prepare for the 6.2.0 release

.Rbuildignore

@@ -19,6 +19,7 @@
 ^tools/tbb$
 ^\.github$
 ^\.claude$
+^\.worktrees$
 ^cran-comments\.md$
 ^patches
 ^CRAN-SUBMISSION$

.github/workflows/R-CMD-check.yaml

@@ -23,8 +23,8 @@ jobs:
           - {os: ubuntu-24.04-arm, r: 'release'}
           - {os: windows-latest,   r: 'release'}
           - {os: windows-11-arm,   r: 'release'}
-          # Rtools42 provides only a pre-oneTBB copy of TBB, so this is the
-          # one configuration that builds the bundled oneTBB on Windows
+          # the oldest Rtools we build the bundled oneTBB with (gcc 10, and
+          # the cmake shipped in Rtools42); the newest is covered above
           - {os: windows-latest,   r: '4.2'}
 
     env:
@@ -58,7 +58,8 @@ jobs:
       fail-fast: false
       matrix:
         config:
-          # Rtools42 has no oneTBB, so this one builds the bundled copy
+          # the oldest supported Rtools, and the one rstan could not build
+          # against while RcppParallel used the TBB it provides
           - {os: windows-latest, r: '4.2'}
           - {os: windows-latest, r: 'release'}
           # RcppParallelLibs() changed for every Windows platform, and arm64

CRAN-SUBMISSION

@@ -0,0 +1,3 @@
+Version: 6.2.0
+Date: 2026-07-29 19:00:12 UTC
+SHA: 51a63a9ad17755d02a549bf2fc095150dff172ef

DESCRIPTION

@@ -1,7 +1,7 @@
 Package: RcppParallel
 Type: Package
 Title: Parallel Programming Tools for 'Rcpp'
