swift-reflection-dump, a host-side tool, requires this library that
normally builds for the configured platform. So, if the host platform
isn't configured to build for some reason, swift-reflection-dump will
fail to link.
swift-reflection-test is now the test that forks a swift executable
and performs remote reflection, making it runnable on other targets,
such as the iOS simulator.
swift-reflection-dump is now a host-side tool that dumps the remote
reflection sections for any platform binary and will continue to
link in LLVM object file support.
This necessitates finally moving lib/Refleciton into stdlib/public,
since we're linking target-specific versions of the test tool and
we would eventually like to adopt some of this functionality in
the runtime anyway.
We want to have the option of building the standard library without
-sil-serialize-all.
For now, the build crashes in the SIL verifier due to various issues;
upcoming patches will address these.
This is part of the larger goal of building the stdlib with
-enable-resilience.
Part of https://bugs.swift.org/browse/SR-267.
Using Clang to compile API notes introduces a dependency on the
underlying Clang, which can cause problems as Clang's support for API
notes evolves. Re-introduce the "-apinotes" driver flag into the Swift
driver to allow us to compile API notes, and use that (rather than
Clang) to precompile API notes for the overlays.
I am going to use the link job for limiting swift lto compile time.
The reason not to use the same variables as LLVM (i.e. LLVM_PARALLEL_LINK_JOBS)
is that Swift since it is compiling more IR may have a larger memory
representation implying less parallel linking jobs than LLVM can be used on
bots.
When I originally committed the LTO code, I tried to match the coding style of
the code right above it that enabled code coverage. Turns out that the code
coverage code did not have a weird coding style and instead just had a bug.
I fixed both of the issues and also enabled the LTO flag on non-Darwin.
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%.
This doesn't hit the runtime. I am going to try that in a little bit.
I saw some nice reductions in compile time in the SILOptimizer in the stdlib.
Specifically, we went from spending ~33 seconds in the siloptimizer -> ~23
seconds. There were other improvements as well.
Keep in mind, I have not tested this with debug info, so it may hog all of your
ram due to crazy amounts of debug info. It would be good to try and do what LLVM
does which is to compile with line tables but not full types.
rdar://24717107
The Xlinker flags were getting globbed into a single string since
we started adding current/compatibility version arguments to the
linker.
rdar://problem/24622276
The short-term goal here is to get everything compiling and all the tests
passing.
The mid-term goal is to test the performance of a resilient stdlib.
The long-term goal is to make this the default (and only) build mode.
This should be considered EXPERIMENTAL; we can't even build libSwiftCore
successfully yet.
This brings down StdlibUnittest build time to 90 seconds with either
a DebugAssert or a ReleaseAssert compiler.
The new library, StdlibCollectionTests, is only built when running
validation tests.
We don't want references to local symbols within an image to be relocatable, since this increases startup time and causes problems with relative references.
Although the user sets the option using `--sil-verify-all`, various
build scripts refer to the option as `SWIFT_VERIFY_ALL`. Code comments
indicate that this may have been a separate setting at one time.
Remove the misleading comments and unify naming with
`--sil-verify-all` and `SWIFT_SIL_VERIFY_ALL`. This more closely matches what
the option actually does (adds `-Xfrontend -sil-verify-all` to `swiftc`
invocations during the build process).
At the time this code was originally written, Swift standard
library hasn't been ported to FreeBSD, so we didn't need any
additional library. This is not true anymore, so fix it.
The `use_internal_sdk` flag has been removed from `_add_variant_link_flags` and
`_add_variant_c_compile_flags` in commit
d9bbb6caf0
In four instances where previously FALSE was given as the value for that
parameter, this value has not been removed from the call.
This causes the two functions to try to append flags to FALSE instead of the
respective link_flags and c_compile_flags variables.
