https://issues.dlang.org/show_bug.cgi?id=14839

ag0aep6g@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ag0aep6g@gmail.com
          Component|phobos                      |druntime

--- Comment #1 from ag0aep6g@gmail.com ---
Digger says this introduced the regression:
https://github.com/D-Programming-Language/druntime/pull/1181
("Make .destroy() work with attribute inference")

That puts the problem in druntime's destroy.

Reduced test case:
----
struct Payload {}
struct Impl { Payload _payload; }

struct RefCounted()
{
    ~this()
    {
        Impl* _refCounted;
        .destroy(_refCounted._payload);
    }
}

class Test { RefCounted!()[1] field; }
----

--

https://issues.dlang.org/show_bug.cgi?id=14839

Martin Nowak <code@dawg.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |code@dawg.eu

--- Comment #2 from Martin Nowak <code@dawg.eu> ---
No, the problem is that the destructor of the class has wrong attributes inferred b/c the used TypeInfo_StaticArray.destroy has no attributes.

--

https://issues.dlang.org/show_bug.cgi?id=14839

--- Comment #3 from ag0aep6g@gmail.com ---
(In reply to Martin Nowak from comment #2)
> No, the problem is that the destructor of the class has wrong attributes inferred b/c the used TypeInfo_StaticArray.destroy has no attributes.

I didn't mean to say that the new destroy code is buggy, just that it triggers the compiler bug.

That means, if the compiler bug can't be fixed in reasonable time for 2.068, we could workaround it in destroy, or revert the destroy changes for the release.

--

https://issues.dlang.org/show_bug.cgi?id=14839

Martin Nowak <code@dawg.eu> changed:

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

--- Comment #4 from Martin Nowak <code@dawg.eu> ---
(In reply to ag0aep6g from comment #3)
> That means, if the compiler bug can't be fixed in reasonable time for 2.068, we could workaround it in destroy, or revert the destroy changes for the release.

The destroy change you triggered issue 14838, but it really is unrelated (see example). Reverting the destroy change is the wrong move here.

We must replace the TypeInfo.destroy calls in buildDtor.

*** This issue has been marked as a duplicate of issue 14838 ***

--