[PATCH] Add warning capabilities in LLVM (backend part), Take 2
hfinkel at anl.gov
Wed Dec 11 04:52:35 PST 2013
----- Original Message -----
> From: "Quentin Colombet" <qcolombet at apple.com>
> To: reviews+D2376+public+8c083b1648e3e7b6 at llvm-reviews.chandlerc.com
> Cc: "David Blaikie" <dblaikie at gmail.com>, "renato golin" <renato.golin at linaro.org>, "Chandler Carruth"
> <chandlerc at gmail.com>, "Eric Christopher" <echristo at gmail.com>, "llvm-commits" <llvm-commits at cs.uiuc.edu>, "Hal
> Finkel" <hfinkel at anl.gov>
> Sent: Tuesday, December 10, 2013 6:55:19 PM
> Subject: Re: [PATCH] Add warning capabilities in LLVM (backend part), Take 2
> Hi Hal,
> On Dec 10, 2013, at 4:52 PM, hfinkel at anl.gov wrote:
> > Thanks for working on this!
> > For what do you imagine that DiagnosticInfoOther will be used?
> I was thinking plugins.
Okay; I don't think this is the right way to support plugins. Here's my suggestion:
1. enum DiagnosticKind should end with DK_FirstPluginKind
2. Add a global function: int getNextAvailablePluginDiagnosticKind() which returns an incremented static variable (which starts with DK_FirstPluginKind).
Doing it this way has two advantages:
1. A plugin can take full advantage of the infrastructure (including making full use of customized printers), even for its own custom diagnostics
2. It only adds a few fairly-trivial lines of code to the core infrastructure
For a plugin that contains its own diagnostic classes, each would need a static variable to hold its kind ID, which would be initialized by calling llvm::getNextAvailablePluginDiagnosticKind().
> > http://llvm-reviews.chandlerc.com/D2376
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory
More information about the llvm-commits