On Tue, Apr 26, 2016 at 8:49 AM, John McCall via swift-dev <swift-dev@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 _______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
