ping?
On 01/11/2017 10:53 AM, Nathan Sidwell wrote:
On 01/04/2017 12:53 AM, Jason Merrill wrote:
Hmm, that seems like where the problem is. We shouldn't try to
instantiate the inheriting constructor until we've already chosen the
base constructor; in the new model the inheriting constructor is just an
implementation detail.
Oh what fun. This testcase behaves differently for C++17, C++11
-fnew-inheriting-ctors and C++11 -fno-new-inheriting-ctors compilation
modes.
Firstly, unpatched G++ is fine in C++17 mode, because:
/* In C++17, "If the initializer expression is a prvalue and the
cv-unqualified version of the source type is the same class as the
class
of the destination, the initializer expression is used to
initialize the
destination object." Handle that here to avoid doing overload
resolution. */
and inside that we have:
/* FIXME P0135 doesn't say how to handle direct initialization from a
type with a suitable conversion operator. Let's handle it like
copy-initialization, but allowing explict conversions. */
That conversion lookup short-circuits the subsequent overload resolution
that would otherwise explode.
Otherwise, with -fnew-inheriting-ctors, you are indeed correct. There
needs to be a call to strip_inheriting_ctors in deduce_inheriting_ctor.
With -fno-new-inheriting-ctors we need the original patch I posted
(included herein). I suppose we might be able to remove the assert from
strip_inheriting_ctors and always call that from deduce_inheriting_ctor,
but that seems a bad idea to me.
I was unable to produce a c++17 testcase that triggered this problem by
avoiding the above-mentioned overload resolution short-circuiting.
As -fnew-inheriting-ctors is a mangling-affecting flag, I guess we're
stuck with it for the foreseable future.
ok?
nathan
--
Nathan Sidwell
