On 2/9/24 11:55, Patrick Palka wrote:
On Fri, 9 Feb 2024, Jason Merrill wrote:
On 2/9/24 10:51, Patrick Palka wrote:
It turns out that with modules we can call mangle_decl recursively,
which is a problem because the global mangling state isn't recursion
aware. The recursion happens from write_closure_type_name, which calls
lambda function, which performs name lookup, which can trigger lazy
loading,
Hmm, why would looking for a member of a closure trigger lazy loading?
No idea.. We could sidestep lazy loading here by using
get_class_binding_direct instead of lookup_member in lambda_function,
but I don't know if if that would have unintended consequences.
Seems worth trying; the lazy load should still get triggered by some
other name lookup.
FWIW the closure for which op() lookup triggers lazy loading is for a
non-generic lambda from an instantiated function template scope and
captures another closure object that captures a dependent function
parameter (_overwrite in libstdc++'s <format> line 1607). So I'd guess
the entity dependency graph is pretty complicated..
And it seems lazy loading from maybe_lazily_declare can be quite
recursive, I wonder if that's expected? I attached the full backtrace
that leads mangle_decl recursion, and there's about 15 recursive calls
to maybe_lazily_declare in this backtrace which seem to go through
check_local_shadow. Maybe we can reduce this somehow?
I think we shouldn't bother with check_local_shadow in a clone or
instantiation, only when actually parsing.
Jason
