Merge main to 6.2 #8516
Open
Merge main to 6.2 #8516
+4,105
−4,625
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…g#8449) ### Motivation: Some of the `SwiftBuildSupport/PIFBuilder.swift` encoding/decoding code was using unsafe string keys. This replaces with proper typesafe keys. This part of the ground work to support the new PIF builder in `SwiftBuildSupport` (i.e., rdar://147527170). ### Modifications: When conforming to `Codable`, replace string keys with `enum` based keys instead. ### Result: The resulting code is a tad safer and easier to understand :-) Tracked by rdar://148546582.
…wiftlang#8441) ### Motivation: The goal is to adopt the new `SwiftBuild.ProjectModel` API. This new API provides a *typesafer* and *modern* way of building PIFs programmatically. This continues the work I started in PR swiftlang#8405, introducing now our new PIF builder for packages. ### Modifications: Replaces all `SwiftBuild.PIF` (aka, `SWBProjectModel.PIF`) API usage, in `PackagePIFBuilder`, with the new `SwiftBuild.ProjectModel` API instead. ### Result: `PackagePIFBuilder` is now modernized... but still not actually used. This will come in my next pull request. Tracked by rdar://147526957.
Some tests in Tests/SourceControlTests are passing on Windows since upgrading the Git Version in the associated docker image, which was completd in https://github.com/swiftlang/swift-docker/pulls/452 Enable the tests that are skipped. Relates to: swiftlang#8433 rdar://148248105
…swiftlang#8462) This updates and clarifies the [Version-specific Manifest Selection](https://github.com/swiftlang/swift-package-manager/blob/main/Documentation/Usage.md#version-specific-manifest-selection) section of the usage documentation to clarify the behavior when having either newer or older tools versions. ### Motivation: In general, when using the versioned manifest feature, it's preferable to have the unversioned `Package.swift` represent the newest-supported tools version, and only use version-specific manifest files for older versions. This provides a better workflow because it allows you to more easily drop support for older versions when ready (by avoiding the need to modify the unversioned file), among other benefits. ### Modifications: - "Reverse" the example shown in this documentation by having the unversioned file be newest. - Modernize the version numbers shown in examples. - Fix some non-inclusive language usages. - Add a footnote with some helpful historical context, and giving a recommendation.
Enable WorkspaceTests on Windows that, for some reason, previously failed. Relates: swiftlang#8433 rdar://148248105
Enable additional tests on Windows host platform
- Enable a few `AsyncProcessTests`
- Enable the lone skipped test in `EnvironmentTests`
- Enable the only skipped test in
`Tests/SourceKitLSPAPITests/SourceKitLSPAPITests.swift`
- Enable the only skipped test in
`Tests/BuildTests/BuildSystemDelegateTests.swift`
- Enable the lone skipped test in
`Tests/BuildTests/LLBuildManifestBuilderTests.swift`
- Replace usages of `fixwin` with `AbsolutePath.pathString`
Related to: swiftlang#8433
rdar://148248105
Remove hardcoded WASI sysroot path derivation just for wasi-sysroot embedded in toolchains ### Motivation: The previous implementation assumed there is $TOOLCHAIN_ROOT/share/wasi-sysroot when `--triple wasm32-unknown-wasi` is passed, but this is no longer the case with the [deprecation of the Wasm toolchain installation](swiftwasm/swift#5604) in favor of Swift SDKs. Due to this unnecessary branch, when `--triple wasm32-unknown-wasi` is passed together with `--swift-sdk`, `--swift-sdk` is just ignored: swiftlang#8465 ### Modifications: This change removes the hardcoded path derivation for the WASI sysroot from the `SwiftSDK.deriveTargetSwiftSDK` method. ### Result: When `--triple wasm32-unknown-wasi` is passed without `--swift-sdk`, no user visible change and they will keep getting the following: ``` error: emit-module command failed with exit code 1 (use -v to see invocation) <unknown>:0: warning: libc not found for 'wasm32-unknown-wasi'; C stdlib may be unavailable <unknown>:0: error: unable to load standard library for target 'wasm32-unknown-wasi' ``` When `--triple wasm32-unknown-wasi` is passed together with `--swift-sdk`, `--triple` is ignored and `--swift-sdk` is respected.
Until swiftlang#8223 is fixed copy some helpers from `IntergrationTests/Source/IntegrationTests` to `Test/_InternalTestSupport` so we can re-use the functionality. Related to: swiftlang#8433 rdar://148248105
…8472) We were including flags to hook up modulemaps and include files to C library dependencies in macros and plugin tools through to the modules that depend on those. This adds the capability to prune the depth first searches through the dependencies to ensure these are skipped when crossing macro and plugin boundaries.
Until swiftlang#8223 is fixed copy some helpers from `IntergrationTests/Source/IntegrationTests` to `Test/_InternalTestSupport` so we can re-use the functionality. Related to: swiftlang#8433 rdar://148248105 Test with: swiftlang/swift#80717
Fixed up incorrect wording: 1. Wasm is not an acronym, thus it's not uppercased [per the spec](https://webassembly.github.io/spec/core/intro/introduction.html#wasm). 2. Existing Swift SDKs support only WASI, while WASI-less Wasm modules can be created with Embedded Swift and Swift SDKs are not needed for that.
### Motivation: Ensure swiftpm bootstraps successfully to fully build an OpenBSD toolchain. ### Modifications: * Add the nobtcfi linker flag to the bootstrap script for OpenBSD. This is unconditional for now since swiftpm uses Concurrency liberally and this triggers #80059, so swiftpm only builds on the configuration where BTCFI is disabled. We can revisit some of that perhaps later. * Ensure SPMSQLite3 builds with the correct link library search path flag in CMakeLists.txt. * Update Package.swift conditionals for SPMSQLite3. ### Result: swiftpm successfully builds and bootstraps on OpenBSD.
The TestCommandTests fail on Linux due to a common linker problem with swift build build system, which is the missing 'main' symbol problem. This is described further detail in swiftlang#8439. Provide the link in the skip messages and remove the TODO tags since the investigation is complete and the reason for the failures is now known. Update the common test case logic so that it dumps the command execution stdout and stderr in the case of failure to help diagnose these result.xml failures immediately in the logs.
### Motivation: Pull request swiftlang#8476 was breaking SwiftPM builds in Xcode (i.e., the _package resolution_ step): <img src="https://github.com/user-attachments/assets/2424e52c-1198-45c2-aa82-68c73ef5e9d6" width=600/> ### Modifications: This reverts commit 1d48e0a.
Split the SerializedJSONTests into tests that pass and fail on Windows Related: swiftlang#8433 rdar://148248105
### Motivation:
This improves a bit the error/warning output when building with the new
`--build-system swiftbuild`.
This was the current output:
```shell
warning: unknown Enabling the Swift language feature 'MemberImportVisibility' is recommended; set 'SWIFT_UPCOMING_FEATURE_MEMBER_IMPORT_VISIBILITY = YES' []
error: path("/Users/pmattos/Development/SampleProjects/SamplePackages/PackageAccessCLI/Sources/ExampleApp/main.swift", fileLocation: Optional(SwiftBuild.SwiftBuildMessage.DiagnosticInfo.Location.FileLocation.textual(line: 6, column: Optional(5)))) cannot find 'bar' in scope []
```
...and this is the improved one:
```shell
warning: Enabling the Swift language feature 'MemberImportVisibility' is recommended; set 'SWIFT_UPCOMING_FEATURE_MEMBER_IMPORT_VISIBILITY = YES'
error: /Users/pmattos/Development/SampleProjects/SamplePackages/PackageAccessCLI/Sources/ExampleApp/main.swift:5:5 cannot find 'foo2' in scope
```
Eventually, we should consider adopting the error output style from the
`--build-system native` instead, i.e.:
```shell
/Users/pmattos/Development/SampleProjects/SamplePackages/PackageAccessCLI/Sources/ExampleApp/main.swift:5:5: error: cannot find 'foo2' in scope
3 | print("Hello, world!")
4 |
5 | _ = foo2()
| `- error: cannot find 'foo2' in scope
6 | _ = bar()
7 |
```
### Modifications:
These formatting changes are strictly local to the new
`SwiftBuildSupport` target.
### Result:
Slightly better error formatting :-)
The Swift toolchain installation on swift.org indicate to use swiftly to install the toolchain on macOS and Linux. Update the CONTRIBUTING.md file to refer to swiftly for toolchain management.
I had mucked with the fix to finish some testing and forgot to put the fix back. And the test didn't properly catch that. Fixing both.
…ystem (swiftlang#8421) - this also fixes -enable-library-evolution when used as a unsafeFlags Closes: swiftlang#8337 ### Modifications: sets SWIFT_EMIT_MODULE_INTERFACE build setting when option is set ### Result: the build option will include the .swftinertface files in the module folder
This PR adds support for the `--attachments-path` CLI argument on `swift test` as approved in [ST-0009](https://github.com/swiftlang/swift-evolution/blob/main/proposals/testing/0009-attachments.md). We will maintain support for the older `--experimental-attachments-path` version through Swift 6.2. The implementation of this option is held entirely in Swift Testing at this time, so no actual code is needed to support it, we just need to make sure Swift Argument Parser doesn't complain about it. Resolves rdar://147753584. @plemarquand has integration tests but they're blocked on a newer toolchain; unit testing of this argument exists in the Swift Testing repo.
### Motivation: When running tests ensure the *test fixtures* we copy over to temporary directories don't carry over any previous build information. ### Modifications: When copying packages from `/Fixtures/**` we now ensure we delete any `.build` or `.swiftpm` directories, if any.
dschaefer2
requested review from
bnbarham,
MaxDesiatov,
jakepetroules,
xedin,
shawnhyam and
bripeticca
as code owners
Reverts swiftlang#8498 Broke swift-foundation build.
### Motivation: Switch from the legacy PIF builder in `SwiftBuildSupport` to the new one, introduced by PR swiftlang#8405. The new PIF builder (i.e., `SwiftBuildSupport/PackagePIFBuilder*.swift`) is the exact same we use in Xcode. ### Modifications: Replaces the old PIF builder (i.e., `SwiftBuildSupport/PIF.swift` and `SwiftBuildSupport/PIFBuilder.swift` ) with the new one (i.e., `SwiftBuildSupport/PackagePIFBuilder*.swift`). ### Result: The new PIF builder now fully replaces the legacy PIF builder. In particular, all these Swift Build tests are passing (i.e., same as before this PR): * BuildPlanSwiftBuildTests * APIDiffSwiftBuildTests * BuildCommandSwiftBuildTests * PackageCommandSwiftBuildTests * RunCommandSwiftBuildTests * TestCommandSwiftBuildTests I also improved the PIF logging too. Try the `--very-verbose` option to see what I mean :-) Tracked by rdar://147527170.
### Motivation:
Reduce noise from solvable warnings.
### Modifications:
We should `throw XCTSkip("...")` but `try XCTSkipIf(true, "...")`.
The BuildCommandTests was mixing both (i.e., `try XCTSkip("...")`),
making the test a nop actually.
This encodes our indentation size and line ending preferences and such. This is an exact copy of the .editorconfig in swift-build, which uses the same conventions.
|
@swift-ci test self hosted |
|
@swift-ci test self hosted windows |
We are seeing hangs in swift test on Windows. Instead of build-using-self using the underlying toolchain, build swift-test and use that for the tests. When we make improvements to it to fix the underlying problem, we will be able to take advantage of that fix right away.
A SwiftBuild test is currently failing on Amazon Linux 2. Disable this test for now and link it to a GitHub issue.
…ld system (swiftlang#8527) ### Motivation: Increase code coverage for our integration tests. This is an issue I introduced in swiftlang#8454 while ignoring `--build-system swiftbuild` issues on Windows (i.e., actually this specific issue swiftlang#8514). I accidentally skipped the packageInitExecutable test for `--build-system native` as well (which should be green). This PR fixes that. ### Modifications: Swift Testing currently doesn't support combining *conditional traits* (e.g.,`skipHostOS(.windows)`) with *parametric tests*. So the 2nd best approach is to split the tests as I just did.
Adopt the experimental feature MemberImportVisibility. ### Motivation: Due to a weakness in the existing Swift language implementation, a public extension declared in a library module can be accessible to source code that doesn’t directly import that module. ### Modifications: Adopt MemberImportVisibility on all targets and adjust imports to be explicit. There were a few places where ambiguities were exposed. The most apparent one is the ambiguity between Basics.AbsolutePath and TSCBasics.AbsolutePath. In this case they're functionally equivalent since the Basics version just type aliases the TSCBasics version. There were a few others where identically named methods were defined in both a SwiftPM module and an imported dependency. ### Result: SwiftPM compiles with no code included without a corresponding explicit import.
dschaefer2
force-pushed
the
merge-main-to-6.2
branch
from
8844805 to
7998442
Compare
This uses the /ALTERNATENAME flag to link.exe, which is roughly equivalent to -alias/--defsym. This has been verified to work in a sample project. See https://devblogs.microsoft.com/oldnewthing/20200731-00/ for more info. Closes swiftlang#6367
### Motivation: Add **FreeBSD** support to SwiftBuild PIF builder (i.e., when using `--build-system swiftbuild`). ### Modifications: Just a quick change in how we map a `PackageModel.Platform` value to a `SwiftBuild.ProjectModel.BuildSettings.Platform` one.
rdar://149936169 This test is currently failing on CI (https://ci.swift.org/job/oss-swift-package-amazon-linux-2-aarch64/4188) and blocks toolchain builds for swift.org.
…wiftlang#8531) ### Motivation: Adds a flag and entry into outputs file map per file in a swift module to emit any diagnostics in serialized form. This is preliminary work to for future `swift migrate` command that needs serialized diagnostics to get the fix-its and enables future improvements like diagnostic de-duplication. ### Modifications: - Add a new flag to `compileArguments` : `-serialize-diagnostics` - Add an entry per source file an swift module that presents a path to a `.dia` file where the diagnostic information should be stored. - Add a computed property to fetch diagnostic file locations per swift module ### Result: The build would now emit serialized diagnostic files for every swift module.
…and (swiftlang#8532) ### Motivation: Adds a way to programmatically insert new settings into a package manifest. Currently only some Swift settings are supported, namely: `enable{Upcoming, Experimental}Feature`, `swiftLanguageMode` and `strictMemorySafety`; but the command could be expanded to support more Swift (C, C++, linker) settings in the future. ### Modifications: - Add a new "package" sub-command named "add-setting" that accepts a target and a list of `--swift Name[=Value]?` pairs for each new swift setting to add. Each setting would make sure that manifest is new enough to support it. - Add new manifest refactoring action - AddSwiftSetting that would add `swiftSettings:` to a target or modify the existing one. - Expands existing way to check whether manifest is too old to support custom versions. This is doe to make sure that users don't add settings that are not supported by the manifest tools version i.e. `swiftLanguageMode` was introduced in 6.0 tools. ### Result: A new `swift package add-setting --target <name> [--swift Name[=Value]?]+` command that allows users to programmatically add new settings to package manifests.
…and (swiftlang#8532) ### Motivation: Adds a way to programmatically insert new settings into a package manifest. Currently only some Swift settings are supported, namely: `enable{Upcoming, Experimental}Feature`, `swiftLanguageMode` and `strictMemorySafety`; but the command could be expanded to support more Swift (C, C++, linker) settings in the future. ### Modifications: - Add a new "package" sub-command named "add-setting" that accepts a target and a list of `--swift Name[=Value]?` pairs for each new swift setting to add. Each setting would make sure that manifest is new enough to support it. - Add new manifest refactoring action - AddSwiftSetting that would add `swiftSettings:` to a target or modify the existing one. - Expands existing way to check whether manifest is too old to support custom versions. This is doe to make sure that users don't add settings that are not supported by the manifest tools version i.e. `swiftLanguageMode` was introduced in 6.0 tools. ### Result: A new `swift package add-setting --target <name> [--swift Name[=Value]?]+` command that allows users to programmatically add new settings to package manifests.
### Motivation: Improve visualization/debuggability of the PIF JSON sent over to Swift Build (when using the new `--build-system swiftbuild` option). ### Modifications: This PR introduces the `--print-pif-manifest-graph` option to write out the PIF JSON sent to Swift Build as a Graphviz file. This follows a similar design we used for the existing `--print-manifest-job-graph` option. All the serialization happens in the new `DotPIFSerializer.swift` file, with this function as the entry point: func writePIF(_ workspace: PIF.Workspace, toDOT outputStream: OutputByteStream) ### Result: With Graphviz tool (https://graphviz.org) installed (i.e., provides the `dot` command below), we can then run commands like this: $ swift build --build-system swiftbuild --print-pif-manifest-graph | dot -Tpng > PIF.png
) There are tests that were formerly failing due to missing support for plugins in the old PIF builder. Enable these test for better coverage with the new builder. * Fix spelling in one of the APIs * Remove macOS-specific linker flag in the PIF builder and use a setting that is target platform neutral * Update skip comments for tests based on new analysis of the failures
…iftlang#8557) Reverts swiftlang#8477 due to Amazon Linux 2 failures https://ci.swift.org/job/oss-swift-package-amazon-linux-2/4177/console
Prevent non-targets from depending on test targets ### Motivation: Fix for rdar://149007214 Currently, only test targets are allowed to have dependencies on other test targets. ### Modifications: Simply checked for each non-test target, if their dependency is of type test. If it is, throw an error. ### Result: Swift package manager will give an error explaining that only testTargets can depend on other testTargets Fixes swiftlang#8478 --------- Co-authored-by: John Bute <[email protected]>
Adds a `Documentation.docc` directory (a bare DocC catalog) as a stub for migrating existing content in `Documentation/` from general markdown into DocC, as well as providing a base for expanding that documentation. Follow up PRs will bring over and convert content from the `Documentation` directory more piecemeal
…wiftlang#8538) SPM has functionality to skip a set of tests using an undocumented environment variable, '_SWIFTPM_SKIP_TESTS_LIST'. The presence of this variable causes test output to change around starting/ending of test suites. Test Suite 'All tests' started vs. Test Suite 'Selected tests' started * Remove checking for the 'All tests' string. * Check the return code of the test execution. * Set up environment variables to match bootstrap in the IntegrationTests execution. * Change bootstrap to use a call() instead of call_output() as call_output will block until the process has finished. A swift-test may take a long time. Certain CI environments expects output to stream out, and will cancel the build if none is detected for 30 mins. * Update tests with using the 'checker', to output stdout/stderr for easier debugging of failed expects.
…g#8558) There are tests that were formerly failing due to missing support for plugins in the old PIF builder. Enable these test for better coverage with the new builder. * Fix spelling in one of the APIs * Remove macOS-specific linker flag in the PIF builder and use a setting that is target platform neutral * Update skip comments for tests based on new analysis of the failures * Skip test that's failing on Amazon Linux 2
The investigation is pointing to running git commands in parallel that is causing the hang with the Windows CI. Turn them off until we can figure out how to serialize them across xctest processes. Once they completed, fixed the BuildPlanTests which were matching with backslashes. Also had backslash issues when launching the integration tests. ---------
dschaefer2
force-pushed
the
merge-main-to-6.2
branch
from
7998442 to
f0b3529
Compare
|
@swift-ci please test |
|
@swift-ci please test windows |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Merging main 0b23073 to release/6.2.