OK.
On Tue, Apr 11, 2017 at 1:13 PM, Jakub Jelinek wrote:
> On Tue, Apr 11, 2017 at 03:41:39PM +0200, Jakub Jelinek wrote:
>> So like this? Or just type_dependent_expression_p check rather than
>> both?
>
> To answer myself, testing there both type_dependent_expression_p
> and value_dependent_ex
On Tue, Apr 11, 2017 at 03:41:39PM +0200, Jakub Jelinek wrote:
> So like this? Or just type_dependent_expression_p check rather than
> both?
To answer myself, testing there both type_dependent_expression_p
and value_dependent_expression_p for value_expr breaks
the lambda-generic-const2.C testcase
Hi!
On Mon, Apr 10, 2017 at 04:48:43PM -0400, Jason Merrill wrote:
> On Mon, Apr 10, 2017 at 4:35 PM, Jakub Jelinek wrote:
> > - store_decomp_type (v[i], eltype);
> > + if (!processing_template_decl)
> > + store_decomp_type (v[i], eltype);
>
> This spot shouldn't change
On Mon, Apr 10, 2017 at 04:48:43PM -0400, Jason Merrill wrote:
> On Mon, Apr 10, 2017 at 4:35 PM, Jakub Jelinek wrote:
> > - store_decomp_type (v[i], eltype);
> > + if (!processing_template_decl)
> > + store_decomp_type (v[i], eltype);
>
> This spot shouldn't change; we
On Mon, Apr 10, 2017 at 4:35 PM, Jakub Jelinek wrote:
> - store_decomp_type (v[i], eltype);
> + if (!processing_template_decl)
> + store_decomp_type (v[i], eltype);
This spot shouldn't change; we do want to remember the decltype even
in a template.
> @@ -3935,7 +3935,10
Hi!
The following testcase ICEs, because when cp_finish_decomp is called
during parsing with processing_template_decl, but decl is not type
dependent, we finalize it at that point and when we try to do it again
during tsubst time, it doesn't find the expected trees (e.g. DECL_VALUE_EXPR
of the exp
