digitalmars.D.bugs - [Issue 4339] New: Struct destructor + invariant + struct parameter = horrific error message
- d-bugmail puremagic.com (74/74) Jun 17 2010 http://d.puremagic.com/issues/show_bug.cgi?id=4339
- d-bugmail puremagic.com (16/16) Jun 28 2010 http://d.puremagic.com/issues/show_bug.cgi?id=4339
- d-bugmail puremagic.com (12/12) Jun 28 2010 http://d.puremagic.com/issues/show_bug.cgi?id=4339
http://d.puremagic.com/issues/show_bug.cgi?id=4339 Summary: Struct destructor + invariant + struct parameter = horrific error message Product: D Version: D2 Platform: Other OS/Version: Windows Status: NEW Keywords: ice-on-valid-code Severity: critical Priority: P2 Component: DMD AssignedTo: nobody puremagic.com ReportedBy: clugdbug yahoo.com.au I've split this off from the comment in bug 3273, since it has a slightly different cause, since bug 3273 is a regression and this bug is not. This code fails on 2.022 with "cannot goto forward into different try block level". No line number, and the code has no goto or try statements. So I'm marking this as an ICE. Actually an ICE would be less misleading. This code has never worked. (Though it compiles with -release). struct A { invariant() { } ~this() { } void opAssign(A a) {} // workaround for bug 3273 int blah(A a) { return 0; } // This triggers the error } --- Preliminary analysis --- The generated code for blah() is as follows: ========== int blah(A a){ try { assert(&this,"null this"); __result = 0; goto __returnLabel; __returnLabel: assert(&this); // becomes this.invariant(); return __result; } finally { a.~this(); } } ============= The error message is generated in s2ir.c. All comments below relate to this file. It generates an error when lblock->Btry != blx->tryblock. It's failing because lblock->Btry is NULL. Normally block->Btry is set from blx->tryblock. labelToBlock(), around s2ir.c(104) has: if (!s->lblock) { s->lblock = block_calloc(blx); if (s->isReturnLabel) s->lblock->Btry = NULL; // Why??? Why is it setting it to null? Is it to indicate that we are NOT guessing the try block? This line needs a comment. If so, we can fix with this bug with a patch to LabelStatement::toIR() around line 875: if (lblock) { // We had made a guess about which tryblock the label is in. // Error if we guessed wrong. // BUG: should fix this + if (!lblock->Btry) // We didn't make a guess + lblock->Btry = blx->tryblock; if (lblock->Btry != blx->tryblock) error("cannot goto forward into different try block level"); -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jun 17 2010
http://d.puremagic.com/issues/show_bug.cgi?id=4339 Walter Bright <bugzilla digitalmars.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bugzilla digitalmars.com 12:23:57 PDT --- The isReturnLabel code is very old. It sets the Btry to NULL to indicate it is outside of any try block. The problem is that years later, the RAII for parameters was added that winds up wrapping the whole function shebang inside a try-finally in order to run the destructors for the parameters in the finally. Hence, now the return label actually is inside a try block. The fix should be to set it to NULL only if there aren't parameters that need destruction. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jun 28 2010
http://d.puremagic.com/issues/show_bug.cgi?id=4339 Walter Bright <bugzilla digitalmars.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED 14:30:52 PDT --- Better yet, rewrite it to handle forward references correctly. http://www.dsource.org/projects/dmd/changeset/567 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jun 28 2010