http://d.puremagic.com/bugzilla/show_bug.cgi?id=77

           Summary: After a compile error occurs, all template instances
                    fail
           Product: D
           Version: 0.150
          Platform: All
        OS/Version: Windows
            Status: NEW
          Severity: major
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla@digitalmars.com
        ReportedBy: clugdbug@yahoo.com.au


This is the simplest example I could come up with. If you swap the order of line(10) and line(11), you just get "undefined identifier b". With the order as written, the correct error is followed by spurious error messages:

mar30.d(10): undefined identifier b
mar30.d(11): voids have no value
mar30.d(11): cannot implicitly convert expression (dog!(int)) of type void to
in
t

And with a real project, thousands of lines of incorrect error messages can be generated by a single typo! In fact, I now encounter this bug every time I get any error message at all. I'd rank it as the most annoying bug in DMD. I consider this severity=major -- I've had to temporarily abandon some of my metaprogramming work because of it.

-------
template dog(pig) {
    const int dog=2;
}

void main() {
    int a;
    a=b;              // line (10)
    a = dog!(int);    // line (11)
}


-- 

d-bugmail@puremagic.com wrote:
> http://d.puremagic.com/bugzilla/show_bug.cgi?id=77
> 
>            Summary: After a compile error occurs, all template instances
>                     fail
>            Product: D
>            Version: 0.150
>           Platform: All
>         OS/Version: Windows
>             Status: NEW
>           Severity: major
>           Priority: P2
>          Component: DMD
>         AssignedTo: bugzilla@digitalmars.com
>         ReportedBy: clugdbug@yahoo.com.au
> 
> 
> This is the simplest example I could come up with. If you swap the order of
> line(10) and line(11), you just get "undefined identifier b". With the order as
> written, the correct error is followed by spurious error messages:
> 
> mar30.d(10): undefined identifier b
> mar30.d(11): voids have no value
> mar30.d(11): cannot implicitly convert expression (dog!(int)) of type void to
> in
> t
> 
> And with a real project, thousands of lines of incorrect error messages can be
> generated by a single typo! In fact, I now encounter this bug every time I get
> any error message at all. I'd rank it as the most annoying bug in DMD. I
> consider this severity=major -- I've had to temporarily abandon some of my
> metaprogramming work because of it.
> 
> -------
> template dog(pig) {
>     const int dog=2;
> }
> 
> void main() {
>     int a;
>     a=b;              // line (10)
>     a = dog!(int);    // line (11)
> }
> 
> 

Yeah I we've been talking about this for a while, definitely a must fix.

d-bugmail@puremagic.com wrote:
> And with a real project, thousands of lines of incorrect error messages can be
> generated by a single typo! In fact, I now encounter this bug every time I get
> any error message at all. I'd rank it as the most annoying bug in DMD. I
> consider this severity=major -- I've had to temporarily abandon some of my
> metaprogramming work because of it.

I actually put this in at your suggestion - you suggested that once templates had an error, it was pointless to continue trying to expand them because of a blizzard of cascading errors. I can change it so it just quits on first template error?

Walter Bright wrote:
> d-bugmail@puremagic.com wrote:
>> And with a real project, thousands of lines of incorrect error messages can be
>> generated by a single typo! In fact, I now encounter this bug every time I get
>> any error message at all. I'd rank it as the most annoying bug in DMD. I
>> consider this severity=major -- I've had to temporarily abandon some of my
>> metaprogramming work because of it.
> 
> I actually put this in at your suggestion - you suggested that once templates had an error, it was pointless to continue trying to expand them because of a blizzard of cascading errors. I can change it so it just quits on first template error?

This would be very good. Also, on a static assert fail, template expansion should also end.

Walter Bright wrote:
> d-bugmail@puremagic.com wrote:
>> And with a real project, thousands of lines of incorrect error messages can be
>> generated by a single typo! In fact, I now encounter this bug every time I get
>> any error message at all. I'd rank it as the most annoying bug in DMD. I
>> consider this severity=major -- I've had to temporarily abandon some of my
>> metaprogramming work because of it.
> 
> I actually put this in at your suggestion - you suggested that once templates had an error, it was pointless to continue trying to expand them because of a blizzard of cascading errors. I can change it so it just quits on first template error?

Oh no! You're telling me it's my fault! I was actually referring to the old erroneous blizzard that used to occur. I thought this was the same one. Best I think would be to continue to compile, but limit the max number of errors.

(quietly dying of shame)

Walter Bright wrote:
> d-bugmail@puremagic.com wrote:
>> And with a real project, thousands of lines of incorrect error messages can be
>> generated by a single typo! In fact, I now encounter this bug every time I get
>> any error message at all. I'd rank it as the most annoying bug in DMD. I
>> consider this severity=major -- I've had to temporarily abandon some of my
>> metaprogramming work because of it.
> 
> I actually put this in at your suggestion - you suggested that once templates had an error, it was pointless to continue trying to expand them because of a blizzard of cascading errors. I can change it so it just quits on first template error?

Some further thoughts:

If compilation halts immediately that a template error is detected, you might not know where the problem actually was. At the very least, you also need to know which module was actually being compiled.

Ideally, the compiler would print a "call stack" of which templates were instantiated. If the call stack is printed for a recursive function, though, the error messages can be a mile long.

So ideally, when an error occurs in a template, the compiler would print the error message just as it does right now, then begin to unravel the call stack. While doing this, it would not print error messages, but merely set up an array of module/line number/instance count for each template it encountered. If it had already instantiated that template, it would simply increase its instance count.  When it reaches the function actually being compiled, the context for the error message would finally be printed.

An error message while compiling module 'foo' might look something like:

meta.qualifiednameof(25): undefined identifier b
meta.qualifiednameof(80): recursively instantiated from here
meta.qualifiednameof(50): instantiated from here
meta.qualifiednameof(283): recursively instantiated from here
meta.nameof(15): instantiated from here
foo(15): instantiated from here

Now that it is back in 'foo', compilation could continue.

The important features are:
* there is only one template error message for each template instantiation;
* and we need to know which line of the file instantiated the first template.

http://d.puremagic.com/bugzilla/show_bug.cgi?id=77


clugdbug@yahoo.com.au changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




------- Comment #3 from clugdbug@yahoo.com.au  2006-05-29 05:06 -------
Fixed in 0.158.


--