Merge main into release/5.10
#6953
Merged
Conversation
This file contains 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
|
@swift-ci test |
neonichu
approved these changes
Sep 27, 2023
MaxDesiatov
force-pushed
the
maxd/manual-main-merge
branch
2 times, most recently
from
0b93cde
to
327e5ef
Compare
A previous problem here was fixed in #6723, this new fix is attempting to resolve issues where macros are used transitively by a product that a test is depending on. It seems to me that those transitively available macros should not be statically linked into tests and in fact doing so can cause various issues such as linker errors on non-Darwin platforms. It does feel like eventually we need to get away from `computeDependencies(of:)` being a computation on the entire package graph and instead let each package produce separate products which we can then just use transitively, but that is a much bigger change to SwiftPM's build system. rdar://115071012
We never need this for any platform that we're not building for and we also don't really need it for most commands. So we can just move the computation to SwiftTool and leave these empty for all other cases. rdar://64596106
In this case we inject the code directly into the entry point executable. We also need to significantly change the observation code because of the vast API differences between XCTest and swift-corelibs-xctest. Notably, we cannot support features like expected failures, attachments etc since they are not available on non-Darwin platforms. rdar://115067756
This is another set of tests that requires a fully functioning SDK on macOS, so they should be skipped based on `SWIFTCI_DISABLE_SDK_DEPENDENT_TESTS`.
We weren't applying mirrors to root dependencies so far. rdar://110869499
`.upToNextMajor` and `.upToNextMinor` need a `from` argument, but it was missing in the comments.
* Update Product.swift to render the api description correctly * [ADD] Added indent to align parameters
- Merge the two 99% identical implementations of `buildTestsIfNeeded()` - Handle the case where a non-test product is passed to `--test-product` - Handle the case where we cannot find the test product after the build
This option is only useful when in cases where SwiftPM offers more than a single test product. Currently that requires either using XCBuild or a multi-root data file which are both hidden and experimental, so this option should be hidden, too, in order to not confuse users. It could be interesting to investigate changing the build model so that we would always build a test product per test target and if that happens we could publicize this option again.
This can currently lead to bogus output like
```
error: terminated(1): /Users/neonacho/Downloads/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/llvm-profdata merge -sparse -o /Users/neonacho/Desktop/lunch7/.build/arm64-apple-macosx/debug/codecov/default.profdata output:
error: no input files specified. See llvm-profdata merge -help
```
I would also think even if it succeeded, it could result in incorrect data.
rdar://115436056
Currently, we're only invoking build tool plugins for reachable targets which does not seem correct based on the fact that we're willing to build targets out of reachable, e.g. when executing a command plugin. rdar://113264168
We now the triple here, so we shouldn't have it be recomputed from scratch.
This takes a significant amount of time when the selected Xcode doesn't have a `swift-plugin-server` executable: ``` /tmp/exec ❯ time /usr/bin/xcrun --find swift-plugin-server xcrun: error: sh -c '/Users/neonacho/Downloads/Xcode.app/Contents/Developer/usr/bin/xcodebuild -sdk /Users/neonacho/Downloads/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.3.sdk -find swift-plugin-server 2> /dev/null' failed with exit code 17664: (null) (errno=No such file or directory) xcrun: error: unable to find utility "swift-plugin-server", not a developer tool or in PATH /usr/bin/xcrun --find swift-plugin-server 0.34s user 0.17s system 32% cpu 1.579 total ``` Doing this on demand is at least gated on `self.buildParameters.toolchain.isSwiftDevelopmentToolchain` so it shouldn't happen for the primary usage scenario on macOS.
… provided in the dependency (#6897) Update error message when there's a package target with a similar name as the one provided in the dependency. ### Motivation: Partially addresses #4803. It adds a suggestion for an alternative dependency name when there's a dependency target with similar name as the one provided in the `Package.swift`. ### Modifications: Use the existing `bestMatch(for, from)` from TSCBasic to compare the `productRef.name` and `allTargetNames`. However, I'm not sure how and if I can include target from system packages. ### Result: Error messages for package target not found may also suggest an alternative name like: `product 'Barx' required by package 'foo' target 'FooTarget' not found. Did you mean 'Bar'?`
These were public for implementation reasons, likely because of how the old serialization code worked which I refactored in 5.9 fixes #6911
Since this file hasn't been added to `.gitignore`, we have to update it after the list of targets is updated.
This PR implements support for the `linker.path` field in the Swift SDK toolset spec. Depends on apple/swift#68495 and apple/swift-driver#1441. ### Motivation: This field was previously parsed but not respected. ### Modifications: Add `-ld-path=\(linker.path)` to the toolchain's Swift flags if a linker path override is supplied ### Result: The linker path is now respected.
This is the potential source of a crash on x86_64 using the rebranch branch of Swift. rdar://115675736
When setting host triple in Swift SDKs to `arm64-apple-macosx13.0` to allow cross-compiling from an older version of macOS, this triple is not recognized as directly matching `arm64-apple-macosx14.0` on a newer version of macOS. We should support backward compatibility with Swift SDKs that were built for older version of macOS. Resolves rdar://113967401.
#6719)" (#6939) This reverts commit d328002. This broke existing Swift SDKs: ``` ld.lld: error: unable to find library -ld-path=/Users/neonacho/Library/org.swift.swiftpm/swift-sdks/5.8-RELEASE_rhel_ubi9_aarch64.artifactbundle/5.8-RELEASE_rhel_ubi9_aarch64/aarch64-unknown-linux-gnu/swift.xctoolchain/usr/bin/ld.lld ```
* Support qualifiers for ambiguous plugin commands This adds a `--package` option to the plugin command which will limit the set of available plugins to those inside a package with the given identity. The identity is not validated in any way, it will just be applied as a filter on all relevant packages. The option does apply to `--list` as well which seems a bit odd but a consequence of making listing an option rather than a command. rdar://99887952 * Test
…emove wrong llbuild dependency (#6909) This is currently flagging wrong dependencies, enable it again once it works.
With a lot of Swift SDKs installed it's not as easy to navigate through a long unsorted list of strings.
Vendored Swift Driver triple was not checked against a few tests that weren't brought over from TSC after `TSC.Triple` type was deprecated. We should fix those tests, especially as they verified that per-component equality for triples worked instead of the current string-based equality check. Also fixed some of the `Utilities/soundness.sh` script failures. Related to rdar://113967401
MaxDesiatov
force-pushed
the
maxd/manual-main-merge
branch
from
327e5ef
to
fcb1dc8
Compare
|
@swift-ci test |
|
@swift-ci test windows |
|
@swift-ci test |
|
@swift-ci test windows |
1 similar comment
|
@swift-ci test windows |
tomerd
approved these changes
Sep 28, 2023
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.
There were a few conflicts accumulated, which are resolved manually in this PR.