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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
