On 01/25/2017 05:09 PM, Jason Merrill wrote:
Something smaller would be moving the call to deduce_inheriting_ctor
to build_over_call; we can get away with that because calling is the
only way to refer to a constructor. What do you think of this
approach?
LGTM, thanks!
nathan
--
Nathan Sidwel
On Wed, Jan 11, 2017 at 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
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 i
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
On 12/19/2016 08:09 AM, Nathan Sidwell wrote:
this patch fixes 78771, were an assert fires due to recursive
instantiation of an inheriting ctor. Normally when a recursive
instantiation is needed, we've already constructed and registered the
declaration, so simply return it. For ctors though we
Jason,
this patch fixes 78771, were an assert fires due to recursive
instantiation of an inheriting ctor. Normally when a recursive
instantiation is needed, we've already constructed and registered the
declaration, so simply return it. For ctors though we need to construct
the clones after w
