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

[Hal Finkel]

----- 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,
Hal

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

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory