Fix Issue 19099 - Struct with field that has postblit or destructor makes struct assignable

[RazvanN7]

I know this requires a deprecation, it's just that it's a bit complicated to do it.

[dlang-bot]

Thanks for your pull request and interest in making D better, @RazvanN7! 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 annotated coverage diff directly on GitHub with CodeCov's browser extension
• 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
✓	19099	normal	Struct with field that has postblit or destructor makes struct assignable

Testing this PR locally

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

dub fetch digger
dub run digger -- build "master + dmd#8507"

[wilzbach]

Probably a good idea to add a tests for C (only dtor) and D (only postblit)?

[WalterBright]

@RazvanN7 Please add a link to the PR to the bugzilla entry. Otherwise, someone will waste time fixing a bug that has already been fixed. This has happened.

I already added it for this one.

[WalterBright]

see my comments.

[RazvanN7]

After my first noobish attempt, I gave this another look and found the real problem. When the postblit is generated for a struct, opAssign is also generated; opAssign is generated only if all the members are assignable; the TypeStruct isAssignable function tests if each field is assignable, however it has a hack for anonymous unions members so that if a member is assignable, the union is considered assignable; to implement this, it is checked if fields have the same offset, however, the size for the struct is determined on in the second semantic step (right after semantic 1 finished), therefore at this point, all fields have offset 0 => this bug. To fix this, I called the determineSize function in isAssignable so that the offsets are correct. This should be the correct course of action, as at the time of opAssign generation all fields are already semantically analyzed.

ping @WalterBright @andralex

[RazvanN7]

cc @thewilsonator

Fixed.