Rather than directly using the extension `__builtin_expect`, use a macro
to permit the removal of the builtin on compilers which do not support
this (i.e. cl). This permits us to build the swift compiler with MSVC
again.
The functions in LibcShims are used externally, some directly and some through @inlineable functions. These are changed to SWIFT_RUNTIME_STDLIB_SPI to better match their actual usage. Their names are also changed to add "_swift" to the front to match our naming conventions.
Three functions from SwiftObject.mm are changed to SPI and get a _swift prefix.
A few other support functions are also changed to SPI. They already had a prefix and look like they were meant to be SPI anyway. It was just hard to notice any mixup when they were #defined to the same thing.
rdar://problem/35863717
- `_swiftEmpty{Array,Dictionary,Set}Storage` should be marked with `SWIFT_RUNTIME_STDLIB_INTERFACE` so that they can be linked from the standard library implementation.
- Runtime export symbols ought to have protected visibility.
Other changes:
1) Minimize unified versus build-script build differences.
2) Stop trying to make runtime variables have "protected" visibility.
This combination is meaningless and lld rightly complains.
Finally, this blog post is worth reading:
http://www.airs.com/blog/archives/307
* [runtime] Clean up symbols in error machinery.
* [runtime] Clean up symbols in Foundation overlay.
* [runtime] Clean up symbols in collections and hashing.
* [runtime] Remove symbol controls from the Linux definition of swift_allocError.
* [tests] Add more stub functions for tests that link directly to the runtime.
When the standard library is built dynamically on COFF targets, the public
interfaces must be decorated in order to generate a proper DLL which can be
confused by the dependent libraries. When the exported interface is used, it
must be indirectly addressed. This can be done manually in code or the MS
extension of `__declspec(dllimport)` may be used to indicate to the compiler
that this symbol be addressed indirectly. This permits building more pieces of
the standard library dynamically on Windows.
Currently, LLVM supports the current three common object file formats (COFF,
ELF, MachO). Unfortunately, COFF does not provide a compiler macro to identify
the object file format. If neither `__MACH__` nor `__ELF__` is defined, then
assume that the object file format being used is COFF. Within the COFF target
handling, do not use `__declspec(dllexport)` for cygwin targets.
Declarations with protected visibility are assumed to be defined
within the current linkage unit, so we have to use default visibility
if we don't know that we're building that. Teach the shim
visibility header to only use protected visibility when the
__SWIFT_CURRENT_DYLIB macro is defined, and define it when building
the standard library. Eventually we should change
SWIFT_RUNTIME_STDLIB_INTERFACE and SWIFT_RUNTIME_EXPORT to be
parameterized by the defining dylib so that this works for all the
overlay stubs, too; for now, special-casing swiftCore is necessary
to fix the LInux build.
This is a purely mechanical change replacing the attributes with the reserved
spelling. Compilers are to not error when they encounter a reserved spelling
for an attribute which they do not support.
The general rule here is that something needs to be SWIFT_CC(swift)
if it's just declared in Swift code using _silgen_name, as opposed to
importing something via a header.
Of course, SWIFT_CC(swift) expands to nothing by default for now, and
I haven't made an effort yet to add the indirect-result / context
parameter ABI attributes. This is just a best-effort first pass.
I also took the opportunity to shift a few files to just implement
their shims header and to demote a few things to be private stdlib
interfaces.
...and explicitly mark symbols we export, either for use by executables or for runtime-stdlib interaction. Until the stdlib supports resilience we have to allow programs to link to these SPI symbols.
