www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 10409] New: dtor / destructor not called for (rvalue) struct used in opApply

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

           Summary: dtor / destructor not called for (rvalue) struct used
                    in opApply
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Keywords: wrong-code
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: Marco.Leise gmx.de


--- Comment #0 from Marco Leise <Marco.Leise gmx.de> 2013-06-18 16:09:26 PDT ---
This code

--- 8< ---------------

import core.stdc.stdio;

struct DestroyMe
{
    ~this() { printf("~this() called\n"); }

    int opApply(in int delegate(int item) dg)
    {
        throw new Exception("Here we go!");
    }
}

void main()
{
    printf("Version with no dtor call:\n");
    try {
        foreach (item; DestroyMe()) {}
    } catch {}
    printf("Version with dtor call:\n");
    try {
        auto lvalue = DestroyMe();
        foreach (item; lvalue) {}
    } catch {}
}

--- >8 --------------

prints:
Version with no dtor call:
Version with dtor call:
~this() called

So the dtor call gets missed when the struct's scope is inside the foreach
header. There is another open bug about struct destructors not being called on
out parameters:
http://d.puremagic.com/issues/show_bug.cgi?id=6186

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 18 2013
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10409



--- Comment #1 from Kenji Hara <k.hara.pg gmail.com> 2013-07-07 23:13:36 PDT ---
I couldn't reproduce the issue on Windows7, by using release-dmd versions from
2.058 to 2.063.2. What version do you use?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 07 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10409


Marco Leise <Marco.Leise gmx.de> changed:

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


--- Comment #2 from Marco Leise <Marco.Leise gmx.de> 2013-07-08 02:54:27 PDT ---
(In reply to comment #1)
 I couldn't reproduce the issue on Windows7, by using release-dmd versions from
 2.058 to 2.063.2. What version do you use?
I was using GDC and LDC. It really doesn't happen with DMD. I'll mark this as invalid and open new reports for the other compilers. Thanks for looking into this anyway! -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jul 08 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10409


Iain Buclaw <ibuclaw ubuntu.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ibuclaw ubuntu.com


--- Comment #3 from Iain Buclaw <ibuclaw ubuntu.com> 2013-07-08 11:34:09 PDT ---
From the backend's perspective, the frontend represents the code in this way:

try
{
    DestroyMe __sl5;
    DestroyMe.opApply (&__sl5, {.object=0B, .func=__foreachbody6});
    apply.DestroyMe.~this (&__sl5);
}
catch (struct Throwable &)
{
}


try
{
    struct DestroyMe lvalue;

    try
    {
        DestroyMe.opApply (&lvalue, {.object=0B, .func=__foreachbody8});
    }
    finally
    {
        apply.DestroyMe.~this (&lvalue);
    }
}
catch (struct Throwable &)
{
}


In this instance, you could either say that it is the job of the backend to
wrap ExpDtorStatement's in try{} finally{} blocks, or fix the frontend to
generate a matching representation.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 08 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10409


Marco Leise <Marco.Leise gmx.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 08 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10409



--- Comment #4 from Iain Buclaw <ibuclaw ubuntu.com> 2013-07-08 12:15:06 PDT ---
(In reply to comment #3)
 In this instance, you could either say that it is the job of the backend to
 wrap ExpDtorStatement's in try{} finally{} blocks, or fix the frontend to
 generate a matching representation.
Hmmm... I meant Expression::toElemDtor. :) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jul 08 2013