Add opt-in exactLiteral version requirements#9812
Open
bc-lee wants to merge 6 commits into
Open
Conversation
Introduce the PackageDescription surface for exactLiteral requirements for source-control and registry dependencies. Downstream manifest loading remains explicitly unimplemented for this new case for now, using fatalError stubs where exhaustiveness requires follow-up work.
Teach manifest loading and package-model conversions to preserve exactLiteral requirements for source-control and registry dependencies. This includes the package-model requirement cases, equality/hash/encoding behavior, manifest source generation, and focused loading and round-trip tests. Resolver semantics remain unchanged in this step.
Add exactLiteral to VersionSetSpecifier, wire exactLiteral requirements into PackageGraph constraints, and cover the new set behavior with focused tests. Include the minimal diagnostic and PubGrub switch updates needed for the new requirement kind to compile cleanly, while deferring resolver behavior changes to later commits.
Teach source-control and registry package containers to preserve SemVer build-metadata variants as distinct candidates while keeping semantic exact selection deterministic. Add focused workspace coverage for source-control lookup, registry ordering, and Package.resolved metadata preservation.
Keep exactLiteral requirements intact through PubGrub decision making so the resolver preserves metadata-distinct selections and reports conflicts with the full requested identifiers. Add focused resolver coverage for literal selection and conflict reporting.
Preserve metadata-bearing Package.resolved pins as literal selections when PubGrub applies pin constraints or checks pin availability. Add a focused resolver regression test that distinguishes metadata variants by their full version description.
bc-lee
requested review from
bkhouri,
bripeticca,
cmcgee1024,
daveinglis,
daveyc123,
dschaefer2,
jakepetroules,
owenv,
plemarquand and
rconnell9
as code owners
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
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.
Proposal: swiftlang/swift-evolution#3188
Motivation:
SwiftPM currently ignores SemVer build metadata when matching exact version
requirements. This change adds an opt-in way to match a full version identifier
literally, including build metadata.
Modifications:
exactLiteralrequirement APIs for source-control and registrydependencies.
Result:
Packages can now write requirements such as
.exactLiteral("1.0.0+debug")without changing existing
.exact(...)or range semantics.