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




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


-- 
May 29 2006