Boost and RcppEigen warnings for R package using Stan


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 and RcppEigen 1.66.0-1. My package Makevars file has the standard C++ flags set by rstantools using the package skeleton function.


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


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: 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.


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.