Moving towards fast evaluation (unwindProtect) by default

[Enchufa2]

Unwind protection for fast evaluation of R code at C/C++ level was introduced in R 3.5, and it has been supported as an opt-in since Rcpp 0.12.15 via a define (RCPP_USE_UNWIND_PROTECT) and a plugin (unwindProtect). Now #1225 brings this as a default for the next release:

• RCPP_USE_UNWIND_PROTECT has no effect anymore.
• Instead, it can be opted-out by defining RCPP_NO_UNWIND_PROTECT.
• The associated plugin is deprecated. To avoid errors, it currently shows a warning and has no effect. It could be removed in a future release.

To plan ahead for this eventual removal (and avoid warnings as much as possible meanwhile), we'll try to identify all the packages using the plugin and propose a patch to switch to using RCPP_USE_UNWIND_PROTECT, which is harmless when the feature is enabled by default. This issue will keep track of the process.

• [x] PPRL (0.3.6) [no repo] [patch emailed 2022-07-27]

Done

• [x] isotree (0.5.15) [repo] [david-cortes/isotree/pull/41] [on CRAN 2022-08-06]
• [x] MatrixExtra (0.1.10) [repo] [david-cortes/MatrixExtra/pull/6] [on CRAN 2022-08-06]
• [x] outliertree (1.8.1) [repo] [david-cortes/outliertree/pull/7] [on CRAN 2022-08-06]
• [x] readsparse (0.1.5-1) [repo] [david-cortes/readsparse/pull/2] [on CRAN 2022-08-06]
• [x] recometrics (0.1.6) [repo] [david-cortes/recometrics/pull/1] [on CRAN 2022-08-06]
• [x] FIESTAutils (1.1.2) [repo] [USDAForestService/FIESTAutils/pull/2] [on CRAN 2022-08-10]

[eddelbuettel]

(Just curious here: should the checkmarks above not be open until the respective PRs have been merged?)

Thanks for filing all those PRs. Our machine is well oiled :grinning:

[Enchufa2]

In this case, I used the checkmarks to denote that I need to do something (that is, if they're not checked). When the PRs are merged, we'll see the links above change color. And when they hit CRAN, I'll add a note.

[eddelbuettel]

Oh, wow, neat! I was unaware of that link trick. I did notice that GitHub started to expand them, I do notice now that they have the open pull request logo. (Still, to me the tick is for final completion. But details schmetails. You are running with this -- and thanks for that -- so your rules.

[david-cortes]

Wanted to clarify: if I am using function Rcpp::unwindProtect, do I need the defined macro if I am already including the unwind header?

[Enchufa2]

If you are just using Rcpp::unwindProtect for your own purposes, then no, you don't need the define (nor the plugin). The define enables fast evaluation via unwindProtect (i.e., whenever Rcpp pokes back into R, this is done via Rcpp_fast_eval instead of Rcpp_eval), so it won't hurt if you add the define, and this will be the default in the next release anyway.

[kevinushey]

If I recall, (and sorry for the lack of context; conference brain) there was one issue with jsonlite (or another package?) regarding how R tryCatch() handlers interacted with the UnwindProtect mechanism. Did we document this distinction anywhere, or do we have a clear path for users who need explicit tryCatch() handling with UnwindProtect? (Or am I misremembering some parts of this?)

[Enchufa2]

It was Jeroen's V8. The code path that was failing required a tryCatch, which Rcpp has been artificially adding for years. The solution was to explicitly add that tryCatch in the proper place, and this is what Jeroen implemented. So we are good to go.

And packages can still call Rcpp_eval directly. That function is not going anywhere.

[kevinushey]

Okay, great. Thanks!

[eddelbuettel]

Yeah, as I recall Jeroen fixed that promptly and early and it already wasn't an issue on 1.0.8. All good :smile_cat:

[david-cortes]

Updated versions now on CRAN for packages isotree, MatrixExtra, outliertree, readsparse, recometrics.

[ctoney]

Updated version now on CRAN for package FIESTAutils.

[eddelbuettel]

This is now fully complete as Rcpp 1.0.10 is now on CRAN. :sparkler: