[cfe-dev] __has_feature coverage

Richard Smith richard at metafoo.co.uk
Thu May 1 21:34:29 PDT 2014


IIRC there were concerns that __has_feature might not be the right place to
be surfacing these traits.

Some of the traits don't work in general (and support just enough to get
through the MS headers); I don't recall exactly which ones, though, and I
think it was more than just __is_*_destructible. Alp, do you recall? (Maybe
it was the __is_nothrow_* ones?)

Do we advertise support for the __has_* ones? We should stop doing that if
we do -- they're fundamentally broken and pretty much useless (they exist
to support libstdc++ and give wrong answers in some cases for GCC
compatibility). Eventually I would ilke to make them synonyms for the
correct traits, but I'm concerned that people might be relying on the GCC
bugs that we emulate for them.


On Thu, May 1, 2014 at 7:48 AM, Marshall Clow <mclow.lists at gmail.com> wrote:

> Recently, reading llvm/tools/clang/docs/LanguageExtensions.rst, I saw a
> list of type_trait primitives
> supported by clang.
>
> One of them caught my eye: __is_nothrow_constructible  — that could be
> handy for use in libc++.
>
> So I ran a quick test:
>
>         __is_nothrow_constructible(int)
> and it returned true.
>
> Then I tried:
>         __has_feature(is_nothrow_constructible)
> and it returned false.
>
> Well, that’s not useful to me; I need to be able to tell when I can use
> that feature.
> So I whipped up a program to test all of the type_traits listed in that
> file (attached),
> and to see if I can check (using __has_feature) whether or not they are
> implemented.
>
> Turns out that __has_feature returns false for the following type traits:
>
>         __has_feature(is_interface_class) = 0
>         __has_feature(is_destructible) = 0
>         __has_feature(is_nothrow_destructible) = 0
>         __has_feature(is_nothrow_assignable) = 0
>         __has_feature(is_nothrow_constructible) = 0
>
> __is_interface_class is a MS extension; so that’s fine.
> __is_destructible and __is_nothrow_destructible are described as
> “partially implemented”, and attempts to use them fail.
>
> On the other hand:
>         __is_nothrow_constructible(int) returns 1
>         __is_nothrow_assignable(int&, int) returns 1
>
> So these two seem to work (for at least one case)
> It seems to me that we should have feature tests for these type traits if
> we expect people to use them
>
> So, I’d like to see
>         __has_feature(is_nothrow_constructible)
> and     __has_feature(is_nothrow_assignable)
>
> return 1
>
>
> — Marshall
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140501/87386d6c/attachment.html>


More information about the cfe-dev mailing list