[llvm-dev] [RFC] Preferred error/note style across non-clang tools, e.g. tablegen

[Jonathan Roelofs via llvm-dev]

> On Jul 24, 2020, at 2:03 PM, Chris Lattner <clattner at nondot.org> wrote:
> 
> 
> 
>> On Jul 24, 2020, at 11:23 AM, Evandro Menezes <evandro.menezes at sifive.com <mailto:evandro.menezes at sifive.com>> wrote:
>> 
>>>> 
>>>> I do not personally like the error and note, since in the patch above, the note is always fatal, whereas I'd rather see what other errors there are before it aborts.
>>> 
>>> There is plenty of prior-art even just in CodeGenSchedule for error-and-non-fatal-notes (see collectRetireControlUnits, collectLoadStoreQueueInfo). These new ones merely maintain existing behavior of exiting after the diagnostic. Seems this objection is an objection to how it already behaves, and not to the changes I’m proposing.
>> 
>> I may be missing something, but we'll discuss the patch in its review.  However, unless an error results in a barrage of errors because something crucial was broken, I'd rather see all error messages.  Sometimes, building is tedious (e.g., batch system), so I'd rather be aware of all issues and fix them before trying another build.
> 
> Maybe I missed something here: I thought the proposal was to add additional notes to existing error messages, with the goal of clarifying the output and improving the user experience.
> 
> I didn’t think the intention was to turn error messages into notes.  Did I get that wrong?

The patch transforms a few `PrintFatalError()`s into `PrintError(); PrintFatalNote();`s.

Evandro is asking me to turn it instead into `PrintError(); PrintNote();`, which I’m not confident is okay: this might invalidate some invariant and lead to the tool crashing later. I’d rather not lump that in with my changes.


Jon

> 
> Notes serve completely different role than errors: notes are an “add on” to a warning or error, they should never be a primary diagnostic.
> 
> -Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200724/2fc45f07/attachment.html>