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.
libswiftStdlibStubs.a is meant to be an intermediate built product
that's pulled into libswiftCore.a, not its own thing. Add a post-build
step for libswiftCore.a to pull all the object files into it from
libswiftStdlibStubs.a.
(Also, be careful only to do this for private link libraries that are
actually targets.)
<rdar://problem/23621157>
libswiftStdlibStubs.a is meant to be an intermediate built product
that's pulled into libswiftCore.a, not its own thing. Add a post-build
step for libswiftCore.a to pull all the object files into it from
libswiftStdlibStubs.a.
<rdar://problem/23621157>
When we're building the compiler, we already depend on the "swift" target.
When we're /not/ building the compiler, it had better already be there.
Squelches a CMake warning.
This was defaulting to the build directory, which isn't helpful
post-install. Set Swift libraries to look in the same directory
(ORIGIN) or /usr/lib/swift/linux.
rdar://problem/22766758
This skips the Swift standard library due to the linker script incompatibility
issue.
As before for other related projects, the build-script-impl option
'--use-gold-linker' triggers usage of this.
Swift SVN r32706
When building overlay separately, look for dylibs in the overlay
build directory first, and only then fall back to the compiler resource
directory.
If the overlay changes the ABI, we shouldn't even try the dylibs in the
compiler resource directory, that is certain to fail the build or
result in miscompiles.
rdar://22866170
Swift SVN r32382
A couple of small tweaks to _compiler_version based on review comments:
- Fix &&/|| rejection to work with _compiler_version on either side of the
expression. Also add some test cases around this.
- Use clang/LLVM facilities for isdigit and atoi.
- Assert if parsing an invalid version string and there is no diagnostic
engine.
- Clean up some crumbs in the CMake configs.
rdar://problem/22730282
Swift SVN r32212
This configuration clause will suppress lex diagnostics and skip parsing
altogether if the code under the clause isn't active - the compiler must
have a repository version greater than or equal to the version given to
_compiler_version.
This option is only meant to be used sparingly and not to track the
Swift *language* version.
Example, if using a compiler versioned 700.0.28:
#if _compiler_version("700.0.23")
print("This code will compile for versions 700.0.23 and later.")
#else
This + code + will + not + be + parsed
#endif
Included are new diagnostics for checking that the version is formatted
correctly and isn't empty.
New tests:
- Compiler version comparison unit tests
- Build configuration diagnostics
- Skipping parsing of code under inactive clauses
rdar://problem/22730282
Swift SVN r32195
This reverts commit r31313.
This change caused an unacceptable dylib size increase:
- watchOS core dylib size increased from 13 Mb to 25 Mb,
- iOS dylib size increased 40 Mb to 76 Mb.
The size change is due to change of the bitcode section size. It can be
attributed to:
- actual symbol strings that we have started to include;
- full debug info. Symbol obfuscation was also changing full debug info
in LLVM metadata into line tables.
rdar://22330874, again.
Swift SVN r31473
We will need this to switch the darwin targets over to use ICU instead of going
to NSString for string operations. The public SDK does not contain the headers
for ICU - only the dylib.
For builds using a public SDK users can specify the path to an ICU install where
the headers can be found. If this path is specified the logic will not use
internal SDK variants.
Swift SVN r31471
This is a negative version of the flag
SWIFT_EXPERIMENTAL_EXTRA_REGEXP_FLAGS. The reason why an additional flag
is needed is that cmake does not support negative regexes in the regex
string itself. Instead you need to do:
if (NOT "..." MATCHES "...")
...
endif()
This suggests that we either needed to introduce more complexity into
SWIFT_EXPERIMENTAL_EXTRA_REGEXP_FLAGS or just introduce another flag. I
decided to go with the later.
Swift SVN r31417
