ninstantiated template by checking e.g. value_dependent_expression_p.
This too is sufficient to fix the testcase (since f isn't a template)
and survives bootstrap and regtest.
I think this is an orthogonal issue -- can we remove it from this patch?
Done.
-- >8 --
Subject: [PATCH] c++
)
> > and survives bootstrap and regtest.
>
> I think this is an orthogonal issue -- can we remove it from this patch?
Done.
-- >8 --
Subject: [PATCH] c++ modules: lazy loading from within template [PR99377]
Here when lazily loading the binding for f at parse time from the
tem
On 10/4/22 13:36, Patrick Palka wrote:
Here when lazily loading the binding for f at parse time from the
template g, processing_template_decl is set and thus the call to
note_vague_linkage_fn from module_state::read_cluster has no effect,
and we never push f onto deferred_fns and end up never emi
On Tue, 4 Oct 2022, Patrick Palka wrote:
> Here when lazily loading the binding for f at parse time from the
> template g, processing_template_decl is set and thus the call to
> note_vague_linkage_fn from module_state::read_cluster has no effect,
> and we never push f onto deferred_fns and end up
Here when lazily loading the binding for f at parse time from the
template g, processing_template_decl is set and thus the call to
note_vague_linkage_fn from module_state::read_cluster has no effect,
and we never push f onto deferred_fns and end up never emitting its
definition.
ISTM the behavior
