[6.2.1] Cherry-pick: Fix traits .when(traits:) condition; pre-computation when loading dependency manifests #9141
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
…ftlang#9015) The culprit here is the fact that we were essentially doing an AND boolean check across all the traits in the target dependency condition, when we should be doing an OR boolean check. If at least one trait is enabled in the list of traits in the target dependency condition, then the target dependecy should be considered enabled as well.
|
@swift-ci please test |
…tlang#9057) This fix addresses some issues that arose with trait-based dependency resolution on Linux and, found through development, a related issue found involving the `swift package show-dependencies` command. It fixes an error that was thrown as a discrepancy in state when executing `swift package show-dependencies` if traits were guarding a dependency and was omitted from the package graph. Additionally, this will assure that the `EnabledTraitsMap` guards against explicitly adding "default" traits to the stored dictionary, since this wrapper is a mechanism to determine whether traits have been explicitly set (and therefore have overridden "default" or have flattened the list of default traits).
|
@swift-ci please test |
bripeticca
changed the title
|
@swift-ci please test windows |
rconnell9
approved these changes
Sep 19, 2025
simonjbeaumont
added a commit
to swift-otel/swift-otel
that referenced
this pull request
Sep 24, 2025
#357) ## Motivation We had a workaround in our package manifest for the use of `.when(traits:)` not using its argument as a boolean-OR. The good news is that this bug has been addressed and the fix available in the 6.2.0 release. The bad news is that there was still an issue with resolving dependencies that themselves had trait-conditional transitive dependencies, and the fix for that did _not_ make the Xcode 26.0 release. The outcome is that if you were to try to compile a project that depends on Swift OTel with _only_ the `OTLPHTTP` trait, it will fail to resolve. We have such an example in our `Examples/` directory: ```console % rm -rf .build Package.resolved && swift build ... error: 'swift-otel': product 'SwiftProtobuf' required by package 'swift-otel' target 'OTel' not found in package 'swift-protobuf'. ``` The fix is included in the nightly main, and I have verified that works. It also has been cherry-picked into 6.2.1 here: swiftlang/swift-package-manager#9141. So it is just 6.2.0 that's the problem. Fortunately, all our trait-conditional dependencies are only used with `internal import`, which means we can add a workaround without having to make a future API-breaking change. We can just unconditionally include these dependencies on the known problematic toolchain (6.2.0). ## Modifications - Add 6.2.0-specific workaround for trait-conditional dependencies ## Result Packages that depend on Swift OTel with only `OTLPHTTP` trait will now compile with Xcode 26.0 toolchains.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Addresses multiple traits issues:
whencondition of a target dependency were enabled for the dependency to be considered unguarded, but now the check confirms that at least one trait in the condition is enabled.There were also cases where we were re-computing transitively enabled traits in areas where we had already filled out the enabledTraitsMap, so we now default to simply fetching the entry from the dictionary instead of computing the traits all over again.
Package resolution stage; particularly affects pre-computation of transitively enabled traits when determining which target dependencies are/aren't guarded by traits. Also allows for multiple traits to be considered in a target dependency's
whencondition, any of which being enabled would then include said target dependency.Fix for .when(traits:) condition not working for multiple traits #9015
Fix pre-computation of traits when loading dependency manifests #9057
Low risk; fixes trait-related issues.
Fixtures added for end-to-end testing of the issue; regression tests added to multiple suites
@FranzBusch @jakepetroules @dschaefer2