Re: [lmi] Compiler diagnostics

[Vadim Zeitlin]

On Mon, 11 Jul 2022 19:03:25 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> On 7/11/22 16:22, Greg Chicares wrote:
GC> [...]
GC> > Experimentally, for Rule of 0-->5 changes, I copied the old dtor that I
GC> > had removed, and added the other four members, all deleted; then I did
GC> > s/delete/default/ as few times as possible to get everything to build.
GC> 
GC> BTW, I just wanted to mention how difficult that process can be.
GC> For example, if we change 'fund_data.hpp' thus:
GC> 
GC> -    FundInfo(FundInfo const&) = default;
GC> +    FundInfo(FundInfo const&) = delete;
GC> 
GC> then clang's diagnostics are about thirty lines long, and only
GC> one of those lines says that a ctor has been deleted, without
GC> saying which one:
GC> 
GC> 
/usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/stl_construct.h:94:5:
 note: candidate template ignored: substitution failure [with _Tp = FundInfo, 
_Args = <const FundInfo &>]: call to deleted constructor of 'FundInfo'

 It's surprising to me that it doesn't point out to the deleted ctor
directly as I'm pretty sure I had already seen error messages similar to
the gcc one from clang. But at least the deleted ctor can be identified by
its signature (_Args).

GC> OTOH, gcc issues more lines of diagnostics than clang, but
GC> does identify the cause directly:
GC> 
GC> /opt/lmi/src/lmi/fund_data.hpp:51:5: note: declared here
GC>    51 |     FundInfo(FundInfo const&) = delete;

 The trouble with gcc (and MSVC, although you don't care about it) is
finding this line among all the other stuff.

GC> Some years ago, clang's diagnostics were generally better than
GC> gcc's, but now neither one seems much better than the other.

 I've rarely seen situations in which gcc gives better diagnostics than
clang but I'm sure they must exist, just because the phase space of all the
possible C++ errors is so huge that you should be able to find just about
anything in it... I do continue to often encounter cases when clang is much
more clear and to the point than gcc and, in fact, when I get a
particularly incomprehensible gcc error, I often try to compile the same
code with clang because it might be faster to do it than trying to parse
the error from gcc.

GC> Should I hope for better clang diagnostics if I use its
GC>   https://libcxx.llvm.org/
GC> standard library?

 Yes, I think this might be the case and, in particular, I'd be curious if
this particular error message is improved when using libc++. But mostly I
always use libc++ because it's even more different from libstdc++ than
clang itself is different from gcc and I've found several unportable
constructs in my own code that correctly failed to compile (or compiled
with warnings indicating a serious problem) with libc++, while they
compiled just fine with libstdc++. Again, I'm sure the reverse must be
possible as well, but as my primary compiler is gcc, I never encounter it.

 Regards,
VZ

pgpCGxD6b3le8.pgp
Description: PGP signature