Attempt to fix issue 23868

[JohanEngelen]

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

Not sure if this is correct.

[dlang-bot]

Thanks for your pull request and interest in making D better, @JohanEngelen! We are looking forward to reviewing it, and you should be hearing from a maintainer soon. Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✗	23868	major	Compiler-generated opAssign has very high stack frame usage

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + dmd#15148"

[maxhaton]

@WalterBright

[JohanEngelen]

This probably needs some extra work to make it exception-safe (what if exception is thrown in the dtor)

[RazvanN7]

This probably needs some extra work to make it exception-safe (what if exception is thrown in the dtor)

This case wasn't treated previously either. Since we are not constructing anything I don't see why we would need to do anything extra.

[JohanEngelen]

This probably needs some extra work to make it exception-safe (what if exception is thrown in the dtor)

This case wasn't treated previously either. Since we are not constructing anything I don't see why we would need to do anything extra.

The state is different after exception is thrown in dtor: Before: this object contains new assigned object After: this object contains old value (on which the dtor failed). The assign object value is lost.

[JohanEngelen]

Testcase whose behavior changes with this change (i.e. I think the PR is wrong currently) :

import std.stdio;
import std.exception;

struct S {
    int i;

    ~this() {
        writeln("~S(", i, ")");
        if (i == 1)
            throw new Exception("thorw");
    }
}

void main() {
    S s;
    s.i = 1;

    try {
        s = S(2);
    } catch (Throwable) {}

    writeln(s.i);
}

Without the change:

~S(1)
2
~S(2)

With this PR:

~S(1)
1
~S(1)
object.Exception@../dtor_throw.d(11): thorw
----------------
??:? void dtor_throw.S.__dtor() [0x100fd3689]
??:? _Dmain [0x100fd35ce]

[12345swordy]

The deconstructor should be nogc and nothrow by default here.

[JohanEngelen]

The deconstructor should be nogc and nothrow by default here.

Why? Is that a language requirement? (do you have a reference?)

[WalterBright]

Please see https://issues.dlang.org/show_bug.cgi?id=23868 which explains that this solution is not correct, and offers suggestions on how to avoid the issue.