Hi all,
I've done some analysis on the proposed assembly instructions and want to discuss a little bit about how a module granularity symbol visibility solution isn't likely to work for us. We currently use an exported symbols list to control visibility of Swift symbols in our dylibs. For one such dylib, I took the existing exported symbols list and found all Swift modules which defined at least one symbol included in the current exported symbol list. The penalty of exporting all symbols from those modules is significant: we would go from exporting ~400 Swift symbols to exporting ~27,000, and I'm only looking at Swift symbols, not considering related symbols for ObjC interop.
It seems there have been a couple other requests for more fine grain symbol control: https://forums.swift.org/t/convention-thin-function-pointers/65180/8, https://forums.swift.org/t/pitch-low-level-linkage-control-attributes-used-and-section/65877?fbclid=IwAR1SSGYGOkZiD7hDnn9TH9Wh0v4S1NJa8FN5kiv6rtJ3TXP8Pu9Drl0tHi0, including suggesting an annotation that controls attributes including visibility.
@mren already mentioned it, but the concept of LTO visibility is quite important. For example, because Swift currently lacks something like this, Swift's LLVM-VFE implementation currently uses the visibility of otherwise unnecessary dispatch thunks to reason about the existence of virtual calls outside the LTO unit.
I know @mren already suggested a visibility annotation, but if any of this is compelling perhaps we might consider at least an underscored attribute to start. For instance the previous suggestion of @symbolName(swift: "swift_foo", visibility: internal) would seem suitable.