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

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

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 cfe-comm

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

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 SIN

[PATCH] D63508: make -frewrite-includes also rewrite conditions in #if/#elif

torarnv added a comment. Thank you for the explanation! 🙂 Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D63508/new/ https://reviews.llvm.org/D63508 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists

[PATCH] D63508: make -frewrite-includes also rewrite conditions in #if/#elif

torarnv added a comment. Just for understanding what's going on here, I'm going to ask some stupid questions 😄 So, this will make `-frewrite-includes` do more work, to ensure that it not only covers the "top level" `#include` or `__has_include` case, but also `__has_include` in one or more lev

[PATCH] D63508: make -frewrite-includes handle __has_include wrapped in a macro

torarnv added a comment. In D63508#1550668 , @rsmith wrote: > Perhaps we should rewrite all `#if`-like directives to `#if 0` or `#if 1`? If I understand your suggestion correctly, wouldn't the latter break this case? #if QT_HAS_INCLUDE() # include

[PATCH] D63508: make -frewrite-includes handle __has_include wrapped in a macro

torarnv added a comment. Just a thought: From the point of view of `-frewrite-includes`, it should technically do full/nested macro expansion right? But from the point of view of Icecream, that would defeat the purpose of using `-frewrite-includes`, since the goal is to embed all includes into

[PATCH] D24998: Add a new optimization option -Og

torarnv added a comment. This seems to have hit a recent Xcode toolchain (Xcode 9.1 ?). Xcode now complains that "[app name] was compiled with optimization - stepping may behave oddly; variables may not be available.", when launching a debug session, which seems to be the case, debugging is all