[libcxx-commits] [libcxx] [libc++] Deprecates std::errc constants. (PR #80542)
Nico Weber via libcxx-commits
libcxx-commits at lists.llvm.org
Mon Mar 25 11:02:06 PDT 2024
nico wrote:
I mean some way (preprocessor define I suppose) that says "I have seen this deprecation message, please silence it for now". That's useful to be able to update your libc++ and then work on new deprecations asynchronously. Without opt-outs, you always have to fix all issues before you can updating again. That opens the risk that upstream lands some bug that you don't notice until the next update attempt, and if that adds a new deprecation before the new bug, you now have to fix _that_ deprecation before you can roll in the bug fix.
MSVC's STL has opt-out macros for every deprecation they add, as far as I know. That is very useful for consumers, since it makes updating independent from fixing deprecation warnings. (It's enough to have these opt-outs for a little while, not forever, of course.)
(For some data points, https://autoroll.skia.org/r/libcxx-chromium/roll-history shows that libc++ updates have been very rough for us this year, with several weeks between successful updates. When things work, we usually update within hours. The last time, it took us a few weeks to clean up the iterator change in #74482 since that didn't have an effective opt-out. In the meantime, 79 changes landed. Several of them cleaned up includes, but luckily it looks like we only had to add a single `#include` line for that. And then this here landed. Which might not need a _ton_ of cleanup, not sure yet, but it's in a dependency, not in direct code, so it'll take a while to pick up the fix again. Every single of these changes isn't super big, but there have been like 5 medium-sized once this year so far, and it's just so much easier if there's an opt-out flag.)
https://github.com/llvm/llvm-project/pull/80542
More information about the libcxx-commits
mailing list