The purpose of this module is to prespecialize generic methods in the
stdlib. All symbols exposed by the ABI must be explicitly identified
to maintain ABI compatibility. Some of those ABI-exposed symbols
reference internal stdlib types.
Given that we want the prespecialized code to live in the separate
SwiftOnoneSupport library, and we want the module to explicitly list
all the symbols required for ABI stability, there's no way around
disabling access control when building it. In fact, that flag does
precisely what we want.
This should be harmless because
- no one imports SwiftOnoneSupport.swiftmodule
- these internal symbols were always being exposed in
SwiftOnoneSupport.dylib, so nothing changes there
When compiling SwiftOnoneSupport, issue errors for missing functions which are expected in the module.
This ensures ABI compatibility.
rdar://problem/48924409
Magic symbols of the form $ld$install_name$os9.0$@rpath/libswiftCore.dylib tell the linker to use that install name when targeting that OS version. Use these symbols to specify an @rpath install name for all back-deployment libraries when targeting watchOS 2.0-5.1, iOS 7.0-12.1, and macOS 10.9-10.14.
rdar://problem/45027809
The debug build of the standard library on Windows does not generate the
import library for SwiftOnoneSupport which prevents the build of debug
programs against the debug runtime. Because the linker must find the
import library in order to satisfy the forced link that we emit for the
link against the SwiftOnoneSupport library, without this, the build is
not usable. Furthermore, this requires a debug build of the runtime
since in the optimized build, the interfaces that this library provides
are not provided by swiftCore and this supplements the library to allow
building the debug program.
The key thing here is that all of the underlying code is exactly the same. I
purposely did not debride anything. This is to ensure that I am not touching too
much and increasing the probability of weird errors from occurring. Thus the
exact same code should be executed... just the routing changed.
TBD validation is effectively an expensive assertion, and is currently only
tuned for Apple platforms. However, we don't want it to regress more, and it
would be nice to start getting validation from people using master
snapshots. Together, this means that turning it on by default for the cases
mentioned above is an appropriate course of action.
At the very least, this has the benefit of running validation across the stdlib,
the overlays and the whole testsuite on each build, so people making changes to
the compiler that change symbols are hopefully alerted.
One limitation here is that this is only validating that the TBD is a superset
of the true set of symbols: it could include spurious symbols that aren't
actually in the binary. This case is less problematic for Swift than symbols
missing from the TBD file, and so we've focused energy on this. Once we've fixed
the extra-symbols problems and are confident in it, this validation can be
upgraded to validate that too.
Half of rdar://problem/40431434.
These changes caused a number of issues:
1. No debug info is emitted when a release-debug info compiler is built.
2. OS X deployment target specification is broken.
3. Swift options were broken without any attempt any recreating that
functionality. The specific option in question is --force-optimized-typechecker.
Such refactorings should be done in a fashion that does not break existing
users and use cases.
This reverts commit e6ce2ff388.
This reverts commit e8645f3750.
This reverts commit 89b038ea7e.
This reverts commit 497cac64d9.
This reverts commit 953ad094da.
This reverts commit e096d1c033.
rdar://30549345
This patch splits add_swift_library into two functions one which handles
the simple case of adding a library that is part of the compiler being
built and the second handling the more complicated case of "target"
libraries, which may need to build for one or more targets.
The new add_swift_library is built using llvm_add_library, which re-uses
LLVM's CMake modules. In adapting to use LLVM's modules some of
add_swift_library's named parameters have been removed and
LINK_LIBRARIES has changed to LINK_LIBS, and LLVM_LINK_COMPONENTS
changed to LINK_COMPONENTS.
This patch also cleans up libswiftBasic's handling of UUID library and
headers, and how it interfaces with gyb sources.
add_swift_library also no longer has the FILE_DEPENDS parameter, which
doesn't matter because llvm_add_library's DEPENDS parameter has the same
behavior.
This reverts commit 1b3d29a163, reversing
changes made to b32424953e.
We're seeing a handful of issues from turning on inlining of generics,
so I'm reverting to unblock the bots.
As a first step to allowing the build script to build *only*
static library versions of the stdlib, change `add_swift_library`
such that callers must pass in `SHARED`, `STATIC`, or `OBJECT_LIBRARY`.
Ideally, only these flags would be used to determine whether to
build shared, static, or object libraries, but that is not currently
the case -- `add_swift_library` also checks whether the library
`IS_STDLIB` before performing certain additional actions. This will be
cleaned up in a future commit.
Pre-specializations were only used by Onone builds, but were kept inside the standard library dylyb anyways. This commit moves all the pre-specializations into a dedicated Swift module and a dynamic library, which are only used by Onone builds.
This reduces the code size of libswiftCore.dylib by 4%-5%.
Pre-specializations were only used by Onone builds, but were kept inside the standard library dylyb anyways. This commit moves all the pre-specializations into a dedicated Swift module and a dynamic library, which are only used by Onone builds.
This reduces the code size of libswiftCore.dylib by 5%.
