On 03/06/2016 09:30 AM, Patrick Palka wrote:
On Sun, Mar 6, 2016 at 1:42 AM, Jason Merrill <ja...@redhat.com> wrote:
On 02/08/2016 12:19 AM, Patrick Palka wrote:
Here, we are calling template_class_depth on a FIELD_DECL corresponding
to a lambda that is used inside variable template. template_class_depth
however does not see that this FIELD_DECL is used inside a variable
template binding because its chain of DECL_CONTEXTs does not include the
corresponding VAR_DECL. So template_class_depth returns the wrong
template nesting level which causes its callers to malfunction. In
particular we strip a template argument level in
tsubst_copy [FIELD_DECL] when we shouldn't have.
This patch makes template_class_depth look at a lambda type's
LAMBDA_TYPE_EXTRA_SCOPE field instead of its TYPE_CONTEXT, so that it
can iterate into an enclosing variable template, if applicable.
Tested on x86_64-pc-linux gnu, no new regressions. Also tested against
Boost. Is this OK to commit?
This is breaking several lambda testcases with -fconcepts on;
LAMBDA_TYPE_EXTRA_SCOPE can also be a FIELD_DECL or PARM_DECL. Let's just
check DECL_P.
Sorry about that.
In the case of LAMBDA_TYPE_EXTRA_SCOPE being a PARM_DECL, could there
be a chance that this PARM_DECL has a non-null DECL_LANG_SPECIFIC? If
so it looks like we could still later ICE in get_template_info (called
from template_class_depth) when we try to get at its
DECL_TEMPLATE_INFO, an accessor that cannot be used on PARM_DECLs. So
I wonder if maybe get_template_info() should also be adjusted to
handle the case of being given a PARM_DECL which may have a non-null
DECL_LANG_SPECIFIC:
Looks good.
Jason
