Fix swiftc selection for the case no swiftc found in Swift SDK #7296
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
When `swiftc` is not in the toolchain bin directory of Swift SDK, system swiftc in PATH should be used. But the current implementation of `UserToolchain` always picks the last found entry in the PATH instead of the first one. This behavior was introduced by 22c2493
kateinoigakukun
requested review from
neonichu,
tomerd and
MaxDesiatov
as code owners
|
@swift-ci test |
|
Not really a comment for this PR, but it seems inconsistent that we're not using |
|
Yeah, findTool handles xcrun case but there are some direct calls of getTool. I'm not sure they are appropriate use. |
MaxDesiatov
added a commit
that referenced
this pull request
Jun 6, 2024
Behavior of `--toolchain` regressed in #7296 by preferring the first match in toolset root paths: when `swiftc` is available in the same directory next to the SwiftPM binary being invoked, that became preferred with `--toolchain` value ignored. This is now fixed by slightly tweaking where custom toolchain gets added - it's prepended. A newly added test verifies that the behavior is fixed. For that we had to inject `FileSystem` and `EnvironmentVariables` in a lot more places, with an added benefit of making our tests more consistent and isolated from an arbitrary build environment. Resolves: rdar://126095653 --------- Co-authored-by: Pavel Yaskevich <[email protected]>
MaxDesiatov
added a commit
that referenced
this pull request
Jun 12, 2024
Behavior of `--toolchain` regressed in #7296 by preferring the first match in toolset root paths: when `swiftc` is available in the same directory next to the SwiftPM binary being invoked, that became preferred with `--toolchain` value ignored. This is now fixed by slightly tweaking where custom toolchain gets added - it's prepended. A newly added test verifies that the behavior is fixed. For that we had to inject `FileSystem` and `EnvironmentVariables` in a lot more places, with an added benefit of making our tests more consistent and isolated from an arbitrary build environment. Resolves: rdar://126095653 --------- Co-authored-by: Pavel Yaskevich <[email protected]> (cherry picked from commit ee9d0b2) # Conflicts: # Sources/PackageModel/UserToolchain.swift
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.
Fix
PATHexecutable selection inUserToolchainMotivation:
When
swiftcis not in the toolchain bin directory of Swift SDK, system swiftc in PATH should be used. But the current implementation ofUserToolchainalways picks the last found entry in the PATH instead of the first one. This behavior was introduced by 22c2493The causes actual issues when:
swiftcare inPATHswift-buildis placed from outside of toolchain bin directoryThen it uses the last found
swiftcinPATHeven though we expect the first one.Modifications:
Fixed the order of
PATHselection to prefer the first entry.Result:
The first found
swiftcis used as well as shell PATH selection.