aaron.ballman added a comment. In D49091#1773190 <https://reviews.llvm.org/D49091#1773190>, @torarnv wrote:
> I'm picking this up on the Qt side and removing our wrapper macro. Does this > apply to other cases as well? The standard mentions > `__has_cpp_attribute`, but what about `__has_builtin`, `__has_attribute`, > and `__has_include_next`? The standard can only talk about `__has_cpp_attribute` and `__has_include` because the others are extensions. We should treat `__has_cpp_attribute` and `__has_c_attribute` the same way, and both should be handled the same as `__has_include` in terms of http://eel.is/c++draft/cpp#cond-7.sentence-2. I see no reason to treat `__has_attribute` or `__has_include_next` differently from `__has_cpp_attribute` or `__has_include`. I am on the fence about `__has_builtin` because I could sort of imagine wanting to vary runtime behavior in a case like this: if (__has_builtin(__builtin_whatever)) { return __builtin_whatever(); } else { // Do it the hard way } (The same is not true for things like `__has_cpp_attribute` or `__has_include`.) Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D49091/new/ https://reviews.llvm.org/D49091 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
