warnings with some compilers due to unknown/unsupported pragma directives

[kotoroshinoto]

On some OSX systems (presumably using clang compilers), packages that are using RcppEigen spout a LOT of warnings of the form:

warning: pragma diagnostic pop could not pop, no matching push [-Wunknown-pragmas] #pragma clang diagnostic pop

I know this is a harmless warning, but end-users in an R context are very often either not software developers at all, or at least lack exposure and experience with compiled programming languages. In an R context warnings are typically more serious and indicative of a serious problem than the compiler warnings in a C/CXX context are assumed to be.

This can result in users being worried about the trustworthiness of a package and being spooked into not using it at all.

Could something be done with preprocessor directives to determine when these pragma directives are actually supported and surround them with #if style directives, so they are only visible the compilers that understand what they do?

[eddelbuettel]

I have to close this -- please bring this up on r-devel or r-package-devel as I as maintainer am forced to re-enable the existing [upstream] suppression of those. I find it painful too, but I don't write CRAN Repository Policy. [1] I do agree with your sentiment -- but it is what it is. So maybe take it to a larger audience.

The package is doing what it is asked to do for CRAN.

[1] I report on its changes via cronjob leading to commits and tweets. https://github.com/eddelbuettel/crp

Edit: Actually the reenable is mostly for BH not RcppEigen. But long story short same thing here: CRAN Repo Policy prohibits suppression of warning. C'est la vie.

[kotoroshinoto]

this isn't so much a warning suppression (i'm not saying you should try to get the compiler to use -Wno flags), its making sure the compiler never sees pragmas that it cannot use.

would CRAN view that as the same thing as using -Wno flags?

Not creating the condition that results in the warning isn't the same thing as suppressing a warning that is otherwise being issued.

[kotoroshinoto]

its like having OS-specific #if switches that change the implementation of a function to work properly on different platforms.

You're changing the actual code presented to the compiler, that isn't simply warning suppression.

Not providing a pragma to clang that it cannot understand isn't merely suppression, it is removing the visibility of code for a given compiler/platform.

its functionally equivalent to the kinds of things one does when making paths use '/' on unix and '\' on windows. If they object to that, it is because THEY don't actually understand the distinction.

[eddelbuettel]

The best you can do is to

• add the -Wno... flags to ~/.R/Makevars
• the R CMD check may still complain when it sees them used
• you cannot put them in src/Makevars

Again, I am on your side. I just cannot change the policies for you -- see them for yourself at https://cran.r-project.org/web/packages/policies.html

[kotoroshinoto]

i wouldn't advise using -Wno flags at all.

I would advise making sure the compiler never sees the pragmas at all, how is that actually any different from other cases where one would use preprocessor switches?

[kotoroshinoto]

I understand that you must have previously been told that this is how they deal with this policy, so i've taken your advice and brought the complaint to them.

It still makes absolutely no sense to treat that kind of thing as equivalent to warning suppression, where in fact it is preventing inappropriate code statements from being used.

[eddelbuettel]

I am going to lock this now. You are still barking at the same tree.

You are free to create a local modified version of RcppEigen -- beauty of open source. Unfortunately the changes you are likely to make there cannot be pushed by me to CRAN. And that is all there is.

[eddelbuettel]

Also: "r-package-devel" is a mailing list you can learn more about and subscribe to here.

I recommend it--it is high quality while low-ish volume. It is a better place for your question.

(And the four-year old repo you filed issue #1 at is likely not the right place. Cheers.)