================
@@ -547,11 +547,9 @@ void
WarningsSpecialCaseList::processSections(DiagnosticsEngine &Diags) {
StringRef DiagGroup = SectionEntry->getKey();
if (Diags.getDiagnosticIDs()->getDiagnosticsInGroup(
WarningFlavor, DiagGroup, GroupDiags)) {
- StringRef Suggestion =
- DiagnosticIDs::getNearestOption(WarningFlavor, DiagGroup);
- Diags.Report(diag::warn_unknown_diag_option)
- << static_cast<unsigned>(WarningFlavor) << DiagGroup
- << !Suggestion.empty() << Suggestion;
+ // If a diagnostic group name is unknown, simply ignore the
----------------
kadircet wrote:
> I realize it was intentional to emit unknown-warning diagnostics, but I
> really think we should not.
i still feel a little bit uneasy about leaving the user in the dark, when
they're trying to use the suppression mapping and it silently doesn't work
(even if it's due to a configuration error). so i'd rather punt on silently
ignoring, until concerns like version skew is really biting us in practice.
Most of the projects that maintain their own toolchain already needs to put
effort into fiddling with warning flags as they update their toolchain hence I
don't think we're creating any new maintenance surface here.
> Why parse the suppression file in the driver? Even if we do check
> ReportDiags, isn't it just wasted work to read it at all?
sorry my comment was a little misleading. i agree that we shouldn't try parsing
this in driver, there's simply no need. but we should still respect
`ReportDiags` in the implementation.
> I'd be happy to have you do so! (Even if a bit less happy than going with the
> simpler proposal, here).
thanks! i'll put together a patch soon
https://github.com/llvm/llvm-project/pull/124141
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
