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.
PR #14306 fixed the problem in https://bugs.swift.org/browse/SR-6878 but
included a comment about mysterious behavior on macOS. I did some
investigation and found that Clang assumes that Darwin platforms use
a different name for LLD. My impression is that LLD is not yet ready for
prime time on Darwin, so leaving it disabled for Apple platforms seems
like the right thing for now. This just updates the comments to explain
what will need to change whenever someone wants to reenable it.
rdar://problem/37053028
ndk14 introduced "unified headers" which merged the headers for all
different API versions into one directory which effectively split the
"SWIFT_SDK_ANDROID_ARCH_${ARCH}_PATH" into two different directories.
Add include and library specific paths to various compilation and link
invocations across the Swift project to account for this change. Remove
some broken sysroot/sdk specific settings.
Report the ICU I18N and UC include paths and the library path. This
makes it obvious when the variable is not defined and more importantly
makes it easier to see what the paths are being used particularly when
cross-compiling for multiple architectures.
This also fixes several issues where attribute arguments could not be
parsed as a TokenList since some of its arguments already had structure
and were not tokens
`-ivfsoverlay` is no longer passed through to the driver with
`clang-cl`. Explicitly mark it as a clang option to ensure that the
option is handled properly. This repairs the build on Windows.
StdlibUnittest uses gyb to avoid duplicating many source-context
arguments. However, this means that any test that wishes to add new
expect helpers has to also be gybbed. Given that this structure hasn't
changed in years, and we should have a real language support
eventually, de-gyb it.
The `-sdk` parameter to the swift compiler causes problems when
cross-compiling to Windows on Linux. Because the host follows the
traditional unix layout but the headers do not correspond to the target
environment, there are conflicting definitions and incorrect definitions
of basic types imported from C. Ensure that we do not pass the `-sdk`
parameter to allow correctly building the libraries for the target.
Create a list that makes it easy to see and add options to the CMake
macro when building. This makes the `cmake_parse_arguments` call much
more legible by adhering to the CMake recommendations. NFC.
General purpose cross compilation from host x to targets a,b,c will
require the ability to have multiple architectures passed to
`configure_sdk_unix`. Simply change the function to accept multiple
archs.
- Re-enable the use of folders with the USE_FOLDER setting. This got
lost a while ago when we stopped including LLVM's top-level
CMakeLists.txt.
- Put a bunch of new targets into folders.
Should not affect the built product and definitely shouldn't affect
anyone not building with Xcode (or MSVC, I guess).
Newer SDKs have the ability to disable the static RTTI usage as well as
the dynamic. We had to enable the use of static RTTI previously for the
use of `std::function`. Disable the static RTTI if possible.
Cross-compilation for multiple architectures & sdks require various
variables to be split to specify the arch/adk variant being focused on.
This change modifies various uses of the `SWIFT_SDK_${SDK}_PATH` to
`SWIFT_SDK_${SDK}_ARCH_${ARCH}`
