-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: make lockfile v4 the default #14595
Merged
Merged
Conversation
This file contains 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
It will become v4 when we changes the default.
rustbot
added
A-dependency-resolution
Area: dependency resolution and the resolver
A-git
Area: anything dealing with git
A-manifest
Area: Cargo.toml issues
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
Sep 25, 2024
This commit makes lockfile version 4 the default version when Cargo tries to write to a lockfile. The lockfile version 4 has been stabilized since 1.78.0, and will become default in 1.83.0. the length of transition period is pretty similar as before. One caveat is that in other output from Cargo, e.g., `cargo metatada`, status messages, `SourceID` will display in the v4 URL encoded format. This shouldn't affect the majority of Rust users, as `SourceId` representation should be opaque to them, unless comparing `SourceId` across different version of toolchains.
weihanglo
force-pushed
the
lockfile-v4
branch
from
September 25, 2024 00:43
65365b4
to
5dfdd59
Compare
epage
approved these changes
Sep 25, 2024
Also important to call out that we respect MSRV for this so we don't generate a lockfile you can't use. @bors r+ |
bors
added
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
and removed
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
Sep 25, 2024
bors
added a commit
that referenced
this pull request
Sep 25, 2024
feat: make lockfile v4 the default ### What does this PR try to resolve? This commit makes lockfile version 4 the default version when Cargo tries to write to a lockfile. The lockfile version 4 has been stabilized since 1.78.0, and will become default in 1.83.0. the length of transition period is pretty similar as before. One caveat is that in other output from Cargo, e.g., `cargo metatada`, status messages, `SourceID` will display in the v4 URL encoded format. This shouldn't affect the majority of Rust users, as `SourceId` representation should be opaque to them, unless comparing `SourceId` across different version of toolchains. ### How should we test and review this PR? Some of those tests don't really need to be `version = 4`. They were updated for consistency. ### Additional information This was discussed in Cargo meeting on 2024-09-24.
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
and removed
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
labels
Sep 25, 2024
Network error. @bors retry |
bors
added
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
and removed
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
Sep 25, 2024
☀️ Test successful - checks-actions |
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Sep 28, 2024
Update cargo 19 commits in eaee77dc1584be45949b75e4c4c9a841605e3a4b..80d82ca22abbee5fb7b51fa1abeb1ae34e99e88a 2024-09-19 21:10:23 +0000 to 2024-09-27 17:56:01 +0000 - Update cc to 1.1.22 (rust-lang/cargo#14607) - feat: lockfile path implies --locked on cargo install (rust-lang/cargo#14556) - feat(toml): Add `autolib` (rust-lang/cargo#14591) - fix: correct error count for `cargo check --message-format json` (rust-lang/cargo#14598) - test: relax panic output assertion (rust-lang/cargo#14602) - feat(timings): support dark color scheme in HTML output (rust-lang/cargo#14588) - feat: add CARGO_MANIFEST_PATH env variable (rust-lang/cargo#14404) - fix(config): Don't double-warn about `$CARGO_HOME/config` (rust-lang/cargo#14579) - fix(cargo-rustc): give trailing flags higher precedence on nightly (rust-lang/cargo#14587) - feat: make lockfile v4 the default (rust-lang/cargo#14595) - perf: Improve quality of completion performance traces (rust-lang/cargo#14592) - test: Remove completion tests (rust-lang/cargo#14590) - feat: Add support for completing `cargo update <TAB>` (rust-lang/cargo#14552) - test: Migrate remaining with_stdout/with_stderr calls (rust-lang/cargo#14577) - fix(resolve): Improve multi-MSRV workspaces (rust-lang/cargo#14569) - chore: Bump MSRV to 1.81 (rust-lang/cargo#14585) - Add a `--dry-run` flag to the `install` command (rust-lang/cargo#14280) - fix(resolve): Don't list transitive, incompatible dependencies as available (rust-lang/cargo#14568) - feat(complete): Upgrade clap_complete (rust-lang/cargo#14573)
Manishearth
added a commit
to unicode-org/icu4x
that referenced
this pull request
Oct 3, 2024
Fixes CI issues because test-c-tiny uses an old rustc that isn't able to understand the lockfile updated by test-c (rust-lang/cargo#14595). We should also consider having the lockfiles cleaned between jobs. <!-- Thank you for your pull request to ICU4X! Reminder: try to use [Conventional Comments](https://conventionalcomments.org/) to make comments clearer. Please see https://github.com/unicode-org/icu4x/blob/main/CONTRIBUTING.md for general information on contributing to ICU4X. -->
Manishearth
added a commit
to unicode-org/icu4x
that referenced
this pull request
Oct 4, 2024
This fixes the nightly CI failure on test-c and test-js that began in [this CI run](https://github.com/unicode-org/icu4x/actions/runs/11093290258/job/30819401664), caused by rust-lang/cargo#14595. Updating the pinned-LLVM Rust version past Apr/May 2024 will fix this problem as well, but this is currently hard since that needs LLVM 18 <!-- Thank you for your pull request to ICU4X! Reminder: try to use [Conventional Comments](https://conventionalcomments.org/) to make comments clearer. Please see https://github.com/unicode-org/icu4x/blob/main/CONTRIBUTING.md for general information on contributing to ICU4X. -->
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-dependency-resolution
Area: dependency resolution and the resolver
A-git
Area: anything dealing with git
A-lockfile
Area: Cargo.lock issues
A-manifest
Area: Cargo.toml issues
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
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.
What does this PR try to resolve?
This commit makes lockfile version 4 the default version when Cargo
tries to write to a lockfile.
The lockfile version 4 has been stabilized since 1.78.0,
and will become default in 1.83.0.
the length of transition period is pretty similar as before.
One caveat is that in other output from Cargo,
e.g.,
cargo metatada
, status messages,SourceID
will display in the v4 URL encoded format.This shouldn't affect the majority of Rust users,
as
SourceId
representation should be opaque to them,unless comparing
SourceId
across different version of toolchains.How should we test and review this PR?
Some of those tests don't really need to be
version = 4
.They were updated for consistency.
Additional information
This was discussed in Cargo meeting on 2024-09-24.