I followed a suggestion from BCS: I disabled the error function with
no line number (it's in root.h).
I renamed it to errorNoLoc() (with a #ifdef MARS just in case it is
also used by the C++ compiler).
Then watched all the places where it was being called. Most of them
were sensible, but this did catch a four places where its used, that
are probably bugs.

The first one is trivial to fix...
statement.c 4197
void Catch::semantic(Scope *sc)
-        error("can only catch class objects, not '%s'", type->toChars());
+        error(loc, "can only catch class objects, not '%s'", type->toChars());

For the other three, it's a bit less obvious which loc to use.

expression.c 518 arrayExpressionToCommonType()
"%s has no value"

template.c 186 match()
error("recursive template expansion for template argument %s", t1->toChars());

init.c, 158 StructInitializer::semantic()
            error("%s %s has constructors, cannot use { initializers
}, use %s( initializers ) instead",
                ad->kind(), ad->toChars(), ad->toChars());

Based on this quick result, I strongly recommend making a change like this, it would eliminate a whole class of errors from recurring in future. Certainly the statement.c bug should be fixed in the next release, it's so easy.

Yeah the error handling is a mess.
There are several different versions of error() in different places
(mars.c, root.c, expression.c, ...). Some add loc by themselves, some
don't (like the global one you mentioned).
I think that's why it's so error prone.

In todt.c:141 an error function is called but neither Visual Studio's IntelliSense nor VisualAssist's usually very smart one can detect which one is called.


Additionally in the following issue Expression::error() is called in
todt.c:683 which normally does add loc to the message, but for some reason
loc is null:
http://d.puremagic.com/issues/show_bug.cgi?id=4241


Warnings are another problem. For example see this bug where a warning is put out like an error: http://d.puremagic.com/issues/show_bug.cgi?id=4216

On Thu, Jun 3, 2010 at 3:53 PM, Trass3r <mrmocool at gmx.de> wrote:

> Yeah the error handling is a mess.
> There are several different versions of error() in different places
> (mars.c, root.c, expression.c, ...). Some add loc by themselves, some don't
> (like the global one you mentioned).
> I think that's why it's so error prone.
>
>
Maybe cleaning that up should be next weeks project...


As for the cases where it's not clear what LOC to put out, I'd say even an arbitrary value would be better than nothing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-internals/attachments/20100603/d5149223/attachment.html>

On 4 June 2010 00:53, Trass3r <mrmocool at gmx.de> wrote:
> Yeah the error handling is a mess.
> There are several different versions of error() in different places (mars.c,
> root.c, expression.c, ...). Some add loc by themselves, some don't (like the
> global one you mentioned).

That function I mentioned is the only one which doesn't add loc. The problem is, that if you have code in a member function which calls error(), then turn it into a static member function, it will happily compile, but the errors will have no longer have a line number since the no-loc error() function has been called.

> In todt.c:141 an error function is called but neither Visual Studio's IntelliSense nor VisualAssist's usually very smart one can detect which one is called.
>
>
> Additionally in the following issue Expression::error() is called in
> todt.c:683 which normally does add loc to the message, but for some reason
> loc is null:
> http://d.puremagic.com/issues/show_bug.cgi?id=4241

That's a different issue, it's caused when a semantic transformation is done, and the compiler creates new expressions, explicitly passing NULL as the loc parameter. The error message shouldn't be created at all, because it refers to compiler-generated code, not source code.

Missing line numbers of the first type are easily preventable by just changing the name of the error() function, as I have done. As I previously mentioned, there are currently 4 such bugs in DMD at present. It's low-hanging fruit.