[PATCH] Add warning capabilities in LLVM (backend part), Take 2

Hal Finkel 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().

Thanks again,

> -Quentin
> > 
> > http://llvm-reviews.chandlerc.com/D2376

Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory

More information about the llvm-commits mailing list