[Bug c++/39728] diagnostic for private operator= is voluminous and unhelpful

[Bug c++/39728] diagnostic for private operator= is voluminous and unhelpful

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39728

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-04-15
                 CC|                            |manu at gcc dot gnu.org,
                   |                            |paolo.carlini at oracle dot
                   |                            |com
     Ever Confirmed|0                           |1

--- Comment #2 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-04-15 17:05:31 UTC ---
This is what Clang prints:

In file included from pr39728.C:1:
In file included from /usr/include/c++/4.3/fstream:44:
In file included from /usr/include/c++/4.3/istream:44:
In file included from /usr/include/c++/4.3/ios:49:
In file included from /usr/include/c++/4.3/bits/basic_ios.h:474:
/usr/include/c++/4.3/bits/basic_ios.tcc:182:25: error: 'operator=' is a private
member of 'std::ios_base'
  extern template class basic_ios<char>;
                        ^
/usr/include/c++/4.3/bits/ios_base.h:785:5: note: declared private here
    operator=(const ios_base&);
    ^
/usr/include/c++/4.3/iosfwd:57:11: note: implicit default copy assignment
operator for 'std::basic_ios<char>' first required here
    class basic_istream;
          ^
/usr/include/c++/4.3/bits/fstream.tcc:914:25: note: implicit default copy
assignment operator for 'std::basic_istream<char>' first required here
  extern template class basic_ifstream<char>;
                        ^
/usr/include/c++/4.3/bits/fstream.tcc:913:25: error: 'operator=' is a private
member of 'std::basic_streambuf<char>'
  extern template class basic_filebuf<char>;
                        ^
/usr/include/c++/4.3/streambuf:782:7: note: declared private here
      operator=(const __streambuf_type&) { return *this; };
      ^
/usr/include/c++/4.3/bits/fstream.tcc:914:25: note: implicit default copy
assignment operator for 'std::basic_filebuf<char>' first required here
  extern template class basic_ifstream<char>;
                        ^
pr39728.C:10:5: note: implicit default copy assignment operator for
'std::basic_ifstream<char>' first required here
  y = x;
    ^
2 errors generated.


Even with canonicalized paths, GCC diagnostic is awful. Several things wrong:

* Do not show "In member function", it clutters the output and it is duplicated
info because they are already mentioned in the note. 

* What is a "synthesized method"? Where this term comes from? Is this something
that an average C++ programmer can understand?

* Avoid monsters like "std::basic_streambuf<_CharT, _Traits>::__streambuf_type&
std::basic_streambuf<_CharT, _Traits>::operator=(const __streambuf_type&) [with
_CharT = char; _Traits = std::char_traits<char>; std::basic_streambuf<_CharT,
_Traits>::__streambuf_type = std::basic_streambuf<char>]"

Following Ian's suggestion, it would be amazing if GCC emitted:

pr39728.C:10:5: error: cannot call implicit default copy assignment operator
for 'std::basic_ifstream<char>'
                note: candidates are:
/usr/include/c++/4.3/streambuf:782:7: note: candidate #1 is implicit default
copy assignment operator for 'std::basic_filebuf<char>'
[...............] note: cannot be called because [reason]

/usr/include/c++/4.3/streambuf:782:7: note: candidate #1 is implicit default
copy assignment operator for 'std::basic_filebuf<char>'
[...............] note: cannot be called because [reason]

/usr/include/c++/4.3/bits/fstream.tcc:914:25: note: candidate #2 is implicit
default copy assignment operator for 'std::basic_istream<char>'
[...............] note: cannot be called because [reason]


I am sorry, I don't have time to fix all this, but I wish we had enough
developers to fix it, because it is a shame.

