beanz 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
----------------
aaron.ballman wrote:
> 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)?
My thought process for implementing them separately was that final would be
useful independent of header_unsafe. I could, for example, see applying final
to macros like MIN and MAX, where they can be safely used anywhere, but you
really don’t want multiple definitions floating around.
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
