beanz added inline comments.
================
Comment at: clang/docs/LanguageExtensions.rst:3968-3984
+Final Macros
+============
+
+Clang supports the pragma ``#pragma clang final``, which can be used to
+mark macros as final, meaning they cannot be undef'd or re-defined. For
example:
+
+.. code-block:: c
----------------
aaron.ballman wrote:
> Design question: would it make sense to extend this slightly so that the
> macro does not have to be defined in order to be finalized? e.g., this could
> be used as a way for a library author to say "this identifier cannot be
> defined as a macro"?
That's an interesting thought. I can look into that. Since the current
implementation relies on the identifier info I'm not sure how much work it
would be to support that.
================
Comment at: clang/docs/LanguageExtensions.rst:3979
+ #undef FINAL_MACRO // warning: FINAL_MACRO is marked final and should not
be undefined
+ #define FINAL_MACRO // warning: FINAL_MACRO is marked final and should not
be redefined
+
----------------
aaron.ballman wrote:
> What happens if the redefinition is to the same token sequence as the
> original definition? e.g.,
> ```
> #define FINAL_MACRO 1+1
> #pragma clang final(FINAL_MACRO)
> #define FINAL_MACRO 1+1 // ok?
> #define FINAL_MACRO (1+1) // Whoa...slow your roll there, champ!
> ```
`-Wmacro-redefined` currently warns on redefinitions even if they are the same
as the existing definition.
The implementation in this patch only triggers on redefining macros that have
been undef'd and relies on `-Wmacro-redefined` to catch masking redefinitions.
Although I should probably change that so that final catches on both.
================
Comment at: clang/include/clang/Basic/DiagnosticLexKinds.td:544
+ ExtWarn<"macro %0 has been marked as final and should not be "
+ "%select{un|re}1defined">,
+ InGroup<FinalMacro>;
----------------
aaron.ballman wrote:
> Heh, I like your approach, but a goal of %select is to ease translation of
> our diagnostics to other languages (in theory, anyway).
Ha... Okay... Can do :)
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D108567/new/
https://reviews.llvm.org/D108567
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
