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

--- Comment #1 from Jonathan M Davis <issues.dlang@jmdavisProg.com> ---
hasElaborateAssign used to have this same problem, but the fix for https://issues.dlang.org/show_bug.cgi?id=24835 inadvertently fixed it.

--

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

Dlang Bot <dlang-bot@dlang.rocks> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |pull

--- Comment #2 from Dlang Bot <dlang-bot@dlang.rocks> ---
@jmdavis updated dlang/dmd pull request #17075 "Fix bugzilla issue# 24864: hasElaborateDestructor wrong with anonymous unions" fixing this issue:

- Fix bugzilla issue 24864: hasElaborateDestructor wrong with anonymous unions

  hasElaborateDestructor should only be true if the type actually has a
  destructor which is called when the object leaves scope. Anonymous
  unions do not give a destructor to their containing type even if one or
  more of their members has one (the same with copy constructors, postblit
  constructors, and assignment operators). For that sort of thing to work
  properly, such functions need to be added manually to the struct such
  that they call the functions appropriately on whichever member of the
  union is the valid one.

  As such, hasElaborateDestructor should not be true based on the member
  of a union, and there is no need to check the fields of a struct at all,
  because the ultimate question is whether the struct itself has a
  destructor. So, the fact that the code has been checking the struct's
  members is unnecessary in general and wrong in the case of anonymous
  unions.

  The change to checking for __xdtor is because __dtor is an explicitly
  declared destructor, whereas __xdtor is generated by the compiler
  (either because the struct has a destructor or because it has at least
  one member variable which does - and which isn't in a union). So, the
  check for whether the member variables had a __dtor member was probably
  to try to catch the cases where the struct hadn't declared an explicit
  destructor but had had one generated because of its member variables.
  However, simply checking for __xdtor catches that along with explicit
  destructors, and there's no need to instantiate any additional templates
  to check the member variables.

  In addition to fixing this issue with hasElaborateDestructor, I've
  improved the tests for hasElaborateCopyConstructor and
  hasElaborateAssign to catch the same issue for them, though they don't
  currently have the bug.

https://github.com/dlang/dmd/pull/17075

--

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

Dlang Bot <dlang-bot@dlang.rocks> changed:

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

--- Comment #3 from Dlang Bot <dlang-bot@dlang.rocks> ---
dlang/dmd pull request #17075 "Fix bugzilla issue# 24864: hasElaborateDestructor wrong with anonymous unions" was merged into master:

- 74e630d98547ca21eb0ce983c27141d641e46908 by Jonathan M Davis:
  Fix bugzilla issue 24864: hasElaborateDestructor wrong with anonymous unions

  hasElaborateDestructor should only be true if the type actually has a
  destructor which is called when the object leaves scope. Anonymous
  unions do not give a destructor to their containing type even if one or
  more of their members has one (the same with copy constructors, postblit
  constructors, and assignment operators). For that sort of thing to work
  properly, such functions need to be added manually to the struct such
  that they call the functions appropriately on whichever member of the
  union is the valid one.

  As such, hasElaborateDestructor should not be true based on the member
  of a union, and there is no need to check the fields of a struct at all,
  because the ultimate question is whether the struct itself has a
  destructor. So, the fact that the code has been checking the struct's
  members is unnecessary in general and wrong in the case of anonymous
  unions.

  The change to checking for __xdtor is because __dtor is an explicitly
  declared destructor, whereas __xdtor is generated by the compiler
  (either because the struct has a destructor or because it has at least
  one member variable which does - and which isn't in a union). So, the
  check for whether the member variables had a __dtor member was probably
  to try to catch the cases where the struct hadn't declared an explicit
  destructor but had had one generated because of its member variables.
  However, simply checking for __xdtor catches that along with explicit
  destructors, and there's no need to instantiate any additional templates
  to check the member variables.

  In addition to fixing this issue with hasElaborateDestructor, I've
  improved the tests for hasElaborateCopyConstructor and
  hasElaborateAssign to catch the same issue for them, though they don't
  currently have the bug.

https://github.com/dlang/dmd/pull/17075

--