Numbering compiler error messages?

Walter Bright newshound2 at digitalmars.com
Sat Mar 29 14:20:48 PDT 2014


On 3/29/2014 1:11 PM, H. S. Teoh wrote:
> I think there's merit in using an error number. It allows easier
> programmatic processing, for example.

     strstr(s,"C2001")

is not any easier than:

     strstr(s, "newline in constant")


> An IDE might want to detect
> certain error numbers and give some more specific user feedback or
> suggest possible fixes.

Sure. But numbers are hardly necessary for that.


> While you *could* do the same with just a string lookup,

And it's trivial to do so. No extra work at all. See strstr() above.


> 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.

Sorry, even with numbers, you gotta go fix the strings everywhere. After all, 
the user would be quite confused if he saw different error messages under 
"C2001" in the documentation than coming from his compiler.

And besides, this DRY problem was solved decades ago. Have a common file from 
which all message texts are drawn.


> 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.

I suggest a simple solution:

    if (A || B) { ... common handler code ... }


> 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.)

I've done error numbers before. It is not less effort - it's more - and it's 
ugly visual noise to the user as well. It's a 1980's solution, forced more or 
less because memory was incredibly tight and I/O was incredibly slow.



More information about the Digitalmars-d mailing list