Fix for .when(traits:) condition not working for multiple traits #9015
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
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 |
FranzBusch
reviewed
Aug 12, 2025
|
@swift-ci please test |
|
@swift-ci please test windows |
FranzBusch
approved these changes
Aug 13, 2025
bkhouri
reviewed
Aug 13, 2025
* Added a wrapper struct that contains a list of traits that could be passed as an argument + the expected output for said combination for TraitTests * Added extra test cases to traits-related Manifest tests, accounting for target dependencies that are enabled by many traits
|
@swift-ci please test |
|
@swift-ci please test |
bripeticca
requested review from
cmcgee1024,
daveyc123,
dschaefer2,
jakepetroules,
owenv,
plemarquand and
shawnhyam
as code owners
FranzBusch
approved these changes
Aug 23, 2025
jakepetroules
approved these changes
Aug 24, 2025
|
@swift-ci please test windows |
|
@swift-ci please test self hosted windows |
bripeticca
added a commit
to bripeticca/swift-package-manager
that referenced
this pull request
Aug 27, 2025
…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.
bripeticca
added a commit
to bripeticca/swift-package-manager
that referenced
this pull request
Aug 28, 2025
…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.
bripeticca
added a commit
to bripeticca/swift-package-manager
that referenced
this pull request
Sep 16, 2025
…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.
bripeticca
added a commit
that referenced
this pull request
Sep 19, 2025
…tion when loading dependency manifests (#9141) - **Explanation**: Addresses multiple traits issues: - Changes the check for trait-guarded target dependencies to determine whether the package dependency from which it derives is used in the parent package; prior to this change, the check was asserting that *all* traits in the `when` condition 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. - Fixes some errors in trait computation that hadn't considered when default traits ["default"] were being appended to the EnabledTraitsMap, which should only consider a list of flattened traits + explicitly enabled traits by a user/parent package. The inclusion of default in this dictionary was resulting in an inaccurate computation of which traits were enabled, since pre-computation serves to flatten the list of transitively enabled traits for future reference. 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. - **Scope**: 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 `when` condition, any of which being enabled would then include said target dependency. - **Issues**: - **Original PRs**: #9015 #9057 - **Risk**: Low risk; fixes trait-related issues. - **Testing**: Fixtures added for end-to-end testing of the issue; regression tests added to multiple suites - **Reviewers**: @FranzBusch @jakepetroules @dschaefer2
johnbute
pushed a commit
to johnbute/fork-swift-package-manager
that referenced
this pull request
Oct 2, 2025
…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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 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.
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.