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

Jonathan Roelofs via llvm-dev llvm-dev at lists.llvm.org
Tue Jul 21 15:15:15 PDT 2020



> On Jul 21, 2020, at 1:46 PM, Evandro Menezes <evandro.menezes at sifive.com> wrote:
> 
> 
> 
>> On Jul 21, 2020, at 14:30, Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>> 
>> 
>> 
>>> On Jul 21, 2020, at 11:50 AM, Jonathan Roelofs via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>>> 
>>> A question of preference came up in https://reviews.llvm.org/D83588 <https://reviews.llvm.org/D83588> as to whether we ought to prefer emitting TableGen error messages with all of the information in a single diagnostic, or whether it makes sense to split things in an error+note style as seen in many clang diagnostics. TableGen doesn’t use a DiagnosticsEngine, so the concept of a fatal note following an error is a bit new/foreign there, but perhaps something that makes sense adding.
>>> 
>>> Is there any precedence here for other internal llvm tooling (outside of clang)? What’s the general consensus here?
>> 
>> I think it makes a lot of sense to add this to TableGen.  It is a widely used tool and the QoI for its error messages could use a lot of improvement!
> 
> There is a lot of room from improvement in several details of TableGen.  However, methinks that changes towards such a goal shouldn't be sneaked in small doses.  Then it just adds more inconsistent error reporting to an already inconsistent reporting.

Sure, let’s talk about what that end goal should be! Can you give some other examples of where these inconsistencies could be improved?

>  If one wants to improve the error reporting in TableGen, let one take it on himself this project, apart from one's other patches.

Is incremental progress not welcome? I understand pushback on refactoring combined with functional changes, but that’s not at all what this is. The entire purpose of that patch is to improve these diagnostics, making it easier to do scheduler model work.

> 
> __ 
> Evandro Menezes ◊ SiFive ◊ Austin, TX
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200721/4ac6c449/attachment.html>


More information about the llvm-dev mailing list