[PATCH] D84673: [clang][cli] Port DiagnosticOpts to new option parsing system

[Jan Svoboda via Phabricator via cfe-commits]

jansvoboda11 added inline comments.


================
Comment at: llvm/utils/TableGen/OptParserEmitter.cpp:102-107
+  std::string getMacroName() const {
+    if (KeyPath.startswith("DiagnosticOpts."))
+      return (Twine("DIAG_") + MarshallingInfo::MacroName).str();
+
+    return MarshallingInfo::MacroName;
+  }
----------------
dexonsmith wrote:
> This seems like a bit of a semantic layering violation. It'd be pretty unexpected if someone renamed `DiagnosticOpts` in clang that they'd have to update this code in llvm. Is there another way to solve this problem?
I don't like it either, but the alternatives I can think of are worse.

We could add a `string MacroPrefix;` field to LLVM's `Option` class and populate it in Clang's TableGen file:
1. Via something like an `IsDiag` multiclass that we'd need to remember to apply to each diagnostic option. I don't like it as it seems error prone and introduces duplication.
2. Put all diagnostic options into a single `let MacroPrefix = "DIAG_" in { ... }` block. This removes the duplication, but doesn't ensure an option is in that block iff it's a diagnostic option with `"DiagnosticOpts.*"` keypath.
3. More involved approach would be to duplicate the LLVM's `Option` and related stuff in Clang. That would get us a place to put the custom `KeyPath.startswith("DiagnosticOpts.")` logic and then forward to LLVM's `Option` with the appropriate `MacroPrefix`.

I'll think some more about it.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D84673/new/

https://reviews.llvm.org/D84673