This patch introduces `--enable-experimental-noncopyable-generics` for
the build script. It replaces
`--swift-stdlib-experimental-noncopyable-generics`
The old build option only enables the feature when building the
stdlib, but if we've built the stdlib with NoncopyableGenerics, the
compiler should be hardwired to have that feature enabled, too.
This patch also introduces the `noncopyable_generics` lit parameter, so
that tests assuming the system was built with the feature can live
in-tree and be tested, if they specify `REQUIRES: noncopyable_generics`.
Obsolete the `-enable-swift3-objc-inference` option and related options by
removing support for inferring `@objc` attributes using Swift 3 rules.
Automated migration from Swift 3 has not been supported by the compiler for
many years.
This is a temporary measure until I get a chance to fix the symbol
mangling. This round-tripper is exactly flagging the current
known issue in that all of the symbols get extra `Copyable` and
`Escapable` requirements mangled into them, and thus reconsituting the
type from the mangled name doesn't give you the same type back.
While `add_swift_target_library` has code to add a dependency from the
install component to the target, similar code was missing from
`add_swift_target_library_single`, probably because
`add_swift_target_library` calls `add_swift_target_library_single`, so
the extra dependency is not necessary.
However, there's usages of `add_swift_target_library_single` outside
`add_swift_target_library` which were creating targets that were not
dependencies of their install components. Some of those cases are the
embedded stdlib targets, which are installed as part of the `stdlib`
component.
It normally does not matter when using `build-script`, because those
targets are build as part of `all`, but it does matter if one is using
CMake/Ninja directly or in cases where `build-script` is not used.
Trying to use targets like `install-stdlib` will had missed building the
embedded stdlib, and failed the installation.
which executor for which type of setting, is consolidated and we have a
single knob we use to determine when to use dispatch as our global
executor.
Radar-Id: rdar://problem/119416196
Swift has some module maps it overlays on Linux and Windows that groups all of the C standard library headers into a single module. This doesn’t allow clang and C++ headers to layer properly with the OS/SDK modules. clang will set -fbuiltin-headers-in-system-modules as necessary for Apple SDKs, but Swift will need to pass that flag itself when required by its module maps.
This is needed for some Apple internal configurations that needs to build the
standard library in pieces to construct an SDK.
Given the limited audience, only introduce this flag in CMake.
Addresses rdar://118178539
Add a `SWIFT_STDLIB_OVERRIDABLE_RETAIN_RELEASE` CMake option. When set to true, swift_retain/release and the other functions in InstrumentsSupport.h can be overridden by setting the appropriate global function pointer, as is already the case. When set to false, those function pointers are removed and the functions always go into the default implementation.
Set `SWIFT_STDLIB_OVERRIDABLE_RETAIN_RELEASE` to false when building the minimal stdlib, and set it to true otherwise by default.
rdar://115987924
The CMake flag `DEPLOYMENT_VERSION_OSX` is currently only passed to the C compiler. This change makes sure it is also passed to the Swift compiler, e.g. when building Swift-only targets like Cxx or CxxStdlib.
rdar://117699474
Conflicts:
- `lib/AST/TypeCheckRequests.cpp` renamed `isMoveOnly` which requires
a static_cast on rebranch because `Optional` is now a `std::optional`.
This would be needed to stop using `swift-api-extract` in some
internal configurations.
Given the limited scope, only add this as a CMake flag.
Addresses rdar://117019309
If we're bootstrapping *and* skip-early-swiftsyntax is enabled, the
build can fail while trying to build target executables because we
haven't built a copy of libswiftCore yet but *the compiler* refers
to it.
This is "fixed" in other places by setting LD_LIBRARY_PATH, but we
don't want or need to do that here; we just want to delay building
these executables until after libswiftCore is available.
rdar://116485713
Turn on frame pointers for the Swift runtime libraries. This makes
backtraces that go through the runtimes more reliable without having
to parse DWARF data.
rdar://116112040
This was causing `swift-backtrace` to crash when linked with the static
version of the runtime, because the runtime then couldn't locate any of
the necessary metadata.
rdar://115278959
This adds a new binary, `swift-backtrace-static`, to the build. The runtime
will not by default use this binary as the backtracer, but if you want to
statically link your own binaries against the standard library you can copy
`swift-backtrace-static` rather than `swift-backtrace` alongside your binary,
naming it `swift-backtrace`, and the runtime should find and use it, which
will mean you don't need to have `libswiftCore.so` et al installed.
rdar://115278959
