[libcxx-commits] [libcxx] [libcxxabi] [libc++][RFC] Always define internal feature test macros (PR #89178)

Nikolas Klauser via libcxx-commits libcxx-commits at lists.llvm.org
Fri May 3 02:33:37 PDT 2024


philnik777 wrote:

> I have a preference for the existing mechanisms. They've not caused my any trouble in my time on the project.
> 
> I think the existing mechanisms encourage/enforce the use of negative feature test macro names (ex. `_LIBCPP_HAS_NO_EXCEPTIONS`). I believe this naming scheme helps avoid misspelling/misconfiguration bugs, since a misspelled guard will almost certainly cause a compilation failure. I worry the proposed approach isn't as robust against this.

I'm not sure how the current mechanism is more robust. A misspelling might not be caught other than by testing the actual code (eg. `#ifdef _LIBCPP_HAS_NO_EXCEPTION` misspelled). The new mechanism will catch all misspellings at compile time (possibly even in your editor), since we use `-Werror -Wundef`. As I said in the description, a very similar change in `<__availability>` caught real bugs.

> This would change very long standing existing practice, which according to my recollection hasn't caused any major problems. Generally the macros are specified in the negative form (ex. _LIBCPP_HAS_NO_EXCEPTIONS), so they're only defined when a feature isn't available.
> 
> Because the current practice is so long standing, I would like this change to come with a clang-tidy that looked for misapplication of `#ifdef` to libc++ macros.

While the practice is long-standing, the names of the individual macros changed before (cf65d27, b22aa3d, 5c40c99, 66a562d), without any major fallout I'm aware of. So I don't think a clang-tidy check pulls its weight here. A general check for internal macros might be nice, but is definitely out of scope for this change.

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


More information about the libcxx-commits mailing list