Changes in downstream packages required by #1402

[eddelbuettel]

PR #1402 addresses the long-standing issue #1247 by masking Rf_error() and preferring Rcpp::stop(). A relatively small number of packages do need a minor adjustment each: often just a removal of an #include <R.h> which may mess with the NO_REMAP macro, or a simple re-run of compileAttributes(). This issue will regroup these changes and is based on the 2025-11-04 reverse dependency run summarized in this text file as mention in this comment.

The checklist will be expanded "in due course" to record PRs (or emailed patches).

Group 1: Including R.h which is best avoided

This is an issue we should be more proactive about (as for example RcppArmadillo is w.r.t. Rcpp.h as it can lead to issues with re-definitions of error() as seen here. It is usually both harmless, and without side-effects -- until it isn't.
It consists on removing #include <R.h> as well as any other R headers, which are already loaded by Rcpp safely. The change can be made anytime before or after we land the patch in Rcpp.

• BayesProject: patch emailed 2025-12-21
• GeneralizedWendland: patch emailed 2025-12-21
• locStra: patch emailed 2025-12-21
• LOMAR: patch emailed 2025-12-21, on CRAN 2025-12-22
• SAM: patch emailed 2025-12-21, on CRAN 2026-02-19
• TDA: patch emailed 2025-12-21

Group 2: Use -DRCPP_NO_MASK_RF_ERROR if needed

Some packages have a complicated-enough setup, possibly with other callbacks into R, making use of Rf_error() unavoidable. In those cases a #define can be used to restore the status quo. These package can apply the change anytime.

• ggiraph: Prevent Rcpp from masking valid uses of Rf_error davidgohel/ggiraph#343 filled 2025-12-22, merged 2026-01-16, version 0.9.3 on CRAN 2026-01-19
• mmrm: Prevent Rcpp from masking valid uses of Rf_error openpharma/mmrm#556 filled 2025-12-22, merged 2026-01-07, on CRAN 2026-01-08
• RTMB: Prevent Rcpp from masking valid uses of Rf_error kaskr/RTMB#78 filled 2025-12-22, fixed 2025-12-24
• s2: Prevent Rcpp from masking valid uses of Rf_error r-spatial/s2#292 filled 2025-12-22, merged 2025-12-31

Group 3: Use custom patch

This mostly consists of applying a custom manual patch that switches to Rcpp::stop().

• cpr: Use Rcpp's stop function dewittpe/cpr#63 filled 2025-12-22, merged 2025-12-23, on CRAN 2026-01-08
• VIC5: Use Rcpp's stop and warning functions CUG-hydro/VIC5.R#2 filled 2025-12-22, merged 2026-01-23

Group 4: Re-run compileAttributes()

Packages that defined an Rcpp::interface(cpp) have a resulting RcppExports.cpp that checks for correct (function) pointers and calls Rf_error(). An compileAttributes() re-run once the PR has landed will fix this. So these packages may be on hold until we make the change in Rcpp, likely right after the next release so early 2026. They can however apply the patch we prepared if they use the current GitHub version of Rcpp.

• BGVAR: run compileAttributes(), patch
• coga: run compileAttributes(), patch; version 1.2.3 on CRAN 2026-03-07
• comat: run compileAttributes(), patch; version 0.9.7 on CRAN 2026-03-05
• dqrng: run compileAttributes(), patch
• itp: run compileAttributes(), patch; version 1.2.2 on CRAN 2026-01-10
• meteoland: run compileAttributes(), patch; on CRAN 2026-02-18
• ravetools: run compileAttributes(), patch
• RcppSimdJson: run compileAttributes(), patch; version 0.1.15 on CRAN 2026-01-14
• rrum: run compileAttributes(), patch
• rucrdtw: run compileAttributes(), patch; version 0.1.7 on CRAN 2026-03-06
• sf: run compileAttributes(), patch; on CRAN 2026-02-24
• simcdm: run compileAttributes(), patch

[Enchufa2]

Just a note: there are 88 packages that would require a compileAttributes rerun as documented here. The ones above are just the ones that would fail.

[danielinteractive]

mmrm is done now ✅

[paulnorthrop]

itp (Group 4) is done. compileAttributes() patch has been run. New v1.2.2 on CRAN.