Error updating to 1.0.8

[crewalsh]

When I try to update Rcpp from 1.0.7 to 1.0.8 from source, I get the following errors:

install.packages("Rcpp")
clang++ -I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG -I../inst/include/ -I/usr/local/include -fPIC -Wall -g -O2 -c api.cpp -o api.o
clang++ -I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG -I../inst/include/ -I/usr/local/include -fPIC -Wall -g -O2 -c attributes.cpp -o attributes.o
attributes.cpp:2813:45: error: a space is required between consecutive right angle brackets (use '> >')
Rcpp::as<std::vectorstd::string>(pargs_cv);
^~
> >
1 error generated.
make: *** [attributes.o] Error 1

Output of my sessionInfo():
R version 4.0.2 (2020-06-22)
Platform: x86_64-apple-darwin17.0 (64-bit)
Running under: macOS Catalina 10.15.7

Matrix products: default
BLAS: /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
LAPACK: /Library/Frameworks/R.framework/Versions/4.0/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] stats graphics grDevices utils datasets methods base

loaded via a namespace (and not attached):
[1] MASS_7.3-51.6 compiler_4.0.2 Matrix_1.2-18 tools_4.0.2 parallel_4.0.2 OpenMx_2.18.1 Rcpp_1.0.7 grid_4.0.2
[9] digest_0.6.27 packrat_0.5.0 lifecycle_1.0.0 rlang_0.4.11 lattice_0.20-41

Thank you in advance!

[eddelbuettel]

Not a macOS user here so what does clang++ --version say? In our defense, we have macOS users on the team and CRAN has no issues either (and they generally use conservative systems).

[eddelbuettel]

Now line 2813 is a new line so you may indeed be helping yourself if you unpack the source .tar.gz and change it to

       Rcpp::as<std::vector<std::string> >(pargs_cv);  

and then rebuild. It may hit you on a few more (new) lines. This one came since 1.0.7.

/ccing @traversc

[eddelbuettel]

The oldest clang++ I have here on Ubuntu is clang++-8 and it builds it. Ditto g++-7. So cannot reproduce :-/

[crewalsh]

Yeah, not entirely sure on the clang++ --version question; it usually just spits it out, I believe it has to do with it unpacking and compiling the source version... I'm not super savvy with developing R packages but I don't think that this is the error. I can try updating my clang++ to see if that helps...

I tried to change that line for myself in the attributes.cpp file but honestly, this is a bit over my head.

[kevinushey]

What does:

system("clang++ --version")

report for you? E.g. I have:

> system("clang++ --version")
Apple clang version 13.0.0 (clang-1300.0.29.30)
Target: arm64-apple-darwin21.2.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

[traversc]

I forgot that prior to C++ 11, you need a space between brackets for nested templates, so a simple fix with adding a space.

https://stackoverflow.com/questions/15785496/c-templates-angle-brackets-pitfall-what-is-the-c11-fix

Since it wasn't picked up in the continuous integration, I think that means all checks assume C++11 or higher. Should there be a check to test earlier C++ versions?

[crewalsh]

output is:

Apple clang version 12.0.0 (clang-1200.0.32.29)
Target: x86_64-apple-darwin19.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

[eddelbuettel]

Well 12.0.0 should be new enough. Color me puzzled!

Because even if we do not impose C++, your R version 4.0.* should have. In any event, you should be able to get a binary version from CRAN for macOS too. Per the CRAN package page for Rcpp binaries exist for the release version of R (i.e. 4.1.*) for macOS on intel and arm, but not yet for oldrel (your R).

@traversc I don't believe in trying to cover all possibly angles because I more or less think you really can't make things "foolproof". There will always be someone on another side of another line. CRAN release checks are pretty good.

I will make a version 1.0.8.1 available (in the Rcpp drat repo that sets C++11 as the compilation standard. Likely by end of day tomorrow.

[eddelbuettel]

And for what it is worth I just rechecked with the r-base container: R 4.0.* already default to C++11 so we had it as a standard for 21+ months already.

[kevinushey]

FWIW I can confirm that this is the only change required for me to be able to compile with -std=c++98.

My R installation's Makevars has:

CXX = clang++ -arch arm64 -std=gnu++14

so normally std=gnu++14 should be used (at least for R 4.1.2)

[crewalsh]

Yeah, I haven't had an issue up until this week (previously was using 1.0.7 with no issue)! I was getting an error from another package that told me something to the effect of rcpp_precious_remove not provided and a brief google suggested updating Rcpp would solve the issue, hence the updating!

Is my best solution then to update R? Or just hang on until tomorrow when you push 1.0.8.1?

[kevinushey]

I think it would be worth updating R to see if that resolves the issue for you (hopefully it would).

If it doesn't, it might be useful to know if you have a local Makevars that might be overwriting CXX here -- e.g. what is the output of:

readLines("~/.R/Makevars")

(if you get an error saying the file doesn't exist, that's normal for most users)

[eddelbuettel]

Well but the rcpp_precious_remove not provided was, if memory serves, the issue we had 'way back when' (when one had a disconnect between 'newer Rcpp' meeting packages compiled against an older version. With 1.0.7 (and packages built against 1.0.7) you should have been good.

Can we maybe step back here and get some details of what your underlying problem is/was? And as @kevinushey correctly hints, you may in any event get yourself onto the R 4.1.2 train. No upside sticking with outdated versions.

To make a long and boring story short: we work really hard to make Rcpp "just work" if you play in the wheelhouse provided by CRAN. That means, in a nutsehell, using the current R version as well as current versions of packages. That setup we can and do test against. If one deviates there simply are too many possibly angles for anyone to cover.

[crewalsh]

Totally will try to update R tomorrow and report back if that fixes it; I honestly didn't realize I was so far behind in versions and have no real reason to be sticking with an old version. It totally makes sense that you can only make it work with the most current versions.

I was getting that error trying to use ggstatsplot::ggbetweenstats, but it appears that somewhere between then and now as I was trying to fix things, it now magically works so I can't provide the errors. I'm guessing that I was behind on versions there as well and wasn't restarting R properly after updataing, or something of that ilk.

[Enchufa2]

FWIW I can confirm that this is the only change required for me to be able to compile with -std=c++98.

On the one hand, I think we should start cleaning up things and getting rid of all pre-C++11 code, enforcing at least this standard. On the other hand, it's also very cheap to insert a space there for the time being to match every other appearance of something<std::vector<std::string> > in that very same file. :)