[R-pkg-devel] Suppressing compiler warnings?

On 14/08/2023 14:43, Dirk Eddelbuettel wrote:

On 14 August 2023 at 11:51, Mark Padgham wrote:
| An update of a package of mine got immediately kicked off CRAN because
| an externally-bundled file which had not been changed for years, and
| which included "pragma clang system_header" to suppress warnings. The
| concern is fair enough. Removing that nevertheless now generates a heap
| of warnings which CRAN will have to wade through / grep to assess
| whether any are of concern. These can be easily suppressed by replacing
| cheap "system_header" with targeted suppression of just two classes of
| warnings for that bundled header file only. But I guess this is also
| forbidden? Should I now just leave those warnings, and rely on CRAN's
| grep policies to assess them? Is there any public list of what such 
grep
| policies might be? (And no, I can't adapt the code to remove the
| warnings, because most are "zero-as-null-pointer-constant", but the "0"
| is actually better than nullptr the way the code is constructed. The
| rest are - currently - unimportant deprecation warnings, all of one
| specific class.)

It is in the CRAN Repostory Policy:

??? - Packages should not attempt to disable compiler diagnostics, nor to
????? remove other diagnostic information such as symbols in shared 
objects.

Per 'svn blame' it goes back to commit 4049 from Apr 2019, but a 
commit from
Nov 2017 has 'memtion (sic!) not disabling compiler diagnostics'.

FWIW I have had to do it for BH and RcppEigen for some time leading to 
both
of them 'spamming' package users with a lot of noise. I don't 
particularly
like that, but I also do not have too many choices here.

Dirk

Thanks Dirk! I've seen also that a couple of tidyverse and r-lib pkgs
bundle the same header, and they also do nothing to suppress this
compiler spam. But gee it would be good to have some "official"
reference for what compiler warnings CRAN are likely to complain about,
and which ones they'll ignore!