Numbering compiler error messages?

Kenji Hara k.hara.pg at gmail.com
Sat Mar 29 20:50:00 PDT 2014


I agree with Walter here. Maintaining error numbers for all errors would
require not little cost for compiler code and documentations, AND it will
slow down compiler improvements for more better diagnostic messages so we
would need to keep backward compatibility of error numbers.

I'll refuse to maintain error number feature.

Kenji Hara

2014-03-30 5:11 GMT+09:00 H. S. Teoh <hsteoh at quickfur.ath.cx>:

> On Sat, Mar 29, 2014 at 12:00:51PM -0700, Walter Bright wrote:
> > On 3/29/2014 11:02 AM, Brad Anderson wrote:
> > >For example, in VC++ if you get "C2001 newline in constant" you
> > >can just lookup C2001
> > >http://msdn.microsoft.com/en-us/library/4x3c2e37.aspx
> >
> > Or you could look up "newline in constant".
> >
> > My point is there's nothing magical about using a number instead. It
> > simply does not enable new features that aren't already there.
>
> I think there's merit in using an error number. It allows easier
> programmatic processing, for example. An IDE might want to detect
> certain error numbers and give some more specific user feedback or
> suggest possible fixes.
>
> While you *could* do the same with just a string lookup, that's unstable
> because presumably, compiler error messages would be improved every now
> and then, and you don't want a simple rephrasing of the error to require
> updating every single IDE and other tool just to match the new wording
> of the same error.
>
> Also, not every error needs a separate number; some parts of the
> compiler may generate different error messages for what is essentially
> the same underlying problem (this may depend on the specific evaluation
> order of the erroneous input, for example). By assigning a single error
> number for both messages, you can aid automated processing tools like
> IDEs to treat a variety of messages as a single logical problem that can
> be uniformly handled.
>
> To do the same using string lookups will require unnecessary additional
> effort on the part of the IDE/tool implementor. (And it would break as
> soon as a PR that improves compiler error messages gets pulled.)
>
>
> T
>
> --
> VI = Visual Irritation
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140330/4a225331/attachment.html>


More information about the Digitalmars-d mailing list