[LLVMdev] [RFC] Add warning capabilities in LLVM.

[Chris Lattner]

Sorry, just getting caught up on an old thread.  I haven't been involved in discussions of this.

On Jul 17, 2013, at 8:53 AM, Bob Wilson <bob.wilson at apple.com> wrote:
> First, let me try to clarify my proposal, in case there was any confusion about that.  LLVMContext already has a hook for diagnostics, setInlineAsmDiagnosticHandler() et al.  I was suggesting that we rename those interfaces to be more generic, add a simple enumeration of whatever diagnostics can be produced from the backend, and add support in clang for mapping those enumeration values to the corresponding clang diagnostics.  This would be a small amount of work and would also be consistent with everything you wrote above about reusing the standard and existing machinery for diagnostics in clang. 

Of all of the proposals discussed, I like this the best:

1) This is a really simple extension of what we already have.

2) The backend providing a set of enumerations for the classes of diagnostics it produces doesn't tie it to clang, and doesn't make it language specific.  Clients should be able to completely ignore the enum if they want the current (unclassified) behavior, and if an unknown enum value comes through, it is easy to handle.

3) I don't see how something like the stack size diagnostic can be implemented by clang calling into the backend. First, the MachineFunction (and thus, MachineFrameInfo) is a transient datastructure used by the backend when a function is compiled.  There is nothing persistent for clang to query.  Second, clang would have to know about all of the LLVM IR functions generated, which is possible, but impractical to track for things like thunks and other implicitly generated entrypoints.

What is the specific concern with this approach?  I don't see how this couples the backend to the frontend or causes layering violation problems.

-Chris