On Fri, 9 Feb 2024, Jason Merrill wrote: > 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.
Makes sense. > > > 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. Ah, this idea seems to work very nicely. I posted a new patch implementing them at https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645307.html (and a follow-up patch fixing two small bugs caught by testing fmtlib with newer -std).