-Version: 6.1.1.9000
+Version: 6.2.0
 Authors@R: c(
     person("Kevin", "Ushey", role = c("aut", "cre"), email = "kevin@rstudio.com",
         comment = c(ORCID = "0000-0003-2880-7407")),

NEWS.md

@@ -1,22 +1,29 @@
-# RcppParallel (development version)
-
-* On macOS, `RcppParallel::LdFlags()` now also emits an `-rpath` entry for the
-  directory containing the TBB libraries. The libraries record an
-  `@rpath`-relative install name, so packages linking against them previously
-  produced binaries with no runtime search path for TBB; those binaries could
-  only be loaded when RcppParallel (and hence TBB) already happened to be
-  loaded into the process, and failed with "Library not loaded:
-  @rpath/libtbb.dylib" otherwise. (#209)
+# RcppParallel 6.2.0
+
+* Fixed a failure to install with toolchains that accept `-std=c++20` but
+  provide a pre-C++20 standard library, with errors of the form "no member
+  named 'random_access_iterator' in namespace 'std'" from
+  `tbb/parallel_for_each.h`. The bundled oneTBB selected its concepts-based
+  iterator dispatch on a macro testing only the language standard, rather than
+  the `__TBB_CPP20_CONCEPTS_PRESENT` used elsewhere in that same header. This
+  affected RcppParallel's own compilation, as well as any package including
+  the header; CRAN's macOS x86_64 machines, which pair Apple clang 14 with the
+  macOS 11.3 SDK, are one such toolchain. (#268)
 
 * On Windows, RcppParallel now builds the bundled oneTBB as a shared library
   and links against it, shipping `tbb.dll` and `tbbmalloc.dll` alongside the
   package -- the same arrangement already used on every other platform.
   Previously it linked the static TBB provided by Rtools directly into
   `RcppParallel.dll`, which meant the TBB version (and ABI) depended on the
   user's toolchain, and left downstream packages with no TBB library to link
-  against. Building it ourselves gives every platform the same oneTBB and makes
-  the ABI a property of RcppParallel. `TBB_LIB` / `TBB_INC` are still honoured
-  for anyone supplying their own build.
+  against. Rtools42 in particular provides Intel TBB 2017, whose headers
+  downstream packages cannot build against: StanHeaders uses
+  `tbb::this_task_arena::isolate`, which that release still gates behind
+  `TBB_PREVIEW_TASK_ISOLATION` and does not export from its library, so rstan
+  could no longer be built on R 4.2 for Windows. Building TBB ourselves gives
+  every platform the same oneTBB and makes the ABI a property of RcppParallel
+  rather than of the toolchain. `TBB_LIB` / `TBB_INC` are still honoured for
+  anyone supplying their own build. (#269, #274)
 
 * Building RcppParallel now requires cmake (>= 3.5) on all platforms, as
   `SystemRequirements` has always declared. Previously a missing or unusable
@@ -26,6 +33,7 @@
   shipped cmake since Rtools42, so this should not affect Windows users in
   practice. Note that the tinythread backend remains selectable at runtime via
   `RCPP_PARALLEL_BACKEND=tinythread`; it is only no longer a build outcome.
+  (#275)
 
 * As a consequence, `RcppParallel::RcppParallelLibs()` now emits `-ltbb` and
   `-ltbbmalloc` on Windows, in addition to `-lRcppParallel` (which remains
@@ -42,43 +50,24 @@
   already was by the shared libraries on other platforms, so binaries built
   against RcppParallel 5.1.11 and earlier continue to resolve it.
 
+* On macOS, `RcppParallel::LdFlags()` now also emits an `-rpath` entry for the
+  directory containing the TBB libraries. The libraries record an
+  `@rpath`-relative install name, so packages linking against them previously
+  produced binaries with no runtime search path for TBB; those binaries could
+  only be loaded when RcppParallel (and hence TBB) already happened to be
+  loaded into the process, and failed with "Library not loaded:
+  @rpath/libtbb.dylib" otherwise. (#209, #271)
+
 * Fixed `RcppParallel::tbbLibraryPath()` returning `NULL` on Windows, and
   `tbbRoot()` reporting a directory that need not exist on the machine running
   the package -- for a pre-built binary, the Rtools tree of the machine that
-  built it. Both now describe the installation actually in use. (#270)
-
-* Fixed an issue where compiling code including `tbb/parallel_for_each.h`
-  could fail with toolchains that accept `-std=c++20` but provide a
-  pre-C++20 standard library, with errors of the form "no member named
-  'random_access_iterator' in namespace 'std'". This affected CRAN's macOS
-  x86_64 machines, which pair Apple clang 14 with the macOS 11.3 SDK.
-
-* On Windows, RcppParallel now only uses the copy of TBB provided by Rtools
-  when that copy is oneTBB; otherwise, the bundled oneTBB is built from
-  sources, as it already is on other platforms. Rtools42 provides Intel TBB
-  2017, whose headers downstream packages cannot build against: StanHeaders
-  uses `tbb::this_task_arena::isolate`, which that release still gates behind
-  `TBB_PREVIEW_TASK_ISOLATION` and does not export from its library. As a
-  result, rstan could no longer be built on R 4.2 for Windows. A TBB
-  configured explicitly via `TBB_LIB` is still used as-is, whatever its
-  vintage.
-
-* On Windows, `RcppParallel::RcppParallelLibs()` once again offers the TBB
-  stub library, so that packages taking all of their linker flags from it
-  (e.g. rstan) can resolve TBB symbols which `RcppParallel.dll` does not
-  itself re-export.
-
-* Fixed an issue on Windows where a failure to build the TBB stub library
-  could go unreported, since `R CMD SHLIB` has been seen to exit successfully
-  even when the link failed. Installation completed, but shipped a package
-  with no `tbb.dll` -- which packages linking `-ltbb` then discovered only
-  when they failed to load. Installation now fails instead.
+  built it. Both now describe the installation actually in use. (#270, #273)
 
 * Fixed an issue where building the bundled oneTBB could fail when `CXX`
   (or `CC`) was configured with a leading compiler launcher such as `ccache`
   (e.g. `CXX = "ccache g++"`). The launcher is now forwarded to cmake via
   `CMAKE_<LANG>_COMPILER_LAUNCHER` instead of being mistaken for the compiler
-  itself.
+  itself. (#267)
 
 
 # RcppParallel 6.1.1

R/flags.R

@@ -9,9 +9,13 @@
 #' PKG_LIBS += $(shell "${R_HOME}/bin/Rscript" -e "RcppParallel::LdFlags()")
 #' ```
 #'
-#' On Windows, the flags ensure that the package links with the built-in TBB
-#' library. On Linux and macOS, the output is empty, because TBB is loaded
-#' dynamically on load by `RcppParallel`.
+#' What is emitted depends on how TBB is resolved at runtime on each platform.
+#' On Windows, every symbol has to be resolved at link time, so the flags name
+#' both the TBB libraries RcppParallel ships and RcppParallel itself. On macOS,
+#' they name the TBB libraries along with an `-rpath` entry, so that the
+#' resulting binary can find them without relying on `RcppParallel` having been
+#' loaded first. On Linux, the output is empty: TBB symbols are left undefined
+#' at link time and resolved from the libraries `RcppParallel` loads.
 #'
 #' \R packages using RcppParallel should also add the following to their
 #' `NAMESPACE` file:

R/tbb.R

@@ -96,9 +96,11 @@ tbbLdFlags <- function() {
       libsPath <- archSystemFile("libs")
       ldFlags <- sprintf("-L%s -lRcppParallel", asBuildPath(libsPath))
 
-      # only name the TBB libraries when there are TBB libraries to name: a
-      # build that fell back to tinythread ships none, and asking the linker
-      # for them would fail the downstream build outright
+      # only name the TBB libraries when there are TBB libraries to name;
+      # asking the linker for one that isn't there would fail the downstream
+      # build outright. configure always enables TBB, so this should not
+      # happen -- but a wrong answer here is only discovered by whoever is
+      # compiling against us, so check rather than assume
       if (TBB_ENABLED && !is.null(tbbLibraryPath("tbb"))) {
          fmt <- "%s -L%s -l%s -l%s"
          ldFlags <- sprintf(

cran-comments.md

@@ -0,0 +1,84 @@
+## RcppParallel 6.2.0
+
+This release follows closely on 6.1.1, and we apologize for the quick
+turnaround. It fixes the installation failure currently reported for 6.1.1 on
+r-release-macos-x86_64, along with a regression that leaves Windows users
+unable to build some downstream packages from source.
+
+### Installation failure on r-release-macos-x86_64
+
+RcppParallel 6.1.1 fails to install on that machine, with:
+
+    no member named 'random_access_iterator' in namespace 'std'
+
+The bundled oneTBB guarded a concepts-based iterator dispatch in
+`parallel_for_each.h` on a macro that only tests the language standard. With a
+toolchain that accepts `-std=c++20` but provides a pre-C++20 standard library
+-- Apple clang 14 with the macOS 11.3 SDK, as on that check machine -- it
+therefore reached for `std::random_access_iterator`, which is not available.
+oneTBB already defines `__TBB_CPP20_CONCEPTS_PRESENT` as 0 for clang, and
+guards the rest of that header on it; this release uses it for the dispatch
+block as well, so the pre-C++20 fallback is selected as intended.
+
+### Downstream builds on Windows
+
+Since 6.0.0, RcppParallel has linked the static TBB provided by Rtools on
+Windows. That makes the TBB version, and its ABI, a property of the user's
+toolchain rather than of RcppParallel: Rtools42 ships Intel TBB 2017, whose
+headers downstream packages cannot build against (StanHeaders requires
+`tbb::this_task_arena::isolate`, which that release gates behind a preview
+macro and does not export), so rstan can no longer be built from source on
+R 4.2 for Windows. It also left downstream packages with no TBB library to
+link against.
+
+RcppParallel now builds the bundled oneTBB as a shared library on Windows and
+ships it with the package, as it already does on every other platform. As a
+consequence, `RcppParallel::RcppParallelLibs()` now emits `-ltbb` and
+`-ltbbmalloc` there in addition to `-lRcppParallel`. Packages that take their
+linker flags from that function require no source changes; packages that
+hard-coded `-lRcppParallel` to pick up TBB symbols will need to use it.
+
+Building the bundled oneTBB requires cmake, which is now required on Windows
+as well. This matches the `SystemRequirements: CMake (>= 3.5)` that DESCRIPTION
+has always declared, and Rtools has shipped cmake since Rtools42, so it should
+not affect Windows users in practice.
+
+## R CMD check results
+
+0 errors | 0 warnings | 1 note
+
+The note is the incoming-feasibility check reporting the number of days since
+the last update, for the reason described above.
+
+## revdepcheck results
+
+We checked 307 reverse dependencies (276 from CRAN + 31 from Bioconductor),
+comparing R CMD check results across CRAN and dev versions of this package.
+
+ * We saw 0 new problems
+ * We failed to check 9 packages
+
+### Failed to check
+
+* bayesdfa              (NA)
+* BayesPET              (NA)
+* blavaan               (NA)
+* bmgarch               (NA)
+* ctsem                 (NA)
+* GeneralizedUmatrixGPU (NA)
+* multinma              (NA)
+* rmsb                  (NA)
+* TriDimRegression      (NA)
+
+None of these are attributable to this release. Each failed identically
+against the released version in the same run -- they could not be installed
+in the check environment -- and all nine were already failing in our previous
+revdepcheck.
+
+That previous run had sixteen such failures; the six that no longer fail
+(CompositionalRF, DER, kernreg, qs2, Rfast2, rxode2) are the ones we reported
+with 6.0.0 as needing a rebuild against the new oneTBB ABI, which has since
+happened.
+
+One further reverse dependency, 'rmdcev', had not finished checking when this
+was written. It also failed to check in our previous run.