[Bug c++/95772] New: warning desired when default operator= cannot be constructued

[Bug c++/95772] New: warning desired when default operator= cannot be constructued

[marcpawl at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95772

            Bug ID: 95772
           Summary: warning desired when default operator= cannot be
                    constructued
           Product: gcc
           Version: 10.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: marcpawl at gmail dot com
  Target Milestone: ---

https://godbolt.org/z/eXckPe

#include <type_traits>

class Const {
 public:
  int const i_;

  Const(int i) : i_(i) {}

  Const& operator=(Const& rhs) = default;
};

int main(int argc, char**) {
  Const c{argc};
  static_assert(!std::is_assignable<Const, Const>::value,
                "should not be able to assign i_");
#ifdef ASSIGN
  Const d{argc + 1};
  d = c;
#endif
  return c.i_;
}

I expected a diagnostic saying that operator= cannot be defaulted which is seen
if the ASSIGN code is enabled.  The code compiles cleanly.

When I wrote this bug in a large code base  with -03 and -flto the code will
fail with illegal instructions and other memory corruption errors.  No problem
without optimization.

[Bug c++/95772] warning desired when default operator= cannot be constructued

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95772

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Marc Pawlowsky from comment #0)
> I expected a diagnostic saying that operator= cannot be defaulted which is
> seen if the ASSIGN code is enabled.  The code compiles cleanly.

As expected. The C++ standard is clear about what this code means. The
explicitly defaulted assignment operator is defined as deleted, because it
would be ill-formed.

Defaulting it doesn't mean it will be provided by the compiler.


> When I wrote this bug in a large code base  with -03 and -flto the code will
> fail with illegal instructions and other memory corruption errors.  No
> problem without optimization.

What bug? The type is not assignable, how can that fail at runtime?

[Bug c++/95772] warning desired when default operator= cannot be constructued

[marcpawl at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95772

--- Comment #2 from Marc Pawlowsky <marcpawl at gmail dot com> ---
I understand that it is deleted, but if somebody says it should be defaulted
when it is defaulted that is most likely an error, and it would be nice if a
warning were generated.

[Bug c++/95772] warning desired when default operator= cannot be constructued

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95772

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
No, =default means "do the right thing" which sometimes means deleting it.

In class templates that is especially true, where you don't know the properties
of the types used as data members or base classes.

[Bug c++/95772] warning desired when default operator= cannot be constructued

[marcpawl at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95772

Marc Pawlowsky <marcpawl at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #4 from Marc Pawlowsky <marcpawl at gmail dot com> ---
"Do the default thing" vs "generate the default".  

What would your feeling be for a clang-tidy rule under readability?  It was a
surprise to me, especially since I never have actually read the spec since
C++98, just training articles/videos and quick scans through the odd committee
paper.