[PATCH] D108567: Implement #pragma clang final extension

Chris Bieneman via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Sep 15 20:14:09 PDT 2021


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



More information about the cfe-commits mailing list