[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