RcppParallel 6.0.0 (oneTBB 2022) heads-up: stringfish should just need a rebuild

[kevinushey]

Hi Travers,

I'm the maintainer of RcppParallel, and I've just submitted version 6.0.0 to
CRAN. It updates the bundled Intel TBB to oneTBB 2022.0.0, and the TBB ABI has
changed. stringfish shows up in our reverse dependency checks, so I wanted to
give you a heads-up.

The good news: I don't think stringfish needs any source changes. The revdep
failures came from a cached stringfish.so built against the old TBB (error:
undefined symbol: ...concurrent_vector_base_v3::internal_grow_by...). That's
an old concurrent_vector internal pulled in transitively; rebuilding against
the new headers should make it go away.

I checked stringfish's source against the APIs oneTBB 2022 actually removed
(tbb::task, task_scheduler_init, tbb::mutex, tbb::atomic,
concurrent_vector, tbb::flow, etc.) and found none of them. The only TBB
types you use directly - enumerable_thread_specific, concurrent_unordered_map,
task_arena, plus parallelFor / RcppParallel::Worker - all still exist in
oneTBB 2022 (changed ABI, stable API). So stringfish should compile and link
cleanly against 6.0.0, and CRAN will rebuild it against the new version
automatically once accepted.

Nothing for you to do here - just wanted you to have context in case you see
transient check failures during the transition. (Also worth noting: on Windows,
RcppParallel 6.0.0 now uses the TBB provided by Rtools, so the TBB backend is
available with R >= 4.2.0 there; older R falls back to the tinythread backend.)

Thanks for stringfish/qs2, and apologies for any noise during the transition.

Best,
Kevin Ushey