On 7/7/20 3:36 PM, Patrick Palka wrote:
On Tue, 7 Jul 2020, Jason Merrill wrote:
On 7/7/20 9:33 AM, Patrick Palka wrote:
We are ICEing in the testcase below because we pass the
yet-uninstantiated class type A of the PARM_DECL b to
is_really_empty_class from potential_rvalue_constant_expression
On Tue, 7 Jul 2020, Jason Merrill wrote:
> On 7/7/20 9:33 AM, Patrick Palka wrote:
> > We are ICEing in the testcase below because we pass the
> > yet-uninstantiated class type A of the PARM_DECL b to
> > is_really_empty_class from potential_rvalue_constant_expression when
> > parsing the requirem
On 7/7/20 9:33 AM, Patrick Palka wrote:
We are ICEing in the testcase below because we pass the
yet-uninstantiated class type A of the PARM_DECL b to
is_really_empty_class from potential_rvalue_constant_expression when
parsing the requirement t += b.
Why are we getting to potential_rvalue_const
On Tue, 7 Jul 2020, Patrick Palka wrote:
> We are ICEing in the testcase below because we pass the
> yet-uninstantiated class type A of the PARM_DECL b to
> is_really_empty_class from potential_rvalue_constant_expression when
> parsing the requirement t += b.
>
> This patch fixes the ICE by guard
We are ICEing in the testcase below because we pass the
yet-uninstantiated class type A of the PARM_DECL b to
is_really_empty_class from potential_rvalue_constant_expression when
parsing the requirement t += b.
This patch fixes the ICE by guarding the problematic call to
is_really_empty_class with
