[PATCH] D116203: [clang] adds unary type transformations as compiler built-ins

John McCall via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Tue Apr 5 21:34:54 PDT 2022

rjmccall added a comment.

In D116203#3430332 <https://reviews.llvm.org/D116203#3430332>, @aaron.ballman wrote:

> In D116203#3425512 <https://reviews.llvm.org/D116203#3425512>, @cjdb wrote:
>> I've noticed that libstdc++ has `using __remove_cv = typename remove_cv<T>::type`, which causes Clang to chuck a wobbly. Changing from `KEYWORD` to `TYPE_TRAIT_1` didn't seem to fix anything.
>> Is there a way we can work around this, or should we just rename `__remove_cv` and friends to something else?
> You could work around it by taking note that you're in a libstdc++ system header and do a special dance, but because these are in the implementation's namespace, I think it's probably kinder for everyone to just pick a different name.
> If you wanted to be especially mean, you could go with `__remove_cvr`, but I'd suggest `__remove_cv_qualifiers` instead. However, what about `restrict` qualifiers? We support them in C++: https://godbolt.org/z/11EPefhjf

Along with a fair number of other vendor qualifiers, yeah.  I think you have to make a policy decision about whether the intent of `std::remove_cv` is really to just remove CV qualifiers or to produce an unqualified type (at the outermost level).  The former is probably more defensible, even if it makes the transform less useful in the presence of extended qualifiers.

  rG LLVM Github Monorepo



More information about the cfe-commits mailing list