This is an archive of the discontinued LLVM Phabricator instance.

[libc++] Consistency in _LIBCPP_CLANG_VER tests in <type_traits>
ClosedPublic

Authored by Quuxplusone on Mar 16 2021, 9:23 AM.

Details

Summary

This came out of my review comments on D97283.

This patch re-enables the use of __is_fundamental, __is_signed, etc. on non-Clang compilers. Previously, when we found that a builtin didn't work on old Clangs, we had been reacting by limiting its use to new Clangs (i.e., we'd also stop using it on new GCCs and new MSVCs, just because of the old Clang bug). I claim that this was unintentional.

Diff Detail

Event Timeline

Quuxplusone requested review of this revision.Mar 16 2021, 9:23 AM
Quuxplusone created this revision.
Herald added 1 blocking reviewer(s): Restricted Project. · View Herald TranscriptMar 16 2021, 9:23 AM

Thanks, Arthur. The tests (and regression tests) should ensure that these issues don't exist on GCC. Not sure how to test this on MSVC (but I think that's "OK" because we don't really test anything on MSVC).

libcxx/include/type_traits
1132–1134

Nit: I think this means we won't take this path on Clang 9.0.1 anymore (which is maybe OK).

Also, saying "style" in the commit message seems to indicate that this is a nfc. I would explicitly point out in the body of the commit message that this enables these builtins on other platforms.

Quuxplusone marked an inline comment as done.Mar 16 2021, 9:36 AM
Quuxplusone added inline comments.
libcxx/include/type_traits
1132–1134

Yeah, I saw that and decided that it was OK, since any difference would be observed merely as a compile-speed pessimization on Clang 9.x compilers. I value consistency-of-syntax more than... that. :)

Quuxplusone retitled this revision from [libc++] Consistent style on _LIBCPP_CLANG_VER tests in <type_traits> to [libc++] Consistency in _LIBCPP_CLANG_VER tests in <type_traits>.Mar 16 2021, 9:39 AM
Quuxplusone edited the summary of this revision. (Show Details)
zoecarver accepted this revision as: zoecarver.Mar 16 2021, 9:43 AM
zoecarver added inline comments.
libcxx/include/type_traits
1132–1134

Fair enough. Especially given these paths won't have to exist much longer.

Quuxplusone marked an inline comment as done.

Rebase on main after the landing of D97283.

libcxx/include/type_traits
1465

FWIW: Reverted the addition of && _LIBCPP_CLANG_VER >= 1300 here, for consistency with how we do it in the other places whose #ifs I'm changing. The compiler-version-specific epicycles don't show up in the #else or #endif comments there.

tmatheson accepted this revision.Mar 16 2021, 10:00 AM

_LIBCPP_CLANG_VER isn't defined for Apple Clang, so branches that were previously disabled, are now enabled, hence the failures for is_pointer and is_unsigned.
An ugly quickfix would be to use (!defined(_LIBCPP_COMPILER_CLANG) || _LIBCPP_CLANG_VER >= N) instead of (!defined(_LIBCPP_CLANG_VER) || _LIBCPP_CLANG_VER >= N).
Cf. https://github.com/llvm/llvm-project/blob/main/libcxx/include/__config#L184-L188.
Another solution would be to define _LIBCPP_CLANG_VER also for Apple Clang, but that might be tricky.
WDYT?

Apart from that, I like the clean-up.

_LIBCPP_CLANG_VER isn't defined for Apple Clang, so branches that were previously disabled, are now enabled

Oh that's just evil. So from our POV they have all the same bugs as Clang, but they pretend to be "not Clang"? :/ I guess that's the only simple approach given how their version numbering doesn't match Clang's.

It does seem like maybe we could keep a mapping like this in __config, but I don't know what the magic numbers would need to be. (And it would bit-rot as new Apple Clang versions were released.)

#if defined(__apple_build_version__)
 #if (__apple_build_version__ < 12340000)
 #define _LIBCPP_CLANG_VER 1200
 #elif (__apple_build_version__ < 12340000)
 #define _LIBCPP_CLANG_VER 1100
 #elif (__apple_build_version__ < 12340000)
 #define _LIBCPP_CLANG_VER 1000
 #else
 #define _LIBCPP_CLANG_VER 100
 #endif
#endif

Personally, I'm okay with your suggestion to use _LIBCPP_COMPILER_CLANG and will update the diff accordingly to poke buildkite. But I agree this has become a can of worms.

Use _LIBCPP_COMPILER_CLANG.
Also, DeMorgan the condition so that it'll be easier to add && !(some-other-compiler) when we learn where else our tricks don't work.

curdeius accepted this revision.Mar 18 2021, 3:51 PM
curdeius added a subscriber: ldionne.

LGTM pending CI.
@ldionne, maybe you have an idea about what should be done for Apple Clang?

This revision is now accepted and ready to land.Mar 18 2021, 3:51 PM