www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Bug 77] New: After a compile error occurs, all template instances fail

reply d-bugmail puremagic.com writes:
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)
}


--
Mar 31 2006
next sibling parent Kyle Furlong <kylefurlong gmail.com> writes:
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.
Mar 31 2006
prev sibling next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
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?
Mar 31 2006
next sibling parent Kyle Furlong <kylefurlong gmail.com> writes:
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.
Mar 31 2006
prev sibling next sibling parent Don Clugston <dac nospam.com.au> writes:
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)
Apr 01 2006
prev sibling parent Don Clugston <dac nospam.com.au> writes:
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.
Apr 03 2006
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/bugzilla/show_bug.cgi?id=77


clugdbug yahoo.com.au changed:

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





Fixed in 0.158.


--
May 29 2006