November 09
https://issues.dlang.org/show_bug.cgi?id=24835

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

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

--- Comment #1 from Dlang Bot <dlang-bot@dlang.rocks> ---
@jmdavis created dlang/dmd pull request #17056 "Fix bugzilla issue 24835." fixing this issue:

- Fix bugzilla issue 24835.

  I don't know why hasElaborateAssign even bothers to look at the member
  variable, since the compiler should be generating opAssign for the
  struct if any of its member variables has one, but doing that check then
  incorrectly reports that the struct has opAssign when that opAssign is
  @disabled.

  So, this fixes it so that it just checks the struct itself for opAssign.
  Ultimately, that's what matters anyway.

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

--
November 10
https://issues.dlang.org/show_bug.cgi?id=24835

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

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

--- Comment #2 from Dlang Bot <dlang-bot@dlang.rocks> ---
dlang/dmd pull request #17056 "Fix bugzilla issue 24835." was merged into master:

- db7b39cf0a2b72051ca35eb91b8a1a1c9220a5ce by Jonathan M Davis:
  Fix bugzilla issue 24835.

  I don't know why hasElaborateAssign even bothers to look at the member
  variable, since the compiler should be generating opAssign for the
  struct if any of its member variables has one, but doing that check then
  incorrectly reports that the struct has opAssign when that opAssign is
  @disabled.

  So, this fixes it so that it just checks the struct itself for opAssign.
  Ultimately, that's what matters anyway.

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

--