Boost and RcppEigen warnings for R package using Stan

Interfaces RStan
1

I am building an R package using Stan, and recently I’ve been getting some warnings I’ve never noticed before. They seem like issues with BH and RcppEigen, not Stan. Here are a few of them:

/Library/Frameworks/R.framework/Versions/3.4/Resources/library/BH/include/boost/move/detail/iterator_traits.hpp:29:1: warning: inline namespaces are a C++11 feature [-Wc++11-inline-namespace]

/Library/Frameworks/R.framework/Versions/3.4/Resources/library/RcppEigen/include/Eigen/src/Core/util/ReenableStupidWarnings.h:10:30: warning: pragma diagnostic pop could not pop, no matching push [-Wunknown-pragmas]
    #pragma clang diagnostic pop

I realize the problem is most likely not with Stan, but I figured one of you might know more about these warnings. Are there flags I can set to suppress them? I have BH 0.3.3.4.0 and RcppEigen 1.66.0-1. My package Makevars file has the standard C++ flags set by rstantools using the package skeleton function.

2

CRAN does not permit packages to suppress compiler warnings, but these particular ones do not seem worrisome.

3

I originally thought it might be something about my particular machine, but I see now that the warnings also appear in my packages’ Travis CI logs. I find that reassuring. At least the BH warning may be explained by something here: http://dirk.eddelbuettel.com/blog/2018/02/13/#bh_1.66.0-1. I’m thinking the same (new?) CRAN policy may have affected RcppEigen as well, in which case I should just get used to seeing these.

They’re annoying, but I can also appreciate the fact that I am being annoyed by something in a file called ReenableStupidWarnings.h.

4

They worry our users, hence the constant stream of messages we get about them. I imagine many more users are just uneasy, but don’t write in.

Before, we’d tried to intercept some of the header files by loading our own first with the same header guards. That might be worth rethinking here given that we don’t seem to have other means to control this. It’s also a huge pain for CmdStan, etc.

5

These warnings are interfering with my paper-writing as they inundate my papers written using Rnw and knitr, even after I set warning and message to FALSE. It seems there is nothing I can do at all to fix this.

Example messages:

In file included from file5bf9673b08fb.cpp:8:

In file included from /Library/Frameworks/R.framework/Versions/3.4/Resour

In file included from /Library/Frameworks/R.framework/Versions/3.4/Resour

In file included from /Library/Frameworks/R.framework/Versions/3.4/Resour

In file included from /Library/Frameworks/R.framework/Versions/3.4/Resour

In file included from /Library/Frameworks/R.framework/Versions/3.4/Resour

In file included from /Library/Frameworks/R.framework/Versions/3.4/Resour

In file included from /Library/Frameworks/R.framework/Versions/3.4/Resour

In file included from /Library/Frameworks/R.framework/Versions/3.4/Resour

In file included from /Library/Frameworks/R.framework/Versions/3.4/Resour

/Library/Frameworks/R.framework/Versions/3.4/Resources/library/RcppEigen/

#pragma clang diagnostic pop

Using RStudio Version 1.1.442 on a MacBook Pro 10.12.6

sessionInfo()
R version 3.4.4 (2018-03-15)
Platform: x86_64-apple-darwin15.6.0 (64-bit)
Running under: macOS Sierra 10.12.6

Matrix products: default
BLAS: /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
LAPACK: /Library/Frameworks/R.framework/Versions/3.4/Resources/lib/libRlapack.dylib

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] grid parallel stats
[4] graphics grDevices utils
[7] datasets methods base

other attached packages:
[1] rstantools_1.4.0
[2] loo_1.1.0
[3] plyr_1.8.4
[4] coda_0.19-1
[5] knitr_1.20
[6] xtable_1.8-2
[7] magrittr_1.5
[8] dplyr_0.7.4
[9] rstudioapi_0.7
[10] reshape2_1.4.3
[11] rstan_2.17.3
[12] StanHeaders_2.17.2
[13] ggplot2_2.2.1
[14] ggridges_0.5.0
[15] lme4_1.1-15
[16] Matrix_1.2-12
[17] MASS_7.3-49

loaded via a namespace (and not attached):
[1] splines_3.4.4
[2] lattice_0.20-35
[3] colorspace_1.3-2
[4] htmltools_0.3.6
[5] stats4_3.4.4
[6] base64enc_0.1-3
[7] yaml_2.1.18
[8] utf8_1.1.3
[9] rlang_0.2.0
[10] nloptr_1.0.4
[11] pillar_1.2.1
[12] glue_1.2.0
[13] bindrcpp_0.2
[14] matrixStats_0.53.1
[15] bindr_0.1.1
[16] stringr_1.3.0
[17] munsell_0.4.3
[18] gtable_0.2.0
[19] codetools_0.2-15
[20] evaluate_0.10.1
[21] labeling_0.3
[22] inline_0.3.14
[23] Rcpp_0.12.16
[24] scales_0.5.0
[25] backports_1.1.2
[26] jsonlite_1.5
[27] gridExtra_2.3
[28] digest_0.6.15
[29] stringi_1.1.7
[30] rprojroot_1.3-2
[31] cli_1.0.0
[32] tools_3.4.4
[33] lazyeval_0.2.1
[34] tibble_1.4.2
[35] crayon_1.3.4
[36] pkgconfig_2.0.1
[37] rsconnect_0.8.8
[38] assertthat_0.2.0
[39] minqa_1.2.4
[40] rmarkdown_1.9
[41] R6_2.2.2
[42] nlme_3.1-131.1
[43] compiler_3.4.4

1 Like
6

For anything with knitr, you want to set results="hide" in the chunk header (and usually cache = TRUE) that compiles and / or draws. Then make new chunks where you show the results.

7

I thought that include=FALSE would take care of everything. See:

https://yihui.name/en/2017/11/knitr-include-false/

But that doesn’t help, I do have include=FALSE.

8

There’s a separate warning = FALSE flag to suppress warnings and include = FALSE to suppress regular output. All the options are here:

https://yihui.name/knitr/options/#code-chunk

9

yes, i know all this, but knitr seems to be behaving erratically over the
last couple months. or something’s gone wrong with my brain.

10

include = FALSE hides the code, although the warnings may come through.

results = "hide" hides the results but not the code, which is what I do all the time when using Stan from RMarkdown

2 Likes