Page MenuHomePhabricator

Warn about usage of __has_include/__has_include_next in macro expansions
Needs ReviewPublic

Authored by arichardson on Jul 9 2018, 10:52 AM.

Details

Reviewers
rsmith
Summary

The characters after 'has_include(' have special lexing rules that can't
possibly be applied when
has_include is generated by a macro. Instead of
wrapping __has_include in another macro the following should be used instead:

#ifndef has_include
#define
has_include(...) 0
#endif

This warning should fix the underlying issue for https://llvm.org/pr37990

Diff Detail

Event Timeline

arichardson created this revision.Jul 9 2018, 10:52 AM

Ping? I'm not sure if this is still required now that D63508 has been committed?

Herald added a project: Restricted Project. · View Herald TranscriptSep 18 2019, 2:21 PM

Under http://eel.is/c++draft/cpp#cond-7.sentence-2, the identifier __has_include can't appear anywhere other than in the context of an #if, #elif, #iifdef, or #ifndef. That's what we should be checking for and diagnosing here (and we should produce an ExtWarn rather than a Warning for this case, because such code is ill-formed, and accepting it at all is a language extension compared to the C++ rules). We should apply the same behavior to __has_cpp_attribute, to which the same rule applies.