Fix pre-computation of traits when loading dependency manifests #9057
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.
* 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
* When applicable, the subscript for EnabledTraitsMap will now automatically form a union of the existing explicitly enabled traits for a package if the package identity exists as a key in the stored dictionary (meaning, if the package has already been assigned explicitly enabled traits rather than relying on "default" traits) * Clean up code surrounding the use of the traits map, namely the redundant checks on whether a package is defaulting to default traits vs. explicitly enabled traits * Add some TODOs in comments to address in next commit
|
@swift-ci please test |
|
@swift-ci please test |
Since the wrapper EnabledTraitsMap allows us to determine whether a package is using default traits by returning ["default"] in place of nil when a package has not yet been added to the stored dict, omit explicitly adding "default" to the dictionary itself. This will allow us to check whether we've explicitly modified the trait configuration for a given package, since it will override the default set of traits.
|
@swift-ci please test |
|
@swift-ci please test windows |
|
@swift-ci please test |
|
@swift-ci please test windows |
bripeticca
requested review from
jakepetroules,
dschaefer2,
shawnhyam,
plemarquand,
owenv,
bkhouri,
cmcgee1024 and
daveyc123
as code owners
|
@swift-ci please test |
|
@swift-ci please test windows |
|
@swift-ci please test self hosted windows |
Update an area of code that used legacy methods to compute enabled traits of a dependency prior to the introduction of the EnabledTraitsMap.
|
@swift-ci please test |
|
@swift-ci please test windows |
|
@swift-ci please test self hosted windows |
2 similar comments
|
@swift-ci please test self hosted windows |
|
@swift-ci please test self hosted windows |
dschaefer2
approved these changes
Sep 10, 2025
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.
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-dependenciescommand. It fixes an error that was thrown as a discrepancy in state when executingswift package show-dependenciesif traits were guarding a dependency and was omitted from the package graph.Additionally, this will assure that the
EnabledTraitsMapguards 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).