This patch fixes the __is_signed builtin type trait to work with floating point types. Now, the builtin will return true if it is passed a floating point type.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
- Build Status
Buildable 38407 Build 38406: arc lint + arc unit
Event Timeline
But std::is_signed_v<float> needs to yield false. Isn't it cleaner to leave the compiler builtin matching the library type-trait, so that the library doesn't have to check for integral types separately?
Looks good, but please also update http://clang.llvm.org/docs/LanguageExtensions.html#type-trait-primitives
(Can I interest you in fixing the misbehaviour for enumeration types too?)
The idea is that these will match the standard. I don't see anywhere where the standard says that floating-point types yield false. The currently libc++ implementation also yields true for your example.
It should yield true; the spec says "If is_arithmetic_v<T> is true, the same result as T(-1) < T(0); otherwise, false".
(Can I interest you in fixing the misbehaviour for enumeration types too?)
Certainly. You mean that __is_signed should return false for enumeration types?
Yes, exactly.
clang/docs/LanguageExtensions.rst | ||
---|---|---|
1165 | I'd just drop the second half of this sentence, and keep the "likely to change" warning for the non-conformance for enumeration types until that's fixed. (We already have an introductory sentence that says we follow the standard-specified behavior for traits marked (C++) unless otherwise specified.) |
Thanks!
clang/docs/LanguageExtensions.rst | ||
---|---|---|
1165 | Now that this does the standard thing, you can delete this text entirely, or add a "before Clang 10, returned true for enumeration types if the underlying type was signed, and returned false for floating-point types". |
clang/docs/LanguageExtensions.rst | ||
---|---|---|
1165 | I'll add that text before committing. |
I'd just drop the second half of this sentence, and keep the "likely to change" warning for the non-conformance for enumeration types until that's fixed. (We already have an introductory sentence that says we follow the standard-specified behavior for traits marked (C++) unless otherwise specified.)