I think it's reasonable to assume that @_silgen_name is not being used for
objects that are external to the declaring module. That is, the
implementation model is that those declarations really are declaring a Swift
function; it just happens that the actual body (if not provided) is provided
magically. That should work for all the standard library use cases.So what's the cleanest way to make this work in practice? I
experimented with the following hack, which worked for building the
stdlib and the SDK overlay but which is full of layer violations:
Sorry, I could've been more clear. For ordinary declarations, we know exactly
which module defines any symbols associated with them because we know
which module the declaration is in and ordinary declarations are always definitions.
A @_silgen_name declaration isn't itself a definition, but it's actually still
reasonable to assume that it's defined by the current module, which means
that as far as knowing where the symbol is defined goes, it really *is* a definition.
So there's no difference.
The right solution is for SILFunctions (well, at least the ones with public linkage)
to always carry a reference to their defining module. IRGen can then just key off
of that + its knowledge of the current module when emitting the llvm::GlobalValue
for the thing.
John.
ยทยทยท
On Oct 7, 2016, at 4:08 PM, Paul Menage <paul@paulmenage.org> wrote:
On Tue, Apr 26, 2016 at 8:49 AM, John McCall via swift-dev > <swift-dev@swift.org> wrote:
- Add a symbol tracking hook in SILGenNameAttr, such that when the
hook is active, whenever we encounter a _silgen_name() declaration we
record it in a set.- Enable this symbol tracking just for the duration of parsing the
main module. Thus we end up with a set of all _silgen_name attributes
on functions declared in the current module, but not _silgen_name
attributes on functions imported from other modules.- At various points in lib/IRGen/GenDecl.cc
(updateLinkageForDefinition, LinkInfo::createFunction,
LinkInfo::createVariable) check whether the symbol being used is in
the list of _silgen_name attributes from the current module, and if so
ignore the dll-import tag on the symbol when setting up the
llvm::GlobalValue.It would be nicer to walk across the main module after parsing it to
find SILGenNameAttr instances, but I don't have a good idea how to
start with that. Then we could perhaps add the list of attributes to
the llvm::Module as some kind of llvm::Metadata object?Paul