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

Renato Golin renato.golin at linaro.org
Wed Dec 11 05:06:29 PST 2013

On 11 December 2013 12:52, Hal Finkel <hfinkel at anl.gov> wrote:
>> >  For what do you imagine that DiagnosticInfoOther will be used?
>> I was thinking plugins.

I think it should be easy for third-party implementations (not-yet or
never-to-be merged code) to have their own non-clashing handlers,
which ends up as deriving from the base class only on your tree and
make use of it only by your code.

>  1. enum DiagnosticKind should end with DK_FirstPluginKind

This is ok, because plugins can use/reuse the same enum values, but it
makes it hard for keeping trees in sync. Worst still, if you use two
plugins that happen to use the same enum values, we'll only find out
if they both run on the same binary and report an error.

Open source plugins can have their values added to the main tree,
closed source ones cannot.

>  2. Add a global function: int getNextAvailablePluginDiagnosticKind() which returns an incremented static variable (which starts with DK_FirstPluginKind).

I think we can start simple, and add a DK_PluginKind and make all
plugins differentiate themselves in the error message, or even having
a customized payload for the C-API which passes a PDK_Kind (Plugin
Diagnostic Kind). But I think this needs more discussion.


More information about the llvm-commits mailing list