[swift-dev] swift (ABI) and Windows

[Paul Menage]

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:

- 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