prepare for the 6.2.0 release

Consolidate the NEWS entries for this cycle: three of them described
intermediate states that later commits superseded, and contradicted the
entries above them -- configure no longer probes for an Rtools TBB, and
the tbb.dll stub is gone.

Also correct the flags documentation, which claimed LdFlags() emits
nothing on macOS; that stopped being true in 5.1.8, and this release
adds an -rpath there. Drop patches/windows_arm64.diff, which patches
files removed with the make-based TBB in 6.0.0 and whose one remaining
hunk is now upstream.

Exclude .worktrees from the build: R CMD build was sweeping local
worktrees into the tarball, 1741 of its 2193 files.

Author: kevinushey

.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

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,19 @@
-# 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
 
 * 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 +23,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 +40,30 @@
   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)
+  built it. Both now describe the installation actually in use. (#270, #273)
 
 * 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.
+  x86_64 machines, which pair Apple clang 14 with the macOS 11.3 SDK. (#268)
 
 * 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,37 @@
+## RcppParallel 6.2.0
+
+This release follows closely on 6.1.1. We apologize for the quick turnaround;
+it repairs a regression that leaves Windows users of RcppParallel unable to
+build some downstream packages.
+
+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
+
+<!-- TODO: fill in from a fresh revdepcheck run against 6.2.0 -->