[Issue 4339] New: Struct destructor + invariant + struct parameter = horrific error message

d-bugmail at puremagic.com d-bugmail at puremagic.com
Thu Jun 17 00:54:18 PDT 2010


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 at puremagic.com
        ReportedBy: clugdbug at yahoo.com.au


--- Comment #0 from Don <clugdbug at yahoo.com.au> 2010-06-17 00:54:17 PDT ---
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: -------


More information about the Digitalmars-d-bugs mailing list