This adds a lit plugin wrapping the core of update-verify-tests. When
lit is invoked with --update-tests it will call the plugin, which checks
if the failure is due to a -verify mismatch. If it is, it tries to
repair the test. If the source file was originally created by
split-file, the changes are propagated to the parent file.
No tests are added, because I don't want to run nested llvm-lit tests
in Swift's test suite, but the core functionality is tested through
update-verify-tests.py.
This ports clang's test suite for update-verify-tests from C to Swift,
and adjusts update-verify-tests as needed. The main differences are the
Swift -verify output format being quite different, as well as Swift's
'-verify-additional-prefix foo' working differently than clang's
'-verify=foo'.
This helper utility takes a module interface as input, and emits a Swift
file importing the module and calling every function in the module. It's
intended for testing of safe interop wrappers to make sure they go
through the entire pipeline of the compiler instead of succumbing to
laziness.
This adds sanitizing of the expansion of the `%t` temp dir to
PathSanitizingFileCheck. Because the expansion of this path is different
for each test case, lit.cfg cannot use the expanded version. Instead it
relies on lit expanding the `%t` substring. This requires path
normalization to occur in PathSanitizingFileCheck instead of lit.cfg.
All strings matching the expansion of `%t` are now replaced with
`TMP_DIR`. This is especially useful when source files are created in
`%t` using `split-file`.
Also sorts the patterns to sanitize based on length, to guarantee that
patterns that are substrings of some other pattern are always tested
after the longer patterns has already been tested. Otherwise the longer
pattern may never match.
In unified builds `swift_obj_root` is in a different place in the CMake
build tree, so using it as the base for finding `lib` is not correct.
Change the usage of `swift_obj_root/lib` for `config.swift_lib_dir`
which should be correct in both unified and non-unified builds.
Changed %target-build-swift-dylib\(([^)]+)\) to
%target-build-swift-dylib\(([^)]+?)([^/()]+)\)
Group 1 now captures the "prefix" and group 2 captures the final word
Captured the basename directly in the regex instead of using a subshell since
Lit's internal shell does not support
This patch adds parsing and extracting of the Swift reflection
metadata data segments from within the WebAssembly DATA section and
tests it using swift-reflection-dump. This is needed to allow LLDB to
acces Swift reflection metadata when attached to WebAssembly
processes.
rdar://159217213
Introduces a new build-script flag `--test-optimize-none-with-opaque-values`
and build targets like `check-swift-optimize_none_with_opaque_values` that
runs the execution_test's while compiling them with -enable-sil-opaque-values.
This mode is quite useful while working to bring-up opaque values.
This switches from using lit.cfg to attempt to recompute the module
triple to using the triple computed in CMake to ensure consistency.
This is a better source of truth than having many sources everywhere.
In case anyone sees this and is wondering, the "target triple" refers to
the triple that the compiler is built for, while the "variant triple"
refers to the platform that the tests and runtimes are built for.
Infer the `-target` argument to `swift-synthesize-interface` to be the host
triple when unspecified instead of emitting an error.
Resolves rdar://156353450.
The test is only partially enabled: we only check for IR correctness and correct linking. We don't run the tests on WASI yet due to unrelated issues that are going to be resolved separately.
Run new `check-swift-embedded-wasi` target from `test/CMakeLists.txt`, tweak `lit.cfg` to support both `-wasi` and `-wasip1` triples, exclude unsupported tests based on `CPU=wasm32` instead of `OS=wasi`.
Currently when test subset is not specified, `lit.cfg` provides an error message that refers to test modes instead of tests subsets. Making error messages distinct makes it easier to backtrack in lit.cfg source code when diagnosing the root cause.
Resolves rdar://152598492
Consider the following Swift, adapted from a real-world framework:
```swift
@available(macOS 10.8, *)
@_originallyDefinedIn(module: "another", macOS 11.0)
public struct SimpleStruct {}
@available(macOS 12.0, iOS 13.0, *)
public extension SimpleStruct {
struct InnerStruct {}
}
```
In this scenario, `SimpleStruct` was originally in a module called
`another`, but was migrated to this module around the time of macOS
11.0. Since then, the module was ported to iOS and gained a nested type
`SimpleStruct.InnerStruct`. When mangling USRs for this nested type, the
result differs depending on whether we're targeting macOS or iOS.
They're mostly the same, but the macOS build yields a USR with an `AAE`
infix, designating that the `InnerStruct` was defined in an extension
from a module with the name of the base module. On iOS, this infix does
not exist.
The reason this is happening is because of the implementation of
`getAlternateModuleName` checking the availability spec in the
`@_originallyDefinedIn` attribute against the currently active target.
If the target matches the spec, then the alternate module name is
reported, otherwise the real module name is. Since the iOS build reports
the real module name, the mangling code doesn't bother including the
extension-context infix, instead just opting to include the parent
type's name and moving on.
This PR routes around this issue by passing the
`RespectOriginallyDefinedIn` variable to the
`ExtensionDecl::isInSameDefiningModule` method, and using that to skip
the alternate module name entirely. It also sets
`RespectOriginallyDefinedIn` to `false` in more places when mangling
USRs, but i'm not 100% confident that it was all necessary. The goal was
to make USRs more consistent across platforms, regardless of the
surrounding context.
remote-run uses rsync instead of sftp server. Some of the tests were
incorrectly labelled as requiring sftp server. Fixed those and replaced
the requirement with rsync.
Since https://github.com/llvm/llvm-project/pull/103042, backslashes in
substitutions are consistently escaped on all platforms before feeding
the substitutions to the regex engine. Make sure all substitutions
containing capture group references are wrapped in `SubstituteCaptures`
to suppress this behavior once main is rebranched.
If you use SwiftStdlibCurrentOS availability, you will be able to
use new types and functions from within the implementation. This
works by, when appropriate, building with the CurrentOS availability
set to the current deployment target.
rdar://150944675
We cross-compile the Swift runtime libs for the Android SDKs in the Windows toolchain. This patch adds a build step that runs non-executable tests for them.
ObjectFileContext doesn't currently support chained fixups. For now, avoid building the test binaries with chained fixups to avoid issues.
This adds a %no-fixup-chains substitution which resolves to -Xlinker -no_fixup_chains on Darwin, and to nothing on everything else.
rdar://145442500
The backtracing code will warn you if you attempt to forcibly enable
backtracing for a privileged executable. This is apparently upsetting
the Driver/filelists.swift test.
Since we want to force it on for tests, so that we will definitely get
backtraces, add an option to suppress warning messages, and turn that
on for tests as well.
rdar://144497613
SIL/verify_all_overlays.py is passing `-F ""` on non-Apple platforms. Swift handles that kind of, but clang doesn't support it and will get argument parsing errors. It's a pathological case, so fix SIL/verify_all_overlays.py to not do that, but also add a failsafe in ClangImporter to not pass on empty paths.
rdar://142441042
