I meant, sorry about the ambiguous use of "also". :)
Oops, I see what you had meant now, sorry about the confusion :)
>
> > IIUC, dependence of
> > these two types should coincide except in the case where we're inside a
> > generic lambda within a non-templat
ve enough information to be able to resolve the
access check at parse time, I think (and so we shouldn't punt).
The below patch, which seems to pass 'make check-c++', checks the
dependence of current_nonlambda_class_type instead of that of
current_class_ptr. Does this approach seem r
eally only need to be checking
dependence of current_nonlambda_class_type here. IIUC, dependence of
these two types should coincide except in the case where we're inside a
generic lambda within a non-template class (in which case
current_class_ptr will dependent and current_nonlambda_class
On 1/6/21 1:19 PM, Patrick Palka wrote:
In the first testcase below, we incorrectly reject the use of the
protected non-static member A::var0 from C::g() because
check_accessibility_of_qualified_id, at template parse time, determines
that the access doesn't go through 'this'. (This happens becau
In the first testcase below, we incorrectly reject the use of the
protected non-static member A::var0 from C::g() because
check_accessibility_of_qualified_id, at template parse time, determines
that the access doesn't go through 'this'. (This happens because the
dependent base B of C doesn't have
