www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 2816] New: Sudden-death static assert is not very useful

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2816

           Summary: Sudden-death static assert is not very useful
           Product: D
           Version: 1.042
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Keywords: patch
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla digitalmars.com
        ReportedBy: clugdbug yahoo.com.au



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

However, they make static assert rather useless, since it gives you absolutely
no context. To make it useful again,

In staticassert.c, line 68 (in DMD2.027):
        error("is false");
        if (!global.gag)
            fatal();
---
change this to:
        error("(%s) is false", exp->toChars());
---

(ie, remove the global.gag test).


--
Apr 07 2009
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2816






The static assert does give you file/line, so it does give context. But I'll
add the expression print, too.

But I think static assert errors should be fatal. They usually involve
misconfigured code, it is pointless to continue.


--
Apr 07 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2816


clugdbug yahoo.com.au changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|patch                       |







 The static assert does give you file/line, so it does give context. But I'll
 add the expression print, too.
 
 But I think static assert errors should be fatal. They usually involve
 misconfigured code, it is pointless to continue.
 


Yes, there will not be any more meaningful errors. But you still need a back
trace.
If the static assert occurs in (say) a library template, knowing that it
happened in std.functional at line 92 doesn't help very much -- you want to
know where the problem is in _your_ code. (That's a real example, BTW).

Actually, I'll have another try, and see if I can create a backtrace, and THEN
make it a fatal error. So I'm retracting this patch.


--
Apr 07 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2816


kamm-removethis incasoftware.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch





-------
Don, LDC already implemented template instantiation traces. Check
StaticAssert::semantic2 and TemplateInstance::printInstantiationTrace. I
emailed Walter about them at the time. If desired, I can provide a patch
against DMD.


--
Apr 07 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2816








 Don, LDC already implemented template instantiation traces. Check
 StaticAssert::semantic2 and TemplateInstance::printInstantiationTrace. I
 emailed Walter about them at the time. If desired, I can provide a patch
 against DMD.


That'd be great!


--
Apr 07 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2816







For that matter, if template errors could all be given optional (some flag?)
stack traces (not just chained errors) that would be cool.

I'm thinking somthing like:

template error foo bla bla bla.
invoked at file.d:7235 from TBar
invoked at file.d:752 from TBaz
invoked at code.d:7235 from Bling
...

maybe (another flag?) some formatted printing of the args to (limited to 80
columns)


--
Apr 07 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2816






-------
Created an attachment (id=318)
 --> (http://d.puremagic.com/issues/attachment.cgi?id=318&action=view)
template instantiation trace patch

patch against DMD 1.043, superficially tested

Note that this originated as a hack and might have been possible without adding
tinst to Scope and TemplateInstance. There were discussions about including
only certain template instantiations in such a trace:
http://www.mail-archive.com/digitalmars-d puremagic.com/msg03614.html


--
Apr 08 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2816






Christian -- Thanks, this is fantastic!
I've modified it so that it detects recursive template instantiations -- this
dramatically reduces the size of the trace. A patch will follow shortly.


--
Apr 09 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2816






Created an attachment (id=319)
 --> (http://d.puremagic.com/issues/attachment.cgi?id=319&action=view)
patch for dmd2.028

I've adjusted the backtrace in two ways:
(1) displays line numbers in what I believe is a more IDE-friendly manner;
(2) detects recursive template instantiations and collapses them into a single
line.
I've made no changes other than to the InstantiationTrace function.


--
Apr 09 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2816






Error messages generated from my patch for the code below:
bug.d(2): Error: static assert  (0) is false
bug.d(9):        instantiatied from here: bar!()
bug.d(14):        100 recursive instantiations from here: foo!(196)
bug.d(19):        253 recursive instantiations from here: baz!(300)

(Oops -- just realised I there's a typo in "instantiated" in the non-recursive
messages. That's easy to fix).
Note that it detects the recursive instantiation in foo!(), even though it is
instantiated from three different places.

--------
template bar() {
   static assert(0);
}

template foo(int N) {
  static if (N>0) {
     static if (N&1) alias foo!(N-3) foo;
     else alias foo!(N-1) foo;
  } else alias bar!() foo; 
}

template baz(int M) {
   static if (M<50) {
     alias foo!(M*4) baz;
   } else alias baz!(M-1) baz;
}

void main() {
  int x = baz!(300);
}


--
Apr 09 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2816










 Note that it detects the recursive instantiation in foo!(), even though it is
 instantiated from three different places.


it would be nice to have (maybe as an "even more verbose" option) a breakdown
of recursive invocations:

bug.d(14):        100 recursive instantiations from here: foo!(196) [50 at
bug.d(7), 50 at bug.d(8)]


--
Apr 09 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2816






Found another bug in this patch.  Should start the count from 0, not 1.
Otherwise you can get a segfault when the out-by-1 error shows up in the "only
show first and last iterations" case.

in TemplateInstance::printInstantiationTrace()

    // determine instantiation depth and number of recursive instantiations
    int n_instantiations = 0;


--
Apr 18 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2816


Leandro Lucarella <llucax gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |llucax gmail.com



PST ---
http://www.dsource.org/projects/dmd/changeset/294

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 15 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2816




11:11:36 PST ---
Fixed dmd 1.054 and 2.038

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 31 2009
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2816


Don <clugdbug yahoo.com.au> changed:

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


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 03 2010