[Bug c++/39728] diagnostic for private operator= is voluminous and unhelpful

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39728

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-04-16 10:44:19 UTC ---
(In reply to comment #1)
>   I think libstdc++ include pathes make the error message useless 

Manu has a patch for that in PR 52974

(In reply to comment #2)
> * What is a "synthesized method"? Where this term comes from? Is this something
> that an average C++ programmer can understand?

Every C++ programmer knows that the compiler implicitly defines special member
functions, including the copy-assignment operator but I don't really like the
terminology. C++ doesn't have methods, it has member functions, and the formal
term in the standard is "implicitly-defined" not synthesized.

[Bug c++/39728] diagnostic for private operator= is voluminous and unhelpful

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39728

--- Comment #4 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-04-16 10:53:50 UTC ---
(In reply to comment #3)
> Every C++ programmer knows that the compiler implicitly defines special member
> functions, including the copy-assignment operator but I don't really like the
> terminology. C++ doesn't have methods, it has member functions, and the formal
> term in the standard is "implicitly-defined" not synthesized.

Indeed. I would consider obvious to do:

sed -i 's/synthesized method/implicitly-defined member function/g' cp/*.c
cp/*.h

Would Jason pre-approve such a patch?

It doesn't fix the actual verbose output Ian is complaining about, but it is a
small positive step.

[Bug c++/39728] diagnostic for private operator= is voluminous and unhelpful

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39728

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-04-16 11:10:07 UTC ---
Maybe the most widely used term is "compiler-generated" but I prefer implicity
defined.

(In reply to comment #2)
> * Do not show "In member function", it clutters the output and it is duplicated
> info because they are already mentioned in the note. 

I'm not sure about this suggestion.  

/home/redi/gcc/4.x/include/c++/4.8.0/bits/ios_base.h: In member function
'std::basic_ios<char>& std::basic_ios<char>::operator=(const
std::basic_ios<char>&)':

This is useful info, it tells me the (implicitly-defined) context in which the
private operator= was needed.

/home/redi/gcc/4.x/include/c++/4.8.0/bits/ios_base.h:791:5: error:
'std::ios_base& std::ios_base::operator=(const std::ios_base&)' is private
     operator=(const ios_base&);
     ^

This is useful, it's the private operator= that was needed, but inaccessible.

In file included from /home/redi/gcc/4.x/include/c++/4.8.0/ios:45:0,
                 from /home/redi/gcc/4.x/include/c++/4.8.0/istream:40,
                 from /home/redi/gcc/4.x/include/c++/4.8.0/fstream:40,
                 from f.cc:1:
/home/redi/gcc/4.x/include/c++/4.8.0/bits/basic_ios.h:64:11: error: within this
context
     class basic_ios : public ios_base
           ^

The caret diagnostic is useless here, because an implictly-defined function has
no location.

[Bug c++/39728] diagnostic for private operator= is voluminous and unhelpful

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39728

--- Comment #6 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-04-16 11:34:01 UTC ---
(In reply to comment #5)
> /home/redi/gcc/4.x/include/c++/4.8.0/bits/ios_base.h: In member function
> 'std::basic_ios<char>& std::basic_ios<char>::operator=(const
> std::basic_ios<char>&)':
> 
> This is useful info, it tells me the (implicitly-defined) context in which the
> private operator= was needed.

OK, the info maybe be useful. I think the way to show it could be better. But
the major improvement would be the typedefs preservation.

> 
> /home/redi/gcc/4.x/include/c++/4.8.0/bits/ios_base.h:791:5: error:
> 'std::ios_base& std::ios_base::operator=(const std::ios_base&)' is private
>      operator=(const ios_base&);
>      ^
> 
> This is useful, it's the private operator= that was needed, but inaccessible.

Indeed! I was in a hurry, but this information should be in the "because
[reason]" part of my ideal output above. My point (and Ian's in comment #1) is
that the error is that the implicitly-defined methods cannot be called/created
(and this should be mentioned first) and the reason is that = is inaccessible
(and this should be mentioned later).

> In file included from /home/redi/gcc/4.x/include/c++/4.8.0/ios:45:0,
>                  from /home/redi/gcc/4.x/include/c++/4.8.0/istream:40,
>                  from /home/redi/gcc/4.x/include/c++/4.8.0/fstream:40,
>                  from f.cc:1:
> /home/redi/gcc/4.x/include/c++/4.8.0/bits/basic_ios.h:64:11: error: within this
> context
>      class basic_ios : public ios_base
>            ^
> 
> The caret diagnostic is useless here, because an implictly-defined function has
> no location.

No, the location is useless (or the error is wrongly stated). The caret just
shows where the error message is pointing to the user. And also, it should not
be an error, but a note.