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


--- Comment #0 from Don <clugdbug@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: -------

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


Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla@digitalmars.com


--- Comment #1 from Walter Bright <bugzilla@digitalmars.com> 2010-06-28 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: -------

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


Walter Bright <bugzilla@digitalmars.com> changed:

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


--- Comment #2 from Walter Bright <bugzilla@digitalmars.com> 2010-06-28 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: -------