[libcxx-commits] [libcxx] [libc++] Deprecates std::errc constants. (PR #80542)

[Louis Dionne via libcxx-commits]

ldionne wrote:

We provide `_LIBCPP_DISABLE_DEPRECATION_WARNINGS` to allow turning those off. Sure, that will turn off *all* deprecation warnings, but in practice is it really a problem if it takes only a day or so to clean up the deprecated uses in most cases?

Alternatively, we could systematically introduce such macros but this is stuff that we'd be stuck with "forever" unless we agree on some kind of process to clean them up after N releases. If we do that, I'd argue that we want to remove them after a single release: if you need to silence deprecation warnings for an extended period of time, I would argue you shouldn't compile with deprecation warnings turned into errors.

> I've no objection to add an opt-out macro. @ldionne any objection from your side? And should we always do this when we add a new deprecation? For example. for barrier, latch, and friends prior to C++20.

This is an example where the deprecation + removal process is made more complicated. So we would do this, I guess?
- LLVM 19: Deprecation warning for `<barrier>` & friends in < C++20, with `_LIBCPP_DISABLE_DEPRECATION_WARNING_SYNC_BEFORE_CXX20`
- LLVM 20: Remove `_LIBCPP_DISABLE_DEPRECATION_WARNING_SYNC_BEFORE_CXX20`, at the same time remove `<barrier>` & friends from < C++20 ?

Or would the deprecation-warning opt-out also imply that we should have the same for the removal from C++20? If that's the expectation, I would push back on that: we need the ability to make breaking changes (not huge ones) in less than 1 year.

https://github.com/llvm/llvm-project/pull/80542