Do all SIL declarations in IRGen carry a mangled name? If so, how would maintaining a global map from module names to SILModules fare as an implementation strategy (rather than maintaining a reference on each underlying declaration type)?
Sounds like a considerable amount of work that would be better put into just maintaining a module pointer.
Okay, in that case and if it's relatively simple, would you be able to provide a rough implementation design? Looking through the LinkEntity types, all the Decl types and ProtocolConformances already carry a DeclContext and SILFunctions have SILModules (and in turn ModuleDecls), but for any of the TypeBase*-backed cases I can't see a way to get to either a ModuleDecl or SILModule.
(I realise it's just before WWDC and Apple people are likely to be fairly busy, so this isn't urgent if you don't have the time right now.)
There's a bit of confusion here worth clearing up: a SILModule contains "all the SIL you are working with", not "all the SIL from a particular module". (It's closer to ASTContext than ModuleDecl in that way, but LLVM has both LLVMContext and llvm::Module, and a SILModule definitely depends on ASTContext, so…)
It'd be easy enough to put the owning SerializedASTFile into SILFunction, perhaps instead of or inside the DebugScope. But the information isn't there now.
2 Likes
To be clear, my suggestion was that an individual SILFunction, SILGlobalVariable, or (maybe) SILWitnessTable would have a ModuleDecl* for the language module which defines the symbol, which should definitely be sufficient to tell us how to generate code which links against it.
The ModuleDecl* of a SILModule is the module currently being emitted. I don't think that's actually a good concept to have at the SIL level — we should be able to link multiple modules and emit them together, without necessarily giving precedence to one — but it's at least meaningful in some way.
1 Like
Looking through the code, SILWitnessTable and SILFunction have getDeclContext(), while for SILGlobalVariable you could use getLocation()->getAsDeclContext(). Would the result of getParentModule() on the resulting DeclContext give us what we want? I see there are comments saying "Debug info only", but I've also seen other comments saying that it's an error if the debug info isn't present.
If that would work, I think the only changes I'd need to make would be perhaps exposing getters on each of those types and then implementing a getModuleDecl() method on LinkEntity that switches over the possible cases.
I don't think that DC is reliable (or well-defined) enough that I'd want to use it for linking.
Making SIL entities carry a module properly shouldn't be a ridiculous amount of work; it's mostly just (1) making intelligent decisions at the various places that create functions (of which there really aren't that many) and (2) preserving the information through the non-in-memory representations (serialized and textual SIL).
If you have that then yes, I think it would be quite reasonable to have a getDefiningModule() method on LinkEntity. (You might need to pass in the IGM so that some of the on-demand cases there can properly return the current module.)
1 Like
I've filed a bug: [SR-10797] SIL Declarations should include their defining ModuleDecl · Issue #53187 · apple/swift · GitHub
While it may not be much work for an experienced contributor, I feel I currently lack the knowledge to make the intelligent decisions necessary. I've spent an hour or so looking over the various call sites and don't know which types and where on the types I should be looking to find the correct ModuleDecls; I don't currently have the experience with the codebase.
If someone more knowledgeable finds the time to take this on it would be very much appreciated, since it should unblock SwiftPM on Windows. Otherwise, I may revisit this in a few weeks and rely on local-toolchain workarounds in the meantime.
Understandable, thanks.