Numbering compiler error messages?

H. S. Teoh hsteoh at quickfur.ath.cx
Sat Mar 29 13:11:53 PDT 2014


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


More information about the Digitalmars-d mailing list