[Bug c++/53360] g++ prints 'invalid use of incomplete type' error when compiling code with -std=gnu++0x and newer
redi at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Thu Aug 5 09:12:28 GMT 2021
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53360
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |11.0
--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Fixed by r11-7289:
c++: Tweak PR969626 patch
It occurred to me that other types of conversions use
rvaluedness_matches_p,
but those uses don't affect overload resolution, so we shouldn't look at
the
flag for them. Fixing that made decltype64.C compile successfully, because
the non-template candidate was a perfect match, so we now wouldn't consider
the broken template. Changing the argument to const& makes it no longer a
perfect match (because of the added const), so we again get the infinite
recursion.
This illustrates the limited nature of this optimization/recursion break;
it
works for most copy/move constructors because the constructor we're looking
for is almost always a perfect match. If it happens to help improve
compile
time for other calls, that's just a bonus.
gcc/cp/ChangeLog:
PR c++/96926
* call.c (perfect_conversion_p): Limit rvalueness
test to reference bindings.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/decltype64.C: Change argument to const&.
Which was a follow-up to r11-7287:
c++: Tuple of self-dependent classes [PR96926]
When compiling this testcase, trying to resolve the initialization for the
tuple member ends up recursively considering the same set of tuple
constructor overloads, and since two of them separately depend on
is_constructible, the one we try second fails to instantiate
is_constructible because we're still in the middle of instantiating it the
first time.
Fixed by implementing an optimization that someone suggested we were
already
doing: if we see a non-template candidate that is a perfect match for all
arguments, we can skip considering template candidates at all. It would be
enough to do this only when LOOKUP_DEFAULTED, but it shouldn't hurt in
other
cases.
gcc/cp/ChangeLog:
PR c++/96926
* call.c (perfect_conversion_p): New.
(perfect_candidate_p): New.
(add_candidates): Ignore templates after a perfect non-template.
gcc/testsuite/ChangeLog:
PR c++/96926
* g++.dg/cpp0x/overload4.C: New test.
Thi might be a dup of PR 96926 but we could add the testcase to be sure.
More information about the Gcc-bugs
mailing list