Missing documentation for unary type traits transformation

[cor3ntin]

The following built-in type traits were recently added to clang

• __add_lvalue_reference
  * __add_pointer
  * __add_rvalue_reference
  * __decay
  * __make_signed
  * __make_unsigned
  * __remove_all_extents
  * __remove_extent
  * __remove_const
  * __remove_volatile
  * __remove_cv
  * __remove_pointer
  * __remove_reference
  * __remove_cvref

These builtins are not mentionned by https://clang.llvm.org/docs/LanguageExtensions.html#type-trait-primitives, which make them hard to discover.

[miscco]

I am unfortuntately late to the party, but I want to state that those builtins are exceptionally hostile for anyone that writes a standard library.

Not only do those builtins collide with ages old functions from libstdc++ which turns them impossible to use, but even worse because those are now keywords, I have to change the name of each of our old school structs because clang is spewing reserved identifier warnings.

I am flabbergasted why on earth they were not prefixed with __builtin like each other builtin that was added recently

[cjdb]

It's quite intentional that the names match the C++ standard library type traits, and has been done this way far longer than the existence of the ones that are mentioned in this issue. There has been long-standing precedent that we do this across Clang and GCC, and in the one or two cases where I did deviate from the <type_traits> name, I've been asked to correct it.

[miscco]

If the intent is to create arbitrary technical debt and force everyone else to jump, then that is indeed a great choice

I already had my fun with __is_signed

[miscco]

Just as an example what kind of hacks this requires from others NVIDIA/thrust@c3ddc5f

[cjdb]

If the intent is to create arbitrary technical debt and force everyone else to jump, then that is indeed a great choice

I already had my fun with __is_signed

Why is the onus on Clang, rather than the standard library implementations, when this is already an inter-compiler precedent? They can just as easily namespace their entities as __stdlib_is_signed, which doesn't disrupt this.

In any case, we do our best to be as compatible with libstdc++ and libc++ as possible, such as warning when there's a struct/builtin conflict, and in some cases, actively going out of our way to detect certain names. In both situations, the library wins the conflict (and if it doesn't, there's a bug).

[miscco]

The onus is on the one that introduces bugs.

If clang introduces builtins that requires me to change perfectly valid code then that is a very bad design.

I can appreciate that our (NVIDIA) dual compilation model is not the best, but I cannot go to our compiler and ask them to change the parser because clang wants to play dirty with names

[cjdb]

I think it would be best if you open a Discourse thread about this, because you are asking us to change a defacto standard across multiple compilers that has been in place for years.

This bug is not the appropriate place to discuss it, and I won't be engaging any further unless it is to discuss the original issue (which won't resolve your frustrations) or to acknowledge a link to your post.

[AaronBallman]

It's hyperbole to ascribe this situation to malice, please stop and familiarize yourself with our community Code of Conduct. Clang is not playing dirty with names, nor are we trying to purposefully make life more difficult for standard library implementers or add technical debt.

There's one reserved namespace that is used by all parts of the implementation, including the compiler and the standard library. That means we all are expected to play nicely together, but that also means there's always a risk of conflicting identifiers. When such a conflict arises, we try to work together to come to a reasonable solution. We were alerted to the libstdc++ issues, and we were able to work around those in the compiler. Sometimes it's easier for the library to work around the issue by picking a different identifier. Sometimes it's an intractable problem where everybody walks away a bit unhappy.

Do you have a link to a bug report filed by your project that alerts us to a problem? If not, please file one if you think this needs to be worked around by Clang so we can discuss it in a more relevant bug report.

However, Clang will continue to add reserved identifiers in the future using this same approach. If you are concerned about your project being negatively impacted, we have the clang-vendors review group for early discussion, we have the potentially-breaking tag we add to announcements for pre-release notification, and we have the potentially breaking changes section of the release notes for post-release notification. So we try to alert folks to exactly this sort of situation whenever we realize there's a potential cause for concern. I'd recommend using some of these channels so that you can provide this feedback before we cause you the problems (at least, as best we can).

[miscco]

It was not my intent to suggest individual malice and I want to apologize if anybody felt attacked personally.

This is mostly me being grumpy about spending a considerable amount of time triaging hard to reproduce bugs that are definitely also related to our compilation model.

I did not know about those channels and will try to monitor them

[AaronBallman]

Thanks! Text is such a hard medium for communication (despite being so quick), and we've all been there with challenging bugs. :-)