• d-bugmail puremagic.com (56/56) Apr 29 2023 https://issues.dlang.org/show_bug.cgi?id=23868

d-bugmail puremagic.com writes:

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

          Issue ID: 23868
           Summary: Compiler-generated opAssign has very high stack frame
                    usage
           Product: D
           Version: D2
          Hardware: All
                OS: All
            Status: NEW
          Severity: major
          Priority: P1
         Component: dmd
          Assignee: nobody puremagic.com
          Reporter: johanengelen weka.io

Testcase:
```
struct S {
    int[100] arr;

    ~this() {}
}

S s;
```

This gives AST (https://d.godbolt.org/z/KKzYnPjah):
```
{
   int[100] arr;
   ~this()
   {
   }
   alias __xdtor = ~this()
   {
   }
   ;
   ref  system S opAssign(S p) return
   {
      (S __swap2 = void;) , __swap2 = this , (this = p , __swap2.~this());
      return this;
   }
}
```

The local `__swap2` variable in the compiler-generated opAssign() results in
very high stack frame usage for large structs.

I believe this implemention of opAssign would solve the problem, as I am 99%
sure that the semantic difference (dtor call before the assignment) is allowed
by the spec:
```
   ref  system S opAssign(S p) return
   {
      this.S.~this();
      this = p;
      return this;
   }
```

Workaround is to disable the generation of opAssign: ` disable ref typeof(this)
opAssign(typeof(this) p);`.

--