[PATCH] D49091: Warn about usage of __has_include/__has_include_next in macro expansions

[Aaron Ballman via Phabricator via cfe-commits]

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