[PR c++/88146] do not crash synthesizing inherited ctor(...)
authorAlexandre Oliva <aoliva@redhat.com>
Wed, 19 Dec 2018 06:51:19 +0000 (06:51 +0000)
committerAlexandre Oliva <aoliva@gcc.gnu.org>
Wed, 19 Dec 2018 06:51:19 +0000 (06:51 +0000)
commitbceca9b3f7d9cd935574652edc62a117c8736823
tree93061afdcfb56ab9463e3f2da40496c7479c5608
parent4469188ce7f228902629595941e1c2ff24b9c4d6
[PR c++/88146] do not crash synthesizing inherited ctor(...)

This patch started out from the testcase in PR88146, that attempted to
synthesize an inherited ctor without any args before a varargs
ellipsis and crashed while at that, because of the unguarded
dereferencing of the parm type list, that usually contains a
terminator.  The terminator is not there for varargs functions,
however, and without any other args, we ended up dereferencing a NULL
pointer.  Oops.

Guarding accesses to parm would be easy, but not necessary.  In
do_build_copy_constructor, non-inherited ctors are copy-ctors, that
always have at least one parm, so parm needs not be guarded when we
know the access will only take place when we're dealing with an
inherited ctor.  The only other problematic use was in the cvquals
initializer, a variable only used in a loop over fields, that we
skipped individually in inherited ctors.  I've guarded the cvquals
initialization and the entire loop over fields so they only run for
copy-ctors.

Avoiding the crash from unguarded accesses was easy, but I thought we
should still produce the sorry message we got in other testcases that
passed arguments through the ellipsis in inherited ctors.  I put a
check in, and noticed the inherited ctors were synthesized with the
location assigned to the class name, although they were initially
assigned the location of the using declaration.  I decided the latter
was better, and arranged for the better location to be retained.

Further investigation revealed the lack of a sorry message had to do
with the call being in a non-evaluated context, in this case, a
noexcept expression.  The sorry would be correctly reported in other
contexts, so I rolled back the check I'd added, but retained the
source location improvement.

I was still concerned about issuing sorry messages while instantiating
template ctors even in non-evaluated contexts, e.g., if a template
ctor had a base initializer that used an inherited ctor with enough
arguments that they'd go through an ellipsis.  I wanted to defer the
instantiation of such template ctors, but that would have been wrong
for constexpr template ctors, and already done for non-constexpr ones.
So, I just consolidated multiple test variants into a single testcase
that explores and explains various of the possibilities I thought of.

for  gcc/cp/ChangeLog

PR c++/88146
* method.c (do_build_copy_constructor): Guard cvquals init and
loop over fields to run for non-inherited ctors only.
(synthesize_method): Retain location of inherited ctor.

for  gcc/testsuite/ChangeLog

PR c++/88146
* g++.dg/cpp0x/inh-ctor32.C: New.

From-SVN: r267250
gcc/cp/ChangeLog
gcc/cp/method.c
gcc/testsuite/ChangeLog
gcc/testsuite/g++.dg/cpp0x/inh-ctor32.C [new file with mode: 0644]