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
