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

2019-12-09 Thread Tor Arne Vestbø via Phabricator via cfe-commits
torarnv added a comment. https://codereview.qt-project.org/c/qt/qtbase/+/284037 has merged and will be part of Qt 5.14.1 I went with treating them all under one strategy: #ifndef __has_foo #define __has_foo(x) 0 #endif This includes `__has_builtin`, `__has_feature`, `__has_attribute`,

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

2019-12-09 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment. In 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

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

2019-12-09 Thread Tor Arne Vestbø via Phabricator via cfe-commits
torarnv added a comment. Qt fix in https://codereview.qt-project.org/c/qt/qtbase/+/284037 Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D49091/new/ https://reviews.llvm.org/D49091 ___ cfe-commits mailing list

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

2019-12-06 Thread Tor Arne Vestbø via Phabricator via cfe-commits
torarnv added a comment. 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`? Repository: rC Clang CHANGES

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

2019-09-19 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith added a comment. 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

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

2019-09-18 Thread Alexander Richardson via Phabricator via cfe-commits
arichardson added a comment. Herald added a project: clang. Ping? I'm not sure if this is still required now that D63508 has been committed? Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D49091/new/

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

2018-07-23 Thread Alexander Richardson via Phabricator via cfe-commits
arichardson added a comment. Ping? Repository: rC Clang https://reviews.llvm.org/D49091 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

2018-07-09 Thread Alexander Richardson via Phabricator via cfe-commits
arichardson created this revision. arichardson added a reviewer: rsmith. Herald added a subscriber: cfe-commits. 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