AaronBallman wrote:

> @AaronBallman, @aengelke, do we have a chance to get this in before branching 
> -- it's important for downstream plugins...

I don't feel comfortable with that because I think this deserves an RFC, for a 
few reasons.

1) Some folks have been pushing to remove `getCustomDiagID()` entirely because 
we want our own internal diagnostics to never use it, so this goes in the 
opposite direction.
2) There's definitely open design questions:
* Can two different plugins introduce the same diagnostic group?
* What happens if a plugin wants to add to an existing compiler diagnostic 
group, like a new flavor of `-Wconversion`?
* Speaking of groups, how does a plugin add their own subgroup? e.g., they want 
`-Wplugin-frobble` but they also want `-Wplugin-frobble-extra` as a subgroup of 
`-Wplugin-frobble`
* How should plugins handle warning groups with options (we don't have a good 
way for our engine to handle it, but it's becoming a more common thing to see 
`-Wwhatever=2` so we should at least be considering it as part of the design)?
3) Because it relates to plugins, early design mistakes could become costly to 
correct later, so it makes sense to do more due diligence up front IMO.

I think we'll be able to come up with a design that everyone is comfortable 
with, but I'd rather not do that with a release branch hanging over us. WDYT?

https://github.com/llvm/llvm-project/pull/208538
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to