mirror of
https://github.com/carbon-language/carbon-lang.git
synced 2026-10-05 22:02:55 +01:00
David BlaikieandRichard Smith
3f9fc633fe
This addresses/avoids the duplicate import of vtables. I went through a few iterations/etc along the way and left them in the commit history for the PR in case any of them are useful to illustrate how I got here, or worth revisiting. Essentially I ended up with a circularity in importing - importing the class imported the vtable_decl which imported the virtual functions - and then pending specifics of the virtual functions needed the self specific of the enclosing class which wasn't ready yet. Adding ImportRef to the vtable_decl to break the cycle caused me trouble when naming the vtable_decl instructions - so I tried making the functions in the vtable unloaded ImportRefs instead. That worked, but meant that importing a class still was doing O(number of vtable entries) even if the vtable wasn't used. So I revisited the lazy vtable_decl - figured out how to make the naming work (when building the vtable_ptr, even though the vtable_decl doesn't have to be loaded for the vtable_ptr, I force it to be loaded anyway, to load the vtable so it's usable by lowering, etc). And then I could go back to the old non-lazy loaded vtable entries (using some loaded ImportRefs in the cases where we needed them/had already adopted them). Then thinking about the VtablePtr instruction, went back/forth on exactly what it needed - went from VtablePtr's member being a VtableDecl InstId, to a ClassId, then back to a VtableId as it was before this patch. Naming the instructions has one oddity, that the VtableDecl and VtablePtr instructions seem to need to add the pending name for the VtableId - despite not using the VtableId in their own name - should the inst namer be doing this work for parameters of instructions rather than requiring the inst to do it deliberately? (or am I holding it wrong in some way?) --------- Co-authored-by: Richard Smith <richard@metafoo.co.uk>