On 2025-11-28 15:32, Patrick Palka wrote:
> Hey Egas, thanks for the patch!
>
> On Fri, 28 Nov 2025, Egas Ribeiro wrote:
>
> > Lambdas used as non-type template arguments to concepts are wrapped
> > in TARGET_EXPR nodes. After r16-5115 changed convert_template_argument
> > to call instantiate_non_dependent_expr_internal on non-dependent
> > expressions, these TARGET_EXPRs began hitting the default case in
> > tsubst_expr, causing an ICE. Add proper TARGET_EXPR handling.
>
> TARGET_EXPR is deliberately not handled by the tsubst routines because
> it is considered a non-templated tree (and the tsubst routines naturally
> expect to see only templated trees). TARGET_EXPR represents temporary
> objects, but we want the templated representation of expressions to
> mirror their syntactic, written form, not their underlying semantic
> representation in terms of temporary objects etc.
>
> The problem here seems to be that when parsing A<[]{}>, we haven't yet
> seen the 'auto' that indicates an abbreviated function template, so we
> haven't switched to being in a template context yet, and we therefore
> represent the []{} template argument as a non-templated tree. Once
> we see the auto we switch to a template context but we still build up
> the type-constraint using the non-templated []{} tree. Later when
> checking the type-constraint via tsubst, it sees this non-template []{}
> tree, which contains a TARGET_EXPR, and we ICE.
>
> We somehow need to switch to being in a template context _before_
> parsing the A<[]{}> type-constraint so that it's represented as
> a templated tree. In order to do that I guess we need to do some
> sort of lookahead of to detect an abbreviated funciton template (
> indicated by an 'auto' function parameter), which admittedly seems
> quite tricky :/
>
> In the meantime I think it'd be good to document in tsubst_expr that
> TARGET_EXPR is deliberately not handled since it's not a valid templated
> tree.
>
> Wonder what Jason thinks
Thanks for the detailed explanation Patrick! That makes a lot of sense -
I hadn't considered that the parser hasn't switched to template context
yet when parsing A<[]{}>, though i did suspect TARGET_EXPR could be
wrong for this lambda case.
Implementing some form of lookahead sounds like the right approach, but
it does seem tricky to do correctly.
Happy to wait for Jason's input on whether to go with a temporary
workaround (with a comment explaining the underlying issue) or if there's
a better solution to apply here.
Thanks!
Egas
