[swift-dev] swift (ABI) and Windows

[John McCall]

> On Oct 7, 2016, at 4:08 PM, Paul Menage <paul at paulmenage.org> wrote:
> On Tue, Apr 26, 2016 at 8:49 AM, John McCall via swift-dev
> <swift-dev at swift.org> wrote:
>> 
>> 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.

> 
> - 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