To allow tooling to analyze use of language mode and experimental/upcoming
features, add that information to the `.SWIFT_TRACE` file.
Resolves rdar://152673681.
This is the C++ driver counterpart to a change that landed in the Swift
driver a while ago to use the clang-linker to determine what the default
linker is. This is to avoid hard-coding gold, which is deprecated and
not available on some newer Linux distributions. The challenge is that
these newer Linux distributions don't already have Swift so we have to
use the old C++ driver implementation.
Use the `clang::TargetInfo` to query the target pointer size for the
given triple. This is meant to enable us to properly determine
`CMAKE_SIZEOF_VOID_P`.
Unified builds of compiler-rt together with LLVM failed for the Android SDKs. It got too complicated to redirect the way LLVM would configure the nested build-trees. Standalone builds slightly increase build time, but they turned out much simpler and we end up with less duplication of definitions.
When running the tests with a toolchain built with the "early swift
driver", we would incorrectly process the command line, losing the empty
string argument to `-sdk` which would then incorrectly process the
remainder of the command line. This allows most of the remaining tests
to pass with the early swift driver on Windows (assuming that the paths
are adjusted properly).
When enabling the early swift driver on Windows, these tests need to be
adjusted for the new driver name that is reported. Add an additional
spelling for the driver to accommodate that for the testsuite.
The legacy driver is still used to build the compiler on Windows, so we need it
to handle these new flags correctly in order to adopt them in the stdlib.
Add a new filetype for this mode option: "Raw LLVM IR". When the mode
option is emit-irgen, the new filetype will be the output kind;
conversely when determining the mode option to use, if the output kind
is the new filetype, the mode option will be emit-irgen.
The Apple SDKs have been providing the Darwin overlay since macOS 10.14.4, iOS 12.2, et al. More recently the SDK version has diverged from the Swift version making them incompatible. Stop building the overlay from Swift. Once the SDK overlays aren't being built, the clang overlays need to be built in testing.
rdar://115192929
The Apple SDKs have been providing the Darwin overlay since macOS 10.14.4, iOS 12.2, et al. More recently the SDK version has diverged from the Swift version making them incompatible. Stop building the overlay from Swift. Once the SDK overlays aren't being built, the clang overlays need to be built in testing.
%target-swift-emit-pcm doesn't use the sdk, but %target-swift-frontend does, which will cause them to have a mismatch with "builtin headers belong to system modules, and _Builtin_ modules are ignored for cstdlib headers" aka LANGOPT(BuiltinHeadersInSystemModules) aka -fbuiltin-headers-in-system-modules.
rdar://115192929
This flag was added back in 2020, but it didn't function properly, since a lot of other code in the compiler assumed the platform-default C++ stdlib until recently (https://github.com/swiftlang/swift/pull/75589).
The recommended way to use a non-default C++ stdlib in Swift now is to pass `-Xcc -stdlib=xyz` argument to the compiler.
This change removes the `-experimental-cxx-stdlib` flag.
Begin accepting `-swift-version 7` in asserts compilers so that we can begin to
test source-breaking changes intended for the next language version mode, such
as diagnostics that need to be staged in without breaking existing code. There
are no announced plans yet for a language mode after Swift 6, so 7 serves as a
placeholder for some future language mode.
Tests that wish to use `-swift-version 7` currently must be marked with
`REQUIRES: swift7` or they will fail in no-asserts bots. The simplest pattern
is probably to duplicate part or all of the pre-Swift 7 test to check that will
behave as intended in Swift 7.
PR #73725 introduced the in-process plugin server library, but the
selection of the library depends on the selected toolchain, which
depends on the compiler target, not the host. When cross-compiling (for
example from macOS to a embedded Unix target), the compiler will
incorrectly chose the `.so` file, not find it, and fail to compile
things like the `@debugDescription` macro.
Move the in-process plugin server library code from the platform
toolchains into the parent type, and code it so it uses the right name
depending on the compiler host at compilation time. This discards the
target and only relies on the compiler host for selecting the right
library.
As is, you cannot set all default fuzzer options directly using -sanitize-coverage. Because of this you can use default fuzzer sanitize-coverage args, or a limited number coverage options.
This PR adds pc-table and inline-8bit-counter as valid args to be parsed for sanitize-coverage flag. These are default fuzzer options -- and will allow customizing sanitizer-coverage in variations of fuzzer defaults. (i.e. w/o pc-table enabled).
In upstream clang the option -fno-sanitize-coverage exists to disable various coverage options. Swift currently does not have a convention of using excluding args for sanitizer flags. This aims to limit the need for a new flag by inclusively setting desired coverage up to current fuzzer defaults.
rdar://127881891
When testing different linkers, it's sometimes useful to run the tests
with `SWIFT_DRIVER_TEST_OPTIONS=" -use-ld=<linker>"`. If we do this,
it will break a handful of tests because they expect the compiler driver
to choose an appropriate linker automatically.
To avoid having these fail, detect when someone has done this, and
set a new feature, `linker_overridden`, then mark the tests in question
with `UNSUPPORTED: linker_overridden`.
rdar://123504095
We changed to `llvm.compiler.used` because of the behaviour of `gold`,
which refuses to coalesce sections that have different `SHF_GNU_RETAIN`
flags, which causes problems with metadata.
Originally I thought we were going to have to generate two sections
with distinct names and have the runtime look for both of them, but
it turns out that the runtime only wants to see sections that have
`SHF_GNU_RETAIN` in any case. It's really the reflection code that
is interested in being able to see non-retained sections. The upshot
is that we don't need to use `llvm.compiler.used`; it's just fine if
we have duplicate sections, as long as the reflection code looks for
them when it's inspecting an ELF image.
This also means we no longer need to pass `-z nostart-stop-gc` to the
linker if we're using `lld`.
rdar://123504095
When using VS Code, it semi-frequently happens that sourcekitd is reading the output file map and the memory buffer containing the memory buffer containing the output file map is not complete and terminates at distinct powers of 2. I managed to attach a debugger once and the memory buffer containing the output file had size 0x3000 = 12288 while the actual output file map is 20319 bytes large. One hypothesis for this is that the read of output file map is racing with a write from a SwiftPM build but I haven’t been able to confirm it.
In either case, the result is that the output file map buffer ends with an unterminated string literal, which causes `getKey()` or `getValue()` in the JSON parser to return `nullptr` and then consequently hits an assertion failure in `dyn_cast`. Add a check for nullptr before invoking `dyn_cast` just like we do it in the outer `for` loop.
rdar://122364031
These tests are using FileCheck to check the result of diagnostic
formatting in ways that don't match the new formatter. Force the old
formatter or, where possible, generalize so that they match both
formatters.
This patch adds a new flag sanitize-stable-abi to support linking
against the Sanitizers stable ABI added recently in compiler-rt. The
patch also passes extra options for the ASan pass when using this flag
to outline instrumentation code and remove version check.
rdar://112915278
