aaron.ballman added inline comments.
================ Comment at: clang/test/Lexer/Inputs/unsafe-macro-2.h:23-26 +// not-expected-warning@+1{{macro 'UNSAFE_MACRO_2' has been marked as unsafe for use in headers}} +#undef UNSAFE_MACRO_2 +// not-expected-warning@+1{{macro 'UNSAFE_MACRO_2' has been marked as unsafe for use in headers}} +#define UNSAFE_MACRO_2 2 ---------------- beanz wrote: > aaron.ballman wrote: > > Why do we not expect warnings for these cases? I would have expected that > > undefining a macro is just as unsafe for ABI reasons as defining a macro is. > I kinda waffled on this myself. My thought was to treat this similarly to how > we handle the macro redefinition warning. If you `undef`, you're kind of > claiming the macro as your own and all bets are off... > > That said, my next clang extension closes that loop hole too: > https://github.com/llvm-beanz/llvm-project/commit/f0a5216e18f5ee0883039095169bd380295b1de0 So `header_unsafe` is "diagnose if someone expands this macro from outside the main source file" and `final` is "diagnose if someone defines or undefines this macro anywhere", correct? Would it make sense to have a shorthand to combine these effects for a "fully reserved" macro identifier (`#pragma clang reserve_macro(IDENT[, msg])` as a strawman)? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D107095/new/ https://reviews.llvm.org/D107095 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits