Rather than computing the triple first and passing it down to the SDK
configuration, hard code the triple into the SDK's configuration. This
is a value which is static and will allow us to configure
cross-compilation of the standard library for Linux. Although most
other targets do not support the same variety of architectures, this
enables those to be cross-compiled as well.
Remove the duplicated platform name parameter to the unix SDK
configuration.. This value is implicit currently and can be computed.
This needs to be computed to permit parallel co-installations of
architectures for targets which do not support fat binaries (i.e.
non-MachO targets).
The SDK is a sysroot. Permit the user to specify the location of the
SDK when building Linux. This is in preparation to cross-compile the
Linux standard library.
While we are exposing more control knobs to the user, we can start
simplifying `configure_sdk_unix`.
When cross-compiling the Windows standard library in release mode, we
would get undefined symbols due to LLVM invoking
`add_definitions(-D_DEBUG)`. This would change the behaviour of certain
functions from MSVCRT resulting in undefined symbols. Scrub out the
unwanted `-D_DEBUG`.
Commit to a command line option spelling so that build systems can
start testing it. I deliberately picked one of the longer names we
were considering because we can always decide to add a shorter alias,
but can't decide a shorter name was too generic.
Like the other supplementary output flags,
-emit-parseable-module-interface-path will emit a .swiftinterface file
to a particular path, while -emit-parseable-module-interface will put
it next to the main output (the one specified with -o).
rdar://problem/43776945
Merge two cases into a single case rather than keeping them separate.
Additionally check the condition early rather than perform the action
and then revert it. NFC.
Hoist out the some of the architecture independent variables outside of
the inner loop. This should simplify the logic for the function and
improve generation times. (NFC)
The SDK configuration can identify the triple for the android targets. This is
similar to the Windows behaviour. Doing so will now enable multi-architecture
builds!
The path to the SDK can be computed from the NDK. Do so to reduce the
parameters needed to pass to CMake. More importantly, this will allow building
with multiple architectures simultaneously.
The android specific configuration here is the same as the non-android in the
sense that it is setting up the triples for the target. Simply inline it as it
makes it more obvious what it is doing. This is preparatory work for adding
support for multiple architectures for Android.
This corrects the casing which would previously not match.
Unfortunately, the `MATCHES` operator also does not handle the case
insensitivity properly. This enables building just the standard library
on Linux for Windows.
This just cleans up the invocation generation for android to avoid passing in
`--sysroot=` twice to the driver with the same value. This has no impact, but
cleans up the command line so it is easier to see what is going on.
Clang's been able to read the textual format for a long time, and
indeed that's what's used in the SDK. This isn't even really a
performance win because the information is cached in PCMs.
rdar://problem/34293901
Visual Studio's compiler does not accept `-Werror=switch`. Use the equivalent
`-we4062` option instead. Avoid using the `--` separate that clang uses to
identify that the options that follow are files and not options on the Visual
Studio compiler to reduce the unnecessary spew when building on Windows.
This may not be their final destination, but at least this will
get them into built toolchains, which means it'll be easier to
do integration testing once all the other pieces are in place.
rdar://problem/43823937
When building for Windows on Windows using Visual Studio, we would attempt to
pass the clang specific flags to cl. It would then attempt to treat the overlay
definition as an input and fail. Although this shouldn't be needed on Windows,
it keeps the builds with clang similar across Linux and Windows.
Add the `-warn-implicit-overrides` flag when building the standard library
and overlays, so that each protocol member that overrides a member of an
inherited protocol will produce a warning unless annotated with either
‘override’ or ‘@_nonoverride’.
An annotation of `override` will mean that the overriding requirement will be treated identically to the overridden declaration. If for some reason a concrete type’s conformance to the inheriting protocol provides a different witness for the overriding requirement than the conformance to the inherited protocol’s witness for the overridden requirement, the witness for the inheriting (more-specialized) protocol will be ignored. A protocol requirement marked ‘override’ only makes sense when the declaration is needed to help associated type inference, which is why the ‘override’ annotations correlate so closely with ABI FIXMEs.
An annotation of `@_nonoverride` means that the two protocol requirements will be treated independently, and may be bound to different witnesses. Use `@_nonoverride` when we might need different witnesses, e.g., because the semantics of the potentially-overriding declaration differ from that of the potentially-overridden declaration. `BidirectionalCollection.index(_:offsetBy:)` is the most obvious example, because the `BidirectionalCollection` ’s version of `index(_:offsetBy:)` allows negative indices. `RandomAccessCollection` ’s version is also marked `@_nonoverride` because it is required to be asymptotically faster than the `Collection` or `BidirectionalCollection` versions.
We're not using them for anything yet, but this will exercise
-emit-interface while we're working on it and make sure that it
doesn't crash when processing complex code like the standard library.
- Get rid of the singular (*_INCLUDE_DIR and *_LIBRARY) variables and
standardize on the plural ones, since that's also what's used by
CMake's FindICU module (which was added in 3.7).
- Use PKG_CONFIG_FOUND instead of PKGCONFIG_FOUND, since that's what's
documented in CMake's FindPkgConfig module. (The latter will be set by
the find_package call, so it's not incorrect, but it's clearer to use
the documented variable.)
- Search for the headers and libraries even if pkg-config can't find the
module, since e.g. we might have ICU somewhere in our CMake search
path but might not have the pkg-config module for it. We're only using
the pkg-config results as search hints anyway. (This might result in
an empty HINTS argument to find_path and find_library, but CMake seems
to handle that fine.) *This should be the only functional change.*
- Remove ICU_${MODULE}_DEFINITIONS, since it's never used anywhere.
- Don't add the *_INCLUDEDIR and *_LIBDIR variables to the hints, since
they should be the same as the corresponding *_INCLUDE_DIRS and
*_LIBRARY_DIRS variables (since we're only searching for a single
module).
The only intended functional change, as mentioned above, is that we can
now successfully find ICU if its include and library directories are in
the CMake search path but its pkg-config module isn't, which might be
the case in certain cross-compilation or hermetic build scenarios. (It's
compounded by CMake only looking for pkg-config modules in
CMAKE_PREFIX_PATH and not CMAKE_SYSTEM_PREFIX_PATH, which I asked about
in https://cmake.org/pipermail/cmake/2018-August/068109.html).
Extract the ExternalProject handling for libdispatch needed to build
SourceKit on Linux into a separate CMake list. This will allow us to
pull in a dependency on Foundation as well to allow building SwiftSyntax
on Linux which requires Foundation. Foundation has a dependency on
libdispatch requiring that the external project handling is centralised.
* Update std lib to Swift 5.0
* Disable Unicode.* warnings for now
* Slow path to resiliently handle the case where an unknown rounding rule is passed
* Remove resilience from Encoding/DecodingError (which should only happen on slow paths anyway)
* internal typealiases now need @usableFromInline
* Force inlining on Array._owner.get
When cross-compiling or specifying a custom sysroot and desiring a
hermetic build, many CMake toolchain files will have a custom
CMAKE_FIND_ROOT_PATH and set the CMAKE_FIND_ROOT_PATH_MODE_* variables
to ONLY, meaning packages will only be searched for in the rerooted
directories. We don't want this rerooting to happen when searching for
the LLVM and clang packages though, since we're specifying our search
paths explicitly and excluding search paths from the system, and we
don't want those explicit search paths to be rerooted.
It's standard to set CMAKE_FIND_ROOT_PATH_MODE_PROGRAM to NEVER instead
of ONLY, since you usually want programs to be found for the build
system and not the host system, so the change for the llvm-config search
is not technically required. It doesn't hurt for consistency though, and
I can envision some scenarios in which it might come in handy.
