Page MenuHomePhabricator

[libcxx] Take advantage of gcc4.7 frontend support in type_traits

Authored by ajwong on Jun 28 2014, 2:22 AM.



Removes _LIBCPP_HAS_TYPE_TRAITS. Insteads, for each needed compiler
frontend built-in, uses a combination of __has_feature() and _GNUC_VER
to enable or disable the particular type_trait library function.

These tests now pass in gcc-4.7


Diff Detail

Event Timeline

ajwong updated this revision to Diff 10961.Jun 28 2014, 2:22 AM
ajwong retitled this revision from to [libcxx] Take advantage of gcc4.7 frontend support in type_traits.
ajwong updated this object.
ajwong edited the test plan for this revision. (Show Details)
ajwong added a reviewer: mclow.lists.
ajwong set the repository for this revision to rL LLVM.
ajwong added a project: deleted.
ajwong added a subscriber: Unknown Object (MLST).

gentle ping...

mclow.lists edited edge metadata.Jul 9 2014, 2:54 PM

I guess we're going to end up with a whole slew of macros for compiler capabilities.
I'd really rather keep the checking of compiler versions in __config as much as possible.


I think I'd rather see a _LIBCPP_HAS_IS_EMPTY defined in __config, rather than adding this here.

See _LIBCPP_HAS_IS_BASE_OF for an similar case.


Same comment as line #944


Same comment as line #944


Same comment as line #944

Thinking about this, I want to retract my previous suggestion.

This patch fixes some things, and does not increase the coupling between type_traits and gcc.

Lets commit this patch as-is, and then decouple the #ifdefs in another patch.


mclow.lists accepted this revision.Jul 10 2014, 8:47 AM
mclow.lists edited edge metadata.

Committed as revision 212727. Thanks!

This revision is now accepted and ready to land.Jul 10 2014, 8:47 AM

Thanks Marshall!

I agree about the unfortunate weaving of GCC specific logic in type_traits and my first attempt locally went down the route of per-feature macro abstraction of __has_feature(). It became unwieldy rather quickly. Also the existing code had multiple patterns for feature checking. :(

With this patch, things should be normalized to (a) Use _GNU_VER and cplusplus where possible (b) use a feature macro *if* the gcc and clang built-in are syntactically different (eg is_literal() vs __is_literal_type()).

I personally think that directly using the gcc version check to gate which feature is used in type_traits is an "okay" tradeoff. An alternative is to simulate has_feature() for gcc in config. If you can tell me which pattern you'd like, I'm happy to go through and beat things into that shape.



mclow.lists closed this revision.May 27 2015, 6:38 PM