development/cargo
development/cargo
1
0
Fork 0
mirror of https://github.com/rust-lang/cargo synced 2024-10-31 08:59:36 +00:00
Code Issues Projects Releases Packages Wiki Activity
cargo/tests/testsuite/lockfile_compat.rs

1158 lines
26 KiB
Rust
Raw Normal View History

Minor testsuite organization.
2019-11-25 02:42:45 +00:00
//! Tests for supporting older versions of the Cargo.lock file format.
Don't export lines_match. Use better high-level interfaces to achieve the same thing.
2021-06-16 02:23:17 +00:00
use cargo_test_support::compare::assert_match_exact;
Extract `support` directory to its own crate Extract out all our test support code to its own standalone crate so it can be shared between multiple test suites if necessary.
2019-09-12 17:14:29 +00:00
use cargo_test_support::git;
use cargo_test_support::registry::Package;
Move comparison and diffing code to a new module. This includes various minor refactorings to try to clean things up and provide better error messages.
2021-06-15 23:23:06 +00:00
use cargo_test_support::{basic_lib_manifest, basic_manifest, project};
Add sha256 checksums to the lockfile This commit changes how lock files are encoded by checksums for each package in the lockfile to the `[metadata]` section. The previous commit implemented the ability to redirect sources, but the core assumption there was that a package coming from two different locations was always the same. An inevitable case, however, is that a source gets corrupted or, worse, ships a modified version of a crate to introduce instability between two "mirrors". The purpose of adding checksums will be to resolve this discrepancy. Each crate coming from crates.io will now record its sha256 checksum in the lock file. When a lock file already exists, the new checksum for a crate will be checked against it, and if they differ compilation will be aborted. Currently only registry crates will have sha256 checksums listed, all other sources do not have checksums at this time. The astute may notice that if the lock file format is changing, then a lock file generated by a newer Cargo might be mangled by an older Cargo. In anticipation of this, however, all Cargo versions published support a `[metadata]` section of the lock file which is transparently carried forward if encountered. This means that older Cargos compiling with a newer lock file will not verify checksums in the lock file, but they will carry forward the checksum information and prevent it from being removed. There are, however, a few situations where problems may still arise: 1. If an older Cargo takes a newer lockfile (with checksums) and updates it with a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then the `[metadata]` section will not be updated appropriately. This modification would require a newer Cargo to come in and update the checksums for such a modification. 2. Today Cargo can only calculate checksums for registry sources, but we may eventually want to support other sources like git (or just straight-up path sources). If future Cargo implements support for this sort of checksum, then it's the same problem as above where older Cargos will not know how to keep the checksum in sync
2016-02-03 19:04:07 +00:00
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
Add sha256 checksums to the lockfile This commit changes how lock files are encoded by checksums for each package in the lockfile to the `[metadata]` section. The previous commit implemented the ability to redirect sources, but the core assumption there was that a package coming from two different locations was always the same. An inevitable case, however, is that a source gets corrupted or, worse, ships a modified version of a crate to introduce instability between two "mirrors". The purpose of adding checksums will be to resolve this discrepancy. Each crate coming from crates.io will now record its sha256 checksum in the lock file. When a lock file already exists, the new checksum for a crate will be checked against it, and if they differ compilation will be aborted. Currently only registry crates will have sha256 checksums listed, all other sources do not have checksums at this time. The astute may notice that if the lock file format is changing, then a lock file generated by a newer Cargo might be mangled by an older Cargo. In anticipation of this, however, all Cargo versions published support a `[metadata]` section of the lock file which is transparently carried forward if encountered. This means that older Cargos compiling with a newer lock file will not verify checksums in the lock file, but they will carry forward the checksum information and prevent it from being removed. There are, however, a few situations where problems may still arise: 1. If an older Cargo takes a newer lockfile (with checksums) and updates it with a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then the `[metadata]` section will not be updated appropriately. This modification would require a newer Cargo to come in and update the checksums for such a modification. 2. Today Cargo can only calculate checksums for registry sources, but we may eventually want to support other sources like git (or just straight-up path sources). If future Cargo implements support for this sort of checksum, then it's the same problem as above where older Cargos will not know how to keep the checksum in sync
2016-02-03 19:04:07 +00:00
fn oldest_lockfile_still_works() {
cargo fmt
2018-03-14 15:17:44 +00:00
let cargo_commands = vec!["build", "update"];
Updated old lockfile tests
2017-10-03 14:57:49 +00:00
for cargo_command in cargo_commands {
oldest_lockfile_still_works_with_command(cargo_command);
}
}
fn oldest_lockfile_still_works_with_command(cargo_command: &str) {
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
Package::new("bar", "0.1.0").publish();
Add sha256 checksums to the lockfile This commit changes how lock files are encoded by checksums for each package in the lockfile to the `[metadata]` section. The previous commit implemented the ability to redirect sources, but the core assumption there was that a package coming from two different locations was always the same. An inevitable case, however, is that a source gets corrupted or, worse, ships a modified version of a crate to introduce instability between two "mirrors". The purpose of adding checksums will be to resolve this discrepancy. Each crate coming from crates.io will now record its sha256 checksum in the lock file. When a lock file already exists, the new checksum for a crate will be checked against it, and if they differ compilation will be aborted. Currently only registry crates will have sha256 checksums listed, all other sources do not have checksums at this time. The astute may notice that if the lock file format is changing, then a lock file generated by a newer Cargo might be mangled by an older Cargo. In anticipation of this, however, all Cargo versions published support a `[metadata]` section of the lock file which is transparently carried forward if encountered. This means that older Cargos compiling with a newer lock file will not verify checksums in the lock file, but they will carry forward the checksum information and prevent it from being removed. There are, however, a few situations where problems may still arise: 1. If an older Cargo takes a newer lockfile (with checksums) and updates it with a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then the `[metadata]` section will not be updated appropriately. This modification would require a newer Cargo to come in and update the checksums for such a modification. 2. Today Cargo can only calculate checksums for registry sources, but we may eventually want to support other sources like git (or just straight-up path sources). If future Cargo implements support for this sort of checksum, then it's the same problem as above where older Cargos will not know how to keep the checksum in sync
2016-02-03 19:04:07 +00:00
Marking Cargo.lock as generated
2019-01-14 10:20:10 +00:00
let expected_lockfile = r#"# This file is automatically @generated by Cargo.
# It is not intended for manual editing.
Change git dependencies to use `HEAD` by default This commit follows through with work started in #8522 to change the default behavior of `git` dependencies where if not branch/tag/etc is listed then `HEAD` is used instead of the `master` branch. This involves also changing the default lock file format, now including a `version` marker at the top of the file notably as well as changing the encoding of `branch=master` directives in `Cargo.toml`. If we did all our work correctly then this will be a seamless change. First released on stable in 1.47.0 (2020-10-08) Cargo has been emitting warnings about situations which may break in the future. This means that if you don't specify `branch = 'master'` but your HEAD branch isn't `master`, you've been getting a warning. Similarly if your dependency graph used both `branch = 'master'` as well as specifying nothing, you were receiving warnings as well. These two situations are broken by this commit, but it's hoped that by giving enough times with warnings we don't actually break anyone in practice.
2021-02-04 16:33:33 +00:00
version = 3
Marking Cargo.lock as generated
2019-01-14 10:20:10 +00:00
[[package]]
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
name = "bar"
Do not update semantically equivalent lockfiles with --frozen/--locked. A previous patch in #4684 attempted to fix this, but didn't work for the case where the [root] crate wasn't the first crate in the sorted package array.
2017-11-12 17:57:05 +00:00
version = "0.1.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
Update lock file encodings on changes This commit alters Cargo's lockfile encoding update strategy from its previous incarnation. Previously Cargo had two versions, one for new lock files and one for old lock files. Each of these versions were different and would affect how Cargo manages lock file updates. The intention was that we'd roll out defaults to new lock files first and then later to preexisting lock files. This requires two separate changes, though, and it's not necessarily clear when to start updating old lock files. Additionally when old lock files were opted in it would break builds using `--locked` if they simply updated Cargo because Cargo would would want to bring the lock file versions forward. The purpose of this change is to solve these issues. The new strategy for updating a lock file's encoding is to simply preserve what's already existing on the filesystem until we actually decide to write out a new lock file. When Cargo updates a lock file on-disk then it will, at that time, update the lock file encoding to whatever the current default is. This means that there's only one version number to keep track of (the default for encoding). Cargo will always preserve the preexisting encoding unless another change is required to the lock file.
2020-07-28 19:17:55 +00:00
checksum = "[..]"
Do not update semantically equivalent lockfiles with --frozen/--locked. A previous patch in #4684 attempted to fix this, but didn't work for the case where the [root] crate wasn't the first crate in the sorted package array.
2017-11-12 17:57:05 +00:00
[[package]]
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
name = "foo"
Removed extraneous logic that generates [root] in cargo.lock
2017-10-03 12:18:08 +00:00
version = "0.0.1"
dependencies = [
Update lock file encodings on changes This commit alters Cargo's lockfile encoding update strategy from its previous incarnation. Previously Cargo had two versions, one for new lock files and one for old lock files. Each of these versions were different and would affect how Cargo manages lock file updates. The intention was that we'd roll out defaults to new lock files first and then later to preexisting lock files. This requires two separate changes, though, and it's not necessarily clear when to start updating old lock files. Additionally when old lock files were opted in it would break builds using `--locked` if they simply updated Cargo because Cargo would would want to bring the lock file versions forward. The purpose of this change is to solve these issues. The new strategy for updating a lock file's encoding is to simply preserve what's already existing on the filesystem until we actually decide to write out a new lock file. When Cargo updates a lock file on-disk then it will, at that time, update the lock file encoding to whatever the current default is. This means that there's only one version number to keep track of (the default for encoding). Cargo will always preserve the preexisting encoding unless another change is required to the lock file.
2020-07-28 19:17:55 +00:00
"bar",
Removed extraneous logic that generates [root] in cargo.lock
2017-10-03 12:18:08 +00:00
]
"#;
Marking Cargo.lock as generated
2019-01-14 10:20:10 +00:00
let old_lockfile = r#"
[root]
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
name = "foo"
Add sha256 checksums to the lockfile This commit changes how lock files are encoded by checksums for each package in the lockfile to the `[metadata]` section. The previous commit implemented the ability to redirect sources, but the core assumption there was that a package coming from two different locations was always the same. An inevitable case, however, is that a source gets corrupted or, worse, ships a modified version of a crate to introduce instability between two "mirrors". The purpose of adding checksums will be to resolve this discrepancy. Each crate coming from crates.io will now record its sha256 checksum in the lock file. When a lock file already exists, the new checksum for a crate will be checked against it, and if they differ compilation will be aborted. Currently only registry crates will have sha256 checksums listed, all other sources do not have checksums at this time. The astute may notice that if the lock file format is changing, then a lock file generated by a newer Cargo might be mangled by an older Cargo. In anticipation of this, however, all Cargo versions published support a `[metadata]` section of the lock file which is transparently carried forward if encountered. This means that older Cargos compiling with a newer lock file will not verify checksums in the lock file, but they will carry forward the checksum information and prevent it from being removed. There are, however, a few situations where problems may still arise: 1. If an older Cargo takes a newer lockfile (with checksums) and updates it with a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then the `[metadata]` section will not be updated appropriately. This modification would require a newer Cargo to come in and update the checksums for such a modification. 2. Today Cargo can only calculate checksums for registry sources, but we may eventually want to support other sources like git (or just straight-up path sources). If future Cargo implements support for this sort of checksum, then it's the same problem as above where older Cargos will not know how to keep the checksum in sync
2016-02-03 19:04:07 +00:00
version = "0.0.1"
dependencies = [
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
"bar 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
Add sha256 checksums to the lockfile This commit changes how lock files are encoded by checksums for each package in the lockfile to the `[metadata]` section. The previous commit implemented the ability to redirect sources, but the core assumption there was that a package coming from two different locations was always the same. An inevitable case, however, is that a source gets corrupted or, worse, ships a modified version of a crate to introduce instability between two "mirrors". The purpose of adding checksums will be to resolve this discrepancy. Each crate coming from crates.io will now record its sha256 checksum in the lock file. When a lock file already exists, the new checksum for a crate will be checked against it, and if they differ compilation will be aborted. Currently only registry crates will have sha256 checksums listed, all other sources do not have checksums at this time. The astute may notice that if the lock file format is changing, then a lock file generated by a newer Cargo might be mangled by an older Cargo. In anticipation of this, however, all Cargo versions published support a `[metadata]` section of the lock file which is transparently carried forward if encountered. This means that older Cargos compiling with a newer lock file will not verify checksums in the lock file, but they will carry forward the checksum information and prevent it from being removed. There are, however, a few situations where problems may still arise: 1. If an older Cargo takes a newer lockfile (with checksums) and updates it with a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then the `[metadata]` section will not be updated appropriately. This modification would require a newer Cargo to come in and update the checksums for such a modification. 2. Today Cargo can only calculate checksums for registry sources, but we may eventually want to support other sources like git (or just straight-up path sources). If future Cargo implements support for this sort of checksum, then it's the same problem as above where older Cargos will not know how to keep the checksum in sync
2016-02-03 19:04:07 +00:00
]
[[package]]
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
name = "bar"
Add sha256 checksums to the lockfile This commit changes how lock files are encoded by checksums for each package in the lockfile to the `[metadata]` section. The previous commit implemented the ability to redirect sources, but the core assumption there was that a package coming from two different locations was always the same. An inevitable case, however, is that a source gets corrupted or, worse, ships a modified version of a crate to introduce instability between two "mirrors". The purpose of adding checksums will be to resolve this discrepancy. Each crate coming from crates.io will now record its sha256 checksum in the lock file. When a lock file already exists, the new checksum for a crate will be checked against it, and if they differ compilation will be aborted. Currently only registry crates will have sha256 checksums listed, all other sources do not have checksums at this time. The astute may notice that if the lock file format is changing, then a lock file generated by a newer Cargo might be mangled by an older Cargo. In anticipation of this, however, all Cargo versions published support a `[metadata]` section of the lock file which is transparently carried forward if encountered. This means that older Cargos compiling with a newer lock file will not verify checksums in the lock file, but they will carry forward the checksum information and prevent it from being removed. There are, however, a few situations where problems may still arise: 1. If an older Cargo takes a newer lockfile (with checksums) and updates it with a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then the `[metadata]` section will not be updated appropriately. This modification would require a newer Cargo to come in and update the checksums for such a modification. 2. Today Cargo can only calculate checksums for registry sources, but we may eventually want to support other sources like git (or just straight-up path sources). If future Cargo implements support for this sort of checksum, then it's the same problem as above where older Cargos will not know how to keep the checksum in sync
2016-02-03 19:04:07 +00:00
version = "0.1.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
"#;
Simplify lockfile tests
2016-08-25 08:34:25 +00:00
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
let p = project()
cargo fmt
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
refactor(testsuite): Replace `[project]` with `[package]`
2022-09-22 19:50:54 +00:00
[package]
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
name = "foo"
version = "0.0.1"
authors = []
[dependencies]
bar = "0.1.0"
"#,
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.file("src/lib.rs", "")
Don't update lockfiles from previous Cargo versions if `--locked` is passed
2017-10-30 19:56:46 +00:00
.file("Cargo.lock", old_lockfile)
.build();
Updated test to ensure cargo update transforms Cargo.lock
2017-10-03 14:05:57 +00:00
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
p.cargo(cargo_command).run();
Removed extraneous logic that generates [root] in cargo.lock
2017-10-03 12:18:08 +00:00
Updated old lockfile tests
2017-10-03 14:57:49 +00:00
let lock = p.read_lockfile();
Don't export lines_match. Use better high-level interfaces to achieve the same thing.
2021-06-16 02:23:17 +00:00
assert_match_exact(expected_lockfile, &lock);
Add sha256 checksums to the lockfile This commit changes how lock files are encoded by checksums for each package in the lockfile to the `[metadata]` section. The previous commit implemented the ability to redirect sources, but the core assumption there was that a package coming from two different locations was always the same. An inevitable case, however, is that a source gets corrupted or, worse, ships a modified version of a crate to introduce instability between two "mirrors". The purpose of adding checksums will be to resolve this discrepancy. Each crate coming from crates.io will now record its sha256 checksum in the lock file. When a lock file already exists, the new checksum for a crate will be checked against it, and if they differ compilation will be aborted. Currently only registry crates will have sha256 checksums listed, all other sources do not have checksums at this time. The astute may notice that if the lock file format is changing, then a lock file generated by a newer Cargo might be mangled by an older Cargo. In anticipation of this, however, all Cargo versions published support a `[metadata]` section of the lock file which is transparently carried forward if encountered. This means that older Cargos compiling with a newer lock file will not verify checksums in the lock file, but they will carry forward the checksum information and prevent it from being removed. There are, however, a few situations where problems may still arise: 1. If an older Cargo takes a newer lockfile (with checksums) and updates it with a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then the `[metadata]` section will not be updated appropriately. This modification would require a newer Cargo to come in and update the checksums for such a modification. 2. Today Cargo can only calculate checksums for registry sources, but we may eventually want to support other sources like git (or just straight-up path sources). If future Cargo implements support for this sort of checksum, then it's the same problem as above where older Cargos will not know how to keep the checksum in sync
2016-02-03 19:04:07 +00:00
}
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
Don't update lockfiles from previous Cargo versions if `--locked` is passed
2017-10-30 19:56:46 +00:00
fn frozen_flag_preserves_old_lockfile() {
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
let cksum = Package::new("bar", "0.1.0").publish();
Don't update lockfiles from previous Cargo versions if `--locked` is passed
2017-10-30 19:56:46 +00:00
Fix the lockfile-compat test The newest version of `tar` tweaks the checksum here slightly as the tarball is slightly different, so this just updates the test to pull the checksum from the publication rather than hardcoding it.
2017-11-29 01:44:25 +00:00
let old_lockfile = format!(
Don't update lockfiles from previous Cargo versions if `--locked` is passed
2017-10-30 19:56:46 +00:00
r#"[root]
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
name = "foo"
Don't update lockfiles from previous Cargo versions if `--locked` is passed
2017-10-30 19:56:46 +00:00
version = "0.0.1"
dependencies = [
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
"bar 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
Don't update lockfiles from previous Cargo versions if `--locked` is passed
2017-10-30 19:56:46 +00:00
]
[[package]]
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
name = "bar"
Don't update lockfiles from previous Cargo versions if `--locked` is passed
2017-10-30 19:56:46 +00:00
version = "0.1.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
[metadata]
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
"checksum bar 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)" = "{}"
Fix the lockfile-compat test The newest version of `tar` tweaks the checksum here slightly as the tarball is slightly different, so this just updates the test to pull the checksum from the publication rather than hardcoding it.
2017-11-29 01:44:25 +00:00
"#,
cargo fmt
2018-03-14 15:17:44 +00:00
cksum,
Fix the lockfile-compat test The newest version of `tar` tweaks the checksum here slightly as the tarball is slightly different, so this just updates the test to pull the checksum from the publication rather than hardcoding it.
2017-11-29 01:44:25 +00:00
);
Don't update lockfiles from previous Cargo versions if `--locked` is passed
2017-10-30 19:56:46 +00:00
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
let p = project()
cargo fmt
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
refactor(testsuite): Replace `[project]` with `[package]`
2022-09-22 19:50:54 +00:00
[package]
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
name = "foo"
version = "0.0.1"
authors = []
[dependencies]
bar = "0.1.0"
"#,
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.file("src/lib.rs", "")
Fix the lockfile-compat test The newest version of `tar` tweaks the checksum here slightly as the tarball is slightly different, so this just updates the test to pull the checksum from the publication rather than hardcoding it.
2017-11-29 01:44:25 +00:00
.file("Cargo.lock", &old_lockfile)
Don't update lockfiles from previous Cargo versions if `--locked` is passed
2017-10-30 19:56:46 +00:00
.build();
chore: update `lockfile_compat` tests to use check
2023-02-16 00:04:09 +00:00
p.cargo("check --locked").run();
Don't update lockfiles from previous Cargo versions if `--locked` is passed
2017-10-30 19:56:46 +00:00
let lock = p.read_lockfile();
Don't export lines_match. Use better high-level interfaces to achieve the same thing.
2021-06-16 02:23:17 +00:00
assert_match_exact(&old_lockfile, &lock);
Don't update lockfiles from previous Cargo versions if `--locked` is passed
2017-10-30 19:56:46 +00:00
}
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
Add sha256 checksums to the lockfile This commit changes how lock files are encoded by checksums for each package in the lockfile to the `[metadata]` section. The previous commit implemented the ability to redirect sources, but the core assumption there was that a package coming from two different locations was always the same. An inevitable case, however, is that a source gets corrupted or, worse, ships a modified version of a crate to introduce instability between two "mirrors". The purpose of adding checksums will be to resolve this discrepancy. Each crate coming from crates.io will now record its sha256 checksum in the lock file. When a lock file already exists, the new checksum for a crate will be checked against it, and if they differ compilation will be aborted. Currently only registry crates will have sha256 checksums listed, all other sources do not have checksums at this time. The astute may notice that if the lock file format is changing, then a lock file generated by a newer Cargo might be mangled by an older Cargo. In anticipation of this, however, all Cargo versions published support a `[metadata]` section of the lock file which is transparently carried forward if encountered. This means that older Cargos compiling with a newer lock file will not verify checksums in the lock file, but they will carry forward the checksum information and prevent it from being removed. There are, however, a few situations where problems may still arise: 1. If an older Cargo takes a newer lockfile (with checksums) and updates it with a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then the `[metadata]` section will not be updated appropriately. This modification would require a newer Cargo to come in and update the checksums for such a modification. 2. Today Cargo can only calculate checksums for registry sources, but we may eventually want to support other sources like git (or just straight-up path sources). If future Cargo implements support for this sort of checksum, then it's the same problem as above where older Cargos will not know how to keep the checksum in sync
2016-02-03 19:04:07 +00:00
fn totally_wild_checksums_works() {
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
Package::new("bar", "0.1.0").publish();
Add sha256 checksums to the lockfile This commit changes how lock files are encoded by checksums for each package in the lockfile to the `[metadata]` section. The previous commit implemented the ability to redirect sources, but the core assumption there was that a package coming from two different locations was always the same. An inevitable case, however, is that a source gets corrupted or, worse, ships a modified version of a crate to introduce instability between two "mirrors". The purpose of adding checksums will be to resolve this discrepancy. Each crate coming from crates.io will now record its sha256 checksum in the lock file. When a lock file already exists, the new checksum for a crate will be checked against it, and if they differ compilation will be aborted. Currently only registry crates will have sha256 checksums listed, all other sources do not have checksums at this time. The astute may notice that if the lock file format is changing, then a lock file generated by a newer Cargo might be mangled by an older Cargo. In anticipation of this, however, all Cargo versions published support a `[metadata]` section of the lock file which is transparently carried forward if encountered. This means that older Cargos compiling with a newer lock file will not verify checksums in the lock file, but they will carry forward the checksum information and prevent it from being removed. There are, however, a few situations where problems may still arise: 1. If an older Cargo takes a newer lockfile (with checksums) and updates it with a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then the `[metadata]` section will not be updated appropriately. This modification would require a newer Cargo to come in and update the checksums for such a modification. 2. Today Cargo can only calculate checksums for registry sources, but we may eventually want to support other sources like git (or just straight-up path sources). If future Cargo implements support for this sort of checksum, then it's the same problem as above where older Cargos will not know how to keep the checksum in sync
2016-02-03 19:04:07 +00:00
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
let p = project()
cargo fmt
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
refactor(testsuite): Replace `[project]` with `[package]`
2022-09-22 19:50:54 +00:00
[package]
Update lock file encodings on changes This commit alters Cargo's lockfile encoding update strategy from its previous incarnation. Previously Cargo had two versions, one for new lock files and one for old lock files. Each of these versions were different and would affect how Cargo manages lock file updates. The intention was that we'd roll out defaults to new lock files first and then later to preexisting lock files. This requires two separate changes, though, and it's not necessarily clear when to start updating old lock files. Additionally when old lock files were opted in it would break builds using `--locked` if they simply updated Cargo because Cargo would would want to bring the lock file versions forward. The purpose of this change is to solve these issues. The new strategy for updating a lock file's encoding is to simply preserve what's already existing on the filesystem until we actually decide to write out a new lock file. When Cargo updates a lock file on-disk then it will, at that time, update the lock file encoding to whatever the current default is. This means that there's only one version number to keep track of (the default for encoding). Cargo will always preserve the preexisting encoding unless another change is required to the lock file.
2020-07-28 19:17:55 +00:00
name = "foo"
version = "0.0.1"
authors = []
Add sha256 checksums to the lockfile This commit changes how lock files are encoded by checksums for each package in the lockfile to the `[metadata]` section. The previous commit implemented the ability to redirect sources, but the core assumption there was that a package coming from two different locations was always the same. An inevitable case, however, is that a source gets corrupted or, worse, ships a modified version of a crate to introduce instability between two "mirrors". The purpose of adding checksums will be to resolve this discrepancy. Each crate coming from crates.io will now record its sha256 checksum in the lock file. When a lock file already exists, the new checksum for a crate will be checked against it, and if they differ compilation will be aborted. Currently only registry crates will have sha256 checksums listed, all other sources do not have checksums at this time. The astute may notice that if the lock file format is changing, then a lock file generated by a newer Cargo might be mangled by an older Cargo. In anticipation of this, however, all Cargo versions published support a `[metadata]` section of the lock file which is transparently carried forward if encountered. This means that older Cargos compiling with a newer lock file will not verify checksums in the lock file, but they will carry forward the checksum information and prevent it from being removed. There are, however, a few situations where problems may still arise: 1. If an older Cargo takes a newer lockfile (with checksums) and updates it with a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then the `[metadata]` section will not be updated appropriately. This modification would require a newer Cargo to come in and update the checksums for such a modification. 2. Today Cargo can only calculate checksums for registry sources, but we may eventually want to support other sources like git (or just straight-up path sources). If future Cargo implements support for this sort of checksum, then it's the same problem as above where older Cargos will not know how to keep the checksum in sync
2016-02-03 19:04:07 +00:00
Update lock file encodings on changes This commit alters Cargo's lockfile encoding update strategy from its previous incarnation. Previously Cargo had two versions, one for new lock files and one for old lock files. Each of these versions were different and would affect how Cargo manages lock file updates. The intention was that we'd roll out defaults to new lock files first and then later to preexisting lock files. This requires two separate changes, though, and it's not necessarily clear when to start updating old lock files. Additionally when old lock files were opted in it would break builds using `--locked` if they simply updated Cargo because Cargo would would want to bring the lock file versions forward. The purpose of this change is to solve these issues. The new strategy for updating a lock file's encoding is to simply preserve what's already existing on the filesystem until we actually decide to write out a new lock file. When Cargo updates a lock file on-disk then it will, at that time, update the lock file encoding to whatever the current default is. This means that there's only one version number to keep track of (the default for encoding). Cargo will always preserve the preexisting encoding unless another change is required to the lock file.
2020-07-28 19:17:55 +00:00
[dependencies]
bar = "0.1.0"
"#,
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.file("src/lib.rs", "")
cargo fmt
2018-03-14 15:17:44 +00:00
.file(
"Cargo.lock",
r#"
Removed extraneous logic that generates [root] in cargo.lock
2017-10-03 12:18:08 +00:00
[[package]]
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
name = "foo"
Add sha256 checksums to the lockfile This commit changes how lock files are encoded by checksums for each package in the lockfile to the `[metadata]` section. The previous commit implemented the ability to redirect sources, but the core assumption there was that a package coming from two different locations was always the same. An inevitable case, however, is that a source gets corrupted or, worse, ships a modified version of a crate to introduce instability between two "mirrors". The purpose of adding checksums will be to resolve this discrepancy. Each crate coming from crates.io will now record its sha256 checksum in the lock file. When a lock file already exists, the new checksum for a crate will be checked against it, and if they differ compilation will be aborted. Currently only registry crates will have sha256 checksums listed, all other sources do not have checksums at this time. The astute may notice that if the lock file format is changing, then a lock file generated by a newer Cargo might be mangled by an older Cargo. In anticipation of this, however, all Cargo versions published support a `[metadata]` section of the lock file which is transparently carried forward if encountered. This means that older Cargos compiling with a newer lock file will not verify checksums in the lock file, but they will carry forward the checksum information and prevent it from being removed. There are, however, a few situations where problems may still arise: 1. If an older Cargo takes a newer lockfile (with checksums) and updates it with a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then the `[metadata]` section will not be updated appropriately. This modification would require a newer Cargo to come in and update the checksums for such a modification. 2. Today Cargo can only calculate checksums for registry sources, but we may eventually want to support other sources like git (or just straight-up path sources). If future Cargo implements support for this sort of checksum, then it's the same problem as above where older Cargos will not know how to keep the checksum in sync
2016-02-03 19:04:07 +00:00
version = "0.0.1"
dependencies = [
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
"bar 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
Add sha256 checksums to the lockfile This commit changes how lock files are encoded by checksums for each package in the lockfile to the `[metadata]` section. The previous commit implemented the ability to redirect sources, but the core assumption there was that a package coming from two different locations was always the same. An inevitable case, however, is that a source gets corrupted or, worse, ships a modified version of a crate to introduce instability between two "mirrors". The purpose of adding checksums will be to resolve this discrepancy. Each crate coming from crates.io will now record its sha256 checksum in the lock file. When a lock file already exists, the new checksum for a crate will be checked against it, and if they differ compilation will be aborted. Currently only registry crates will have sha256 checksums listed, all other sources do not have checksums at this time. The astute may notice that if the lock file format is changing, then a lock file generated by a newer Cargo might be mangled by an older Cargo. In anticipation of this, however, all Cargo versions published support a `[metadata]` section of the lock file which is transparently carried forward if encountered. This means that older Cargos compiling with a newer lock file will not verify checksums in the lock file, but they will carry forward the checksum information and prevent it from being removed. There are, however, a few situations where problems may still arise: 1. If an older Cargo takes a newer lockfile (with checksums) and updates it with a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then the `[metadata]` section will not be updated appropriately. This modification would require a newer Cargo to come in and update the checksums for such a modification. 2. Today Cargo can only calculate checksums for registry sources, but we may eventually want to support other sources like git (or just straight-up path sources). If future Cargo implements support for this sort of checksum, then it's the same problem as above where older Cargos will not know how to keep the checksum in sync
2016-02-03 19:04:07 +00:00
]
[[package]]
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
name = "bar"
Add sha256 checksums to the lockfile This commit changes how lock files are encoded by checksums for each package in the lockfile to the `[metadata]` section. The previous commit implemented the ability to redirect sources, but the core assumption there was that a package coming from two different locations was always the same. An inevitable case, however, is that a source gets corrupted or, worse, ships a modified version of a crate to introduce instability between two "mirrors". The purpose of adding checksums will be to resolve this discrepancy. Each crate coming from crates.io will now record its sha256 checksum in the lock file. When a lock file already exists, the new checksum for a crate will be checked against it, and if they differ compilation will be aborted. Currently only registry crates will have sha256 checksums listed, all other sources do not have checksums at this time. The astute may notice that if the lock file format is changing, then a lock file generated by a newer Cargo might be mangled by an older Cargo. In anticipation of this, however, all Cargo versions published support a `[metadata]` section of the lock file which is transparently carried forward if encountered. This means that older Cargos compiling with a newer lock file will not verify checksums in the lock file, but they will carry forward the checksum information and prevent it from being removed. There are, however, a few situations where problems may still arise: 1. If an older Cargo takes a newer lockfile (with checksums) and updates it with a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then the `[metadata]` section will not be updated appropriately. This modification would require a newer Cargo to come in and update the checksums for such a modification. 2. Today Cargo can only calculate checksums for registry sources, but we may eventually want to support other sources like git (or just straight-up path sources). If future Cargo implements support for this sort of checksum, then it's the same problem as above where older Cargos will not know how to keep the checksum in sync
2016-02-03 19:04:07 +00:00
version = "0.1.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
[metadata]
"checksum baz 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)" = "checksum"
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
"checksum bar 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)" = "checksum"
cargo fmt
2018-03-14 15:17:44 +00:00
"#,
);
Simplify lockfile tests
2016-08-25 08:34:25 +00:00
cargotest/support: remove internal mutability in favor of switching types Remove is_build: Cell<bool> from ProjectBuilder and introduce a new type Project. is_build==false <-> ProjectBuilder is_build==true <-> Project Also add #[must_use] to ProjectBuilder to confirm its instances are surely consumed by its build() method to produce Project. The same goes for RepoBuilder. ProjectBuilder::cargo_process() was removed as its design heavily depended on the internal mutability. Signed-off-by: NODA, Kai <nodakai@gmail.com>
2017-07-22 03:12:21 +00:00
let p = p.build();
Add sha256 checksums to the lockfile This commit changes how lock files are encoded by checksums for each package in the lockfile to the `[metadata]` section. The previous commit implemented the ability to redirect sources, but the core assumption there was that a package coming from two different locations was always the same. An inevitable case, however, is that a source gets corrupted or, worse, ships a modified version of a crate to introduce instability between two "mirrors". The purpose of adding checksums will be to resolve this discrepancy. Each crate coming from crates.io will now record its sha256 checksum in the lock file. When a lock file already exists, the new checksum for a crate will be checked against it, and if they differ compilation will be aborted. Currently only registry crates will have sha256 checksums listed, all other sources do not have checksums at this time. The astute may notice that if the lock file format is changing, then a lock file generated by a newer Cargo might be mangled by an older Cargo. In anticipation of this, however, all Cargo versions published support a `[metadata]` section of the lock file which is transparently carried forward if encountered. This means that older Cargos compiling with a newer lock file will not verify checksums in the lock file, but they will carry forward the checksum information and prevent it from being removed. There are, however, a few situations where problems may still arise: 1. If an older Cargo takes a newer lockfile (with checksums) and updates it with a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then the `[metadata]` section will not be updated appropriately. This modification would require a newer Cargo to come in and update the checksums for such a modification. 2. Today Cargo can only calculate checksums for registry sources, but we may eventually want to support other sources like git (or just straight-up path sources). If future Cargo implements support for this sort of checksum, then it's the same problem as above where older Cargos will not know how to keep the checksum in sync
2016-02-03 19:04:07 +00:00
chore: update `lockfile_compat` tests to use check
2023-02-16 00:04:09 +00:00
p.cargo("check").run();
Add sha256 checksums to the lockfile This commit changes how lock files are encoded by checksums for each package in the lockfile to the `[metadata]` section. The previous commit implemented the ability to redirect sources, but the core assumption there was that a package coming from two different locations was always the same. An inevitable case, however, is that a source gets corrupted or, worse, ships a modified version of a crate to introduce instability between two "mirrors". The purpose of adding checksums will be to resolve this discrepancy. Each crate coming from crates.io will now record its sha256 checksum in the lock file. When a lock file already exists, the new checksum for a crate will be checked against it, and if they differ compilation will be aborted. Currently only registry crates will have sha256 checksums listed, all other sources do not have checksums at this time. The astute may notice that if the lock file format is changing, then a lock file generated by a newer Cargo might be mangled by an older Cargo. In anticipation of this, however, all Cargo versions published support a `[metadata]` section of the lock file which is transparently carried forward if encountered. This means that older Cargos compiling with a newer lock file will not verify checksums in the lock file, but they will carry forward the checksum information and prevent it from being removed. There are, however, a few situations where problems may still arise: 1. If an older Cargo takes a newer lockfile (with checksums) and updates it with a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then the `[metadata]` section will not be updated appropriately. This modification would require a newer Cargo to come in and update the checksums for such a modification. 2. Today Cargo can only calculate checksums for registry sources, but we may eventually want to support other sources like git (or just straight-up path sources). If future Cargo implements support for this sort of checksum, then it's the same problem as above where older Cargos will not know how to keep the checksum in sync
2016-02-03 19:04:07 +00:00
Simplify lockfile tests
2016-08-25 08:34:25 +00:00
let lock = p.read_lockfile();
Don't export lines_match. Use better high-level interfaces to achieve the same thing.
2021-06-16 02:23:17 +00:00
assert_match_exact(
Turn the new lock file format on by default This commit enables the support added in #7070 by default. This means that gradually over time all `Cargo.lock` files will be migrated to the new format. Cargo shipped with Rust 1.38.0 supports this new lock file format, so any project using Rust 1.38.0 or above will converge quickly onto the new lock file format and continue working. The main benefit of the new format is to be more friendly to git merge conflicts. Information is deduplicated throughout the lock file to avoid verbose `depedencies` lists and the `checksum` data is all listed inline with `[[package]]`. This has been deployed with rust-lang/rust for some time now and it subjectively at least seems to have greatly reduced the amount of bouncing that happens for touching `Cargo.lock`.
2019-11-08 23:48:04 +00:00
r#"# This file is automatically @generated by Cargo.
Marking Cargo.lock as generated
2019-01-14 10:20:10 +00:00
# It is not intended for manual editing.
Change git dependencies to use `HEAD` by default This commit follows through with work started in #8522 to change the default behavior of `git` dependencies where if not branch/tag/etc is listed then `HEAD` is used instead of the `master` branch. This involves also changing the default lock file format, now including a `version` marker at the top of the file notably as well as changing the encoding of `branch=master` directives in `Cargo.toml`. If we did all our work correctly then this will be a seamless change. First released on stable in 1.47.0 (2020-10-08) Cargo has been emitting warnings about situations which may break in the future. This means that if you don't specify `branch = 'master'` but your HEAD branch isn't `master`, you've been getting a warning. Similarly if your dependency graph used both `branch = 'master'` as well as specifying nothing, you were receiving warnings as well. These two situations are broken by this commit, but it's hoped that by giving enough times with warnings we don't actually break anyone in practice.
2021-02-04 16:33:33 +00:00
version = 3
Removed extraneous logic that generates [root] in cargo.lock
2017-10-03 12:18:08 +00:00
[[package]]
Add sha256 checksums to the lockfile This commit changes how lock files are encoded by checksums for each package in the lockfile to the `[metadata]` section. The previous commit implemented the ability to redirect sources, but the core assumption there was that a package coming from two different locations was always the same. An inevitable case, however, is that a source gets corrupted or, worse, ships a modified version of a crate to introduce instability between two "mirrors". The purpose of adding checksums will be to resolve this discrepancy. Each crate coming from crates.io will now record its sha256 checksum in the lock file. When a lock file already exists, the new checksum for a crate will be checked against it, and if they differ compilation will be aborted. Currently only registry crates will have sha256 checksums listed, all other sources do not have checksums at this time. The astute may notice that if the lock file format is changing, then a lock file generated by a newer Cargo might be mangled by an older Cargo. In anticipation of this, however, all Cargo versions published support a `[metadata]` section of the lock file which is transparently carried forward if encountered. This means that older Cargos compiling with a newer lock file will not verify checksums in the lock file, but they will carry forward the checksum information and prevent it from being removed. There are, however, a few situations where problems may still arise: 1. If an older Cargo takes a newer lockfile (with checksums) and updates it with a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then the `[metadata]` section will not be updated appropriately. This modification would require a newer Cargo to come in and update the checksums for such a modification. 2. Today Cargo can only calculate checksums for registry sources, but we may eventually want to support other sources like git (or just straight-up path sources). If future Cargo implements support for this sort of checksum, then it's the same problem as above where older Cargos will not know how to keep the checksum in sync
2016-02-03 19:04:07 +00:00
name = "bar"
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
version = "0.1.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
Update lock file encodings on changes This commit alters Cargo's lockfile encoding update strategy from its previous incarnation. Previously Cargo had two versions, one for new lock files and one for old lock files. Each of these versions were different and would affect how Cargo manages lock file updates. The intention was that we'd roll out defaults to new lock files first and then later to preexisting lock files. This requires two separate changes, though, and it's not necessarily clear when to start updating old lock files. Additionally when old lock files were opted in it would break builds using `--locked` if they simply updated Cargo because Cargo would would want to bring the lock file versions forward. The purpose of this change is to solve these issues. The new strategy for updating a lock file's encoding is to simply preserve what's already existing on the filesystem until we actually decide to write out a new lock file. When Cargo updates a lock file on-disk then it will, at that time, update the lock file encoding to whatever the current default is. This means that there's only one version number to keep track of (the default for encoding). Cargo will always preserve the preexisting encoding unless another change is required to the lock file.
2020-07-28 19:17:55 +00:00
checksum = "[..]"
Add sha256 checksums to the lockfile This commit changes how lock files are encoded by checksums for each package in the lockfile to the `[metadata]` section. The previous commit implemented the ability to redirect sources, but the core assumption there was that a package coming from two different locations was always the same. An inevitable case, however, is that a source gets corrupted or, worse, ships a modified version of a crate to introduce instability between two "mirrors". The purpose of adding checksums will be to resolve this discrepancy. Each crate coming from crates.io will now record its sha256 checksum in the lock file. When a lock file already exists, the new checksum for a crate will be checked against it, and if they differ compilation will be aborted. Currently only registry crates will have sha256 checksums listed, all other sources do not have checksums at this time. The astute may notice that if the lock file format is changing, then a lock file generated by a newer Cargo might be mangled by an older Cargo. In anticipation of this, however, all Cargo versions published support a `[metadata]` section of the lock file which is transparently carried forward if encountered. This means that older Cargos compiling with a newer lock file will not verify checksums in the lock file, but they will carry forward the checksum information and prevent it from being removed. There are, however, a few situations where problems may still arise: 1. If an older Cargo takes a newer lockfile (with checksums) and updates it with a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then the `[metadata]` section will not be updated appropriately. This modification would require a newer Cargo to come in and update the checksums for such a modification. 2. Today Cargo can only calculate checksums for registry sources, but we may eventually want to support other sources like git (or just straight-up path sources). If future Cargo implements support for this sort of checksum, then it's the same problem as above where older Cargos will not know how to keep the checksum in sync
2016-02-03 19:04:07 +00:00
[[package]]
name = "foo"
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
version = "0.0.1"
dependencies = [
Update lock file encodings on changes This commit alters Cargo's lockfile encoding update strategy from its previous incarnation. Previously Cargo had two versions, one for new lock files and one for old lock files. Each of these versions were different and would affect how Cargo manages lock file updates. The intention was that we'd roll out defaults to new lock files first and then later to preexisting lock files. This requires two separate changes, though, and it's not necessarily clear when to start updating old lock files. Additionally when old lock files were opted in it would break builds using `--locked` if they simply updated Cargo because Cargo would would want to bring the lock file versions forward. The purpose of this change is to solve these issues. The new strategy for updating a lock file's encoding is to simply preserve what's already existing on the filesystem until we actually decide to write out a new lock file. When Cargo updates a lock file on-disk then it will, at that time, update the lock file encoding to whatever the current default is. This means that there's only one version number to keep track of (the default for encoding). Cargo will always preserve the preexisting encoding unless another change is required to the lock file.
2020-07-28 19:17:55 +00:00
"bar",
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
]
Turn the new lock file format on by default This commit enables the support added in #7070 by default. This means that gradually over time all `Cargo.lock` files will be migrated to the new format. Cargo shipped with Rust 1.38.0 supports this new lock file format, so any project using Rust 1.38.0 or above will converge quickly onto the new lock file format and continue working. The main benefit of the new format is to be more friendly to git merge conflicts. Information is deduplicated throughout the lock file to avoid verbose `depedencies` lists and the `checksum` data is all listed inline with `[[package]]`. This has been deployed with rust-lang/rust for some time now and it subjectively at least seems to have greatly reduced the amount of bouncing that happens for touching `Cargo.lock`.
2019-11-08 23:48:04 +00:00
"#,
&lock,
);
Add sha256 checksums to the lockfile This commit changes how lock files are encoded by checksums for each package in the lockfile to the `[metadata]` section. The previous commit implemented the ability to redirect sources, but the core assumption there was that a package coming from two different locations was always the same. An inevitable case, however, is that a source gets corrupted or, worse, ships a modified version of a crate to introduce instability between two "mirrors". The purpose of adding checksums will be to resolve this discrepancy. Each crate coming from crates.io will now record its sha256 checksum in the lock file. When a lock file already exists, the new checksum for a crate will be checked against it, and if they differ compilation will be aborted. Currently only registry crates will have sha256 checksums listed, all other sources do not have checksums at this time. The astute may notice that if the lock file format is changing, then a lock file generated by a newer Cargo might be mangled by an older Cargo. In anticipation of this, however, all Cargo versions published support a `[metadata]` section of the lock file which is transparently carried forward if encountered. This means that older Cargos compiling with a newer lock file will not verify checksums in the lock file, but they will carry forward the checksum information and prevent it from being removed. There are, however, a few situations where problems may still arise: 1. If an older Cargo takes a newer lockfile (with checksums) and updates it with a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then the `[metadata]` section will not be updated appropriately. This modification would require a newer Cargo to come in and update the checksums for such a modification. 2. Today Cargo can only calculate checksums for registry sources, but we may eventually want to support other sources like git (or just straight-up path sources). If future Cargo implements support for this sort of checksum, then it's the same problem as above where older Cargos will not know how to keep the checksum in sync
2016-02-03 19:04:07 +00:00
}
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
Add sha256 checksums to the lockfile This commit changes how lock files are encoded by checksums for each package in the lockfile to the `[metadata]` section. The previous commit implemented the ability to redirect sources, but the core assumption there was that a package coming from two different locations was always the same. An inevitable case, however, is that a source gets corrupted or, worse, ships a modified version of a crate to introduce instability between two "mirrors". The purpose of adding checksums will be to resolve this discrepancy. Each crate coming from crates.io will now record its sha256 checksum in the lock file. When a lock file already exists, the new checksum for a crate will be checked against it, and if they differ compilation will be aborted. Currently only registry crates will have sha256 checksums listed, all other sources do not have checksums at this time. The astute may notice that if the lock file format is changing, then a lock file generated by a newer Cargo might be mangled by an older Cargo. In anticipation of this, however, all Cargo versions published support a `[metadata]` section of the lock file which is transparently carried forward if encountered. This means that older Cargos compiling with a newer lock file will not verify checksums in the lock file, but they will carry forward the checksum information and prevent it from being removed. There are, however, a few situations where problems may still arise: 1. If an older Cargo takes a newer lockfile (with checksums) and updates it with a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then the `[metadata]` section will not be updated appropriately. This modification would require a newer Cargo to come in and update the checksums for such a modification. 2. Today Cargo can only calculate checksums for registry sources, but we may eventually want to support other sources like git (or just straight-up path sources). If future Cargo implements support for this sort of checksum, then it's the same problem as above where older Cargos will not know how to keep the checksum in sync
2016-02-03 19:04:07 +00:00
fn wrong_checksum_is_an_error() {
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
Package::new("bar", "0.1.0").publish();
Add sha256 checksums to the lockfile This commit changes how lock files are encoded by checksums for each package in the lockfile to the `[metadata]` section. The previous commit implemented the ability to redirect sources, but the core assumption there was that a package coming from two different locations was always the same. An inevitable case, however, is that a source gets corrupted or, worse, ships a modified version of a crate to introduce instability between two "mirrors". The purpose of adding checksums will be to resolve this discrepancy. Each crate coming from crates.io will now record its sha256 checksum in the lock file. When a lock file already exists, the new checksum for a crate will be checked against it, and if they differ compilation will be aborted. Currently only registry crates will have sha256 checksums listed, all other sources do not have checksums at this time. The astute may notice that if the lock file format is changing, then a lock file generated by a newer Cargo might be mangled by an older Cargo. In anticipation of this, however, all Cargo versions published support a `[metadata]` section of the lock file which is transparently carried forward if encountered. This means that older Cargos compiling with a newer lock file will not verify checksums in the lock file, but they will carry forward the checksum information and prevent it from being removed. There are, however, a few situations where problems may still arise: 1. If an older Cargo takes a newer lockfile (with checksums) and updates it with a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then the `[metadata]` section will not be updated appropriately. This modification would require a newer Cargo to come in and update the checksums for such a modification. 2. Today Cargo can only calculate checksums for registry sources, but we may eventually want to support other sources like git (or just straight-up path sources). If future Cargo implements support for this sort of checksum, then it's the same problem as above where older Cargos will not know how to keep the checksum in sync
2016-02-03 19:04:07 +00:00
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
let p = project()
cargo fmt
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
refactor(testsuite): Replace `[project]` with `[package]`
2022-09-22 19:50:54 +00:00
[package]
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
name = "foo"
version = "0.0.1"
authors = []
[dependencies]
bar = "0.1.0"
"#,
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.file("src/lib.rs", "")
cargo fmt
2018-03-14 15:17:44 +00:00
.file(
"Cargo.lock",
r#"
Removed extraneous logic that generates [root] in cargo.lock
2017-10-03 12:18:08 +00:00
[[package]]
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
name = "foo"
Add sha256 checksums to the lockfile This commit changes how lock files are encoded by checksums for each package in the lockfile to the `[metadata]` section. The previous commit implemented the ability to redirect sources, but the core assumption there was that a package coming from two different locations was always the same. An inevitable case, however, is that a source gets corrupted or, worse, ships a modified version of a crate to introduce instability between two "mirrors". The purpose of adding checksums will be to resolve this discrepancy. Each crate coming from crates.io will now record its sha256 checksum in the lock file. When a lock file already exists, the new checksum for a crate will be checked against it, and if they differ compilation will be aborted. Currently only registry crates will have sha256 checksums listed, all other sources do not have checksums at this time. The astute may notice that if the lock file format is changing, then a lock file generated by a newer Cargo might be mangled by an older Cargo. In anticipation of this, however, all Cargo versions published support a `[metadata]` section of the lock file which is transparently carried forward if encountered. This means that older Cargos compiling with a newer lock file will not verify checksums in the lock file, but they will carry forward the checksum information and prevent it from being removed. There are, however, a few situations where problems may still arise: 1. If an older Cargo takes a newer lockfile (with checksums) and updates it with a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then the `[metadata]` section will not be updated appropriately. This modification would require a newer Cargo to come in and update the checksums for such a modification. 2. Today Cargo can only calculate checksums for registry sources, but we may eventually want to support other sources like git (or just straight-up path sources). If future Cargo implements support for this sort of checksum, then it's the same problem as above where older Cargos will not know how to keep the checksum in sync
2016-02-03 19:04:07 +00:00
version = "0.0.1"
dependencies = [
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
"bar 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
Add sha256 checksums to the lockfile This commit changes how lock files are encoded by checksums for each package in the lockfile to the `[metadata]` section. The previous commit implemented the ability to redirect sources, but the core assumption there was that a package coming from two different locations was always the same. An inevitable case, however, is that a source gets corrupted or, worse, ships a modified version of a crate to introduce instability between two "mirrors". The purpose of adding checksums will be to resolve this discrepancy. Each crate coming from crates.io will now record its sha256 checksum in the lock file. When a lock file already exists, the new checksum for a crate will be checked against it, and if they differ compilation will be aborted. Currently only registry crates will have sha256 checksums listed, all other sources do not have checksums at this time. The astute may notice that if the lock file format is changing, then a lock file generated by a newer Cargo might be mangled by an older Cargo. In anticipation of this, however, all Cargo versions published support a `[metadata]` section of the lock file which is transparently carried forward if encountered. This means that older Cargos compiling with a newer lock file will not verify checksums in the lock file, but they will carry forward the checksum information and prevent it from being removed. There are, however, a few situations where problems may still arise: 1. If an older Cargo takes a newer lockfile (with checksums) and updates it with a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then the `[metadata]` section will not be updated appropriately. This modification would require a newer Cargo to come in and update the checksums for such a modification. 2. Today Cargo can only calculate checksums for registry sources, but we may eventually want to support other sources like git (or just straight-up path sources). If future Cargo implements support for this sort of checksum, then it's the same problem as above where older Cargos will not know how to keep the checksum in sync
2016-02-03 19:04:07 +00:00
]
[[package]]
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
name = "bar"
Add sha256 checksums to the lockfile This commit changes how lock files are encoded by checksums for each package in the lockfile to the `[metadata]` section. The previous commit implemented the ability to redirect sources, but the core assumption there was that a package coming from two different locations was always the same. An inevitable case, however, is that a source gets corrupted or, worse, ships a modified version of a crate to introduce instability between two "mirrors". The purpose of adding checksums will be to resolve this discrepancy. Each crate coming from crates.io will now record its sha256 checksum in the lock file. When a lock file already exists, the new checksum for a crate will be checked against it, and if they differ compilation will be aborted. Currently only registry crates will have sha256 checksums listed, all other sources do not have checksums at this time. The astute may notice that if the lock file format is changing, then a lock file generated by a newer Cargo might be mangled by an older Cargo. In anticipation of this, however, all Cargo versions published support a `[metadata]` section of the lock file which is transparently carried forward if encountered. This means that older Cargos compiling with a newer lock file will not verify checksums in the lock file, but they will carry forward the checksum information and prevent it from being removed. There are, however, a few situations where problems may still arise: 1. If an older Cargo takes a newer lockfile (with checksums) and updates it with a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then the `[metadata]` section will not be updated appropriately. This modification would require a newer Cargo to come in and update the checksums for such a modification. 2. Today Cargo can only calculate checksums for registry sources, but we may eventually want to support other sources like git (or just straight-up path sources). If future Cargo implements support for this sort of checksum, then it's the same problem as above where older Cargos will not know how to keep the checksum in sync
2016-02-03 19:04:07 +00:00
version = "0.1.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
[metadata]
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
"checksum bar 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)" = "checksum"
cargo fmt
2018-03-14 15:17:44 +00:00
"#,
);
Simplify lockfile tests
2016-08-25 08:34:25 +00:00
cargotest/support: remove internal mutability in favor of switching types Remove is_build: Cell<bool> from ProjectBuilder and introduce a new type Project. is_build==false <-> ProjectBuilder is_build==true <-> Project Also add #[must_use] to ProjectBuilder to confirm its instances are surely consumed by its build() method to produce Project. The same goes for RepoBuilder. ProjectBuilder::cargo_process() was removed as its design heavily depended on the internal mutability. Signed-off-by: NODA, Kai <nodakai@gmail.com>
2017-07-22 03:12:21 +00:00
let p = p.build();
Add sha256 checksums to the lockfile This commit changes how lock files are encoded by checksums for each package in the lockfile to the `[metadata]` section. The previous commit implemented the ability to redirect sources, but the core assumption there was that a package coming from two different locations was always the same. An inevitable case, however, is that a source gets corrupted or, worse, ships a modified version of a crate to introduce instability between two "mirrors". The purpose of adding checksums will be to resolve this discrepancy. Each crate coming from crates.io will now record its sha256 checksum in the lock file. When a lock file already exists, the new checksum for a crate will be checked against it, and if they differ compilation will be aborted. Currently only registry crates will have sha256 checksums listed, all other sources do not have checksums at this time. The astute may notice that if the lock file format is changing, then a lock file generated by a newer Cargo might be mangled by an older Cargo. In anticipation of this, however, all Cargo versions published support a `[metadata]` section of the lock file which is transparently carried forward if encountered. This means that older Cargos compiling with a newer lock file will not verify checksums in the lock file, but they will carry forward the checksum information and prevent it from being removed. There are, however, a few situations where problems may still arise: 1. If an older Cargo takes a newer lockfile (with checksums) and updates it with a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then the `[metadata]` section will not be updated appropriately. This modification would require a newer Cargo to come in and update the checksums for such a modification. 2. Today Cargo can only calculate checksums for registry sources, but we may eventually want to support other sources like git (or just straight-up path sources). If future Cargo implements support for this sort of checksum, then it's the same problem as above where older Cargos will not know how to keep the checksum in sync
2016-02-03 19:04:07 +00:00
chore: update `lockfile_compat` tests to use check
2023-02-16 00:04:09 +00:00
p.cargo("check")
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
.with_status(101)
.with_stderr(
cargo fmt
2018-03-14 15:17:44 +00:00
"\
Update tests to new Updating msg format
2018-09-08 09:23:57 +00:00
[UPDATING] `[..]` index
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
error: checksum for `bar v0.1.0` changed between lock files
Add sha256 checksums to the lockfile This commit changes how lock files are encoded by checksums for each package in the lockfile to the `[metadata]` section. The previous commit implemented the ability to redirect sources, but the core assumption there was that a package coming from two different locations was always the same. An inevitable case, however, is that a source gets corrupted or, worse, ships a modified version of a crate to introduce instability between two "mirrors". The purpose of adding checksums will be to resolve this discrepancy. Each crate coming from crates.io will now record its sha256 checksum in the lock file. When a lock file already exists, the new checksum for a crate will be checked against it, and if they differ compilation will be aborted. Currently only registry crates will have sha256 checksums listed, all other sources do not have checksums at this time. The astute may notice that if the lock file format is changing, then a lock file generated by a newer Cargo might be mangled by an older Cargo. In anticipation of this, however, all Cargo versions published support a `[metadata]` section of the lock file which is transparently carried forward if encountered. This means that older Cargos compiling with a newer lock file will not verify checksums in the lock file, but they will carry forward the checksum information and prevent it from being removed. There are, however, a few situations where problems may still arise: 1. If an older Cargo takes a newer lockfile (with checksums) and updates it with a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then the `[metadata]` section will not be updated appropriately. This modification would require a newer Cargo to come in and update the checksums for such a modification. 2. Today Cargo can only calculate checksums for registry sources, but we may eventually want to support other sources like git (or just straight-up path sources). If future Cargo implements support for this sort of checksum, then it's the same problem as above where older Cargos will not know how to keep the checksum in sync
2016-02-03 19:04:07 +00:00
this could be indicative of a few possible errors:
* the lock file is corrupt
Various cosmetic improvements.
2019-02-03 04:01:23 +00:00
* a replacement source in use (e.g., a mirror) returned a different checksum
Add sha256 checksums to the lockfile This commit changes how lock files are encoded by checksums for each package in the lockfile to the `[metadata]` section. The previous commit implemented the ability to redirect sources, but the core assumption there was that a package coming from two different locations was always the same. An inevitable case, however, is that a source gets corrupted or, worse, ships a modified version of a crate to introduce instability between two "mirrors". The purpose of adding checksums will be to resolve this discrepancy. Each crate coming from crates.io will now record its sha256 checksum in the lock file. When a lock file already exists, the new checksum for a crate will be checked against it, and if they differ compilation will be aborted. Currently only registry crates will have sha256 checksums listed, all other sources do not have checksums at this time. The astute may notice that if the lock file format is changing, then a lock file generated by a newer Cargo might be mangled by an older Cargo. In anticipation of this, however, all Cargo versions published support a `[metadata]` section of the lock file which is transparently carried forward if encountered. This means that older Cargos compiling with a newer lock file will not verify checksums in the lock file, but they will carry forward the checksum information and prevent it from being removed. There are, however, a few situations where problems may still arise: 1. If an older Cargo takes a newer lockfile (with checksums) and updates it with a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then the `[metadata]` section will not be updated appropriately. This modification would require a newer Cargo to come in and update the checksums for such a modification. 2. Today Cargo can only calculate checksums for registry sources, but we may eventually want to support other sources like git (or just straight-up path sources). If future Cargo implements support for this sort of checksum, then it's the same problem as above where older Cargos will not know how to keep the checksum in sync
2016-02-03 19:04:07 +00:00
* the source itself may be corrupt in one way or another
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
unable to verify that `bar v0.1.0` is the same as when the lockfile was generated
Add sha256 checksums to the lockfile This commit changes how lock files are encoded by checksums for each package in the lockfile to the `[metadata]` section. The previous commit implemented the ability to redirect sources, but the core assumption there was that a package coming from two different locations was always the same. An inevitable case, however, is that a source gets corrupted or, worse, ships a modified version of a crate to introduce instability between two "mirrors". The purpose of adding checksums will be to resolve this discrepancy. Each crate coming from crates.io will now record its sha256 checksum in the lock file. When a lock file already exists, the new checksum for a crate will be checked against it, and if they differ compilation will be aborted. Currently only registry crates will have sha256 checksums listed, all other sources do not have checksums at this time. The astute may notice that if the lock file format is changing, then a lock file generated by a newer Cargo might be mangled by an older Cargo. In anticipation of this, however, all Cargo versions published support a `[metadata]` section of the lock file which is transparently carried forward if encountered. This means that older Cargos compiling with a newer lock file will not verify checksums in the lock file, but they will carry forward the checksum information and prevent it from being removed. There are, however, a few situations where problems may still arise: 1. If an older Cargo takes a newer lockfile (with checksums) and updates it with a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then the `[metadata]` section will not be updated appropriately. This modification would require a newer Cargo to come in and update the checksums for such a modification. 2. Today Cargo can only calculate checksums for registry sources, but we may eventually want to support other sources like git (or just straight-up path sources). If future Cargo implements support for this sort of checksum, then it's the same problem as above where older Cargos will not know how to keep the checksum in sync
2016-02-03 19:04:07 +00:00
cargo fmt
2018-03-14 15:17:44 +00:00
",
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.run();
Add sha256 checksums to the lockfile This commit changes how lock files are encoded by checksums for each package in the lockfile to the `[metadata]` section. The previous commit implemented the ability to redirect sources, but the core assumption there was that a package coming from two different locations was always the same. An inevitable case, however, is that a source gets corrupted or, worse, ships a modified version of a crate to introduce instability between two "mirrors". The purpose of adding checksums will be to resolve this discrepancy. Each crate coming from crates.io will now record its sha256 checksum in the lock file. When a lock file already exists, the new checksum for a crate will be checked against it, and if they differ compilation will be aborted. Currently only registry crates will have sha256 checksums listed, all other sources do not have checksums at this time. The astute may notice that if the lock file format is changing, then a lock file generated by a newer Cargo might be mangled by an older Cargo. In anticipation of this, however, all Cargo versions published support a `[metadata]` section of the lock file which is transparently carried forward if encountered. This means that older Cargos compiling with a newer lock file will not verify checksums in the lock file, but they will carry forward the checksum information and prevent it from being removed. There are, however, a few situations where problems may still arise: 1. If an older Cargo takes a newer lockfile (with checksums) and updates it with a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then the `[metadata]` section will not be updated appropriately. This modification would require a newer Cargo to come in and update the checksums for such a modification. 2. Today Cargo can only calculate checksums for registry sources, but we may eventually want to support other sources like git (or just straight-up path sources). If future Cargo implements support for this sort of checksum, then it's the same problem as above where older Cargos will not know how to keep the checksum in sync
2016-02-03 19:04:07 +00:00
}
Various cosmetic improvements.
2019-02-03 04:01:23 +00:00
// If the checksum is unlisted in the lock file (e.g., <none>) yet we can
// calculate it (e.g., it's a registry dep), then we should in theory just fill
Add sha256 checksums to the lockfile This commit changes how lock files are encoded by checksums for each package in the lockfile to the `[metadata]` section. The previous commit implemented the ability to redirect sources, but the core assumption there was that a package coming from two different locations was always the same. An inevitable case, however, is that a source gets corrupted or, worse, ships a modified version of a crate to introduce instability between two "mirrors". The purpose of adding checksums will be to resolve this discrepancy. Each crate coming from crates.io will now record its sha256 checksum in the lock file. When a lock file already exists, the new checksum for a crate will be checked against it, and if they differ compilation will be aborted. Currently only registry crates will have sha256 checksums listed, all other sources do not have checksums at this time. The astute may notice that if the lock file format is changing, then a lock file generated by a newer Cargo might be mangled by an older Cargo. In anticipation of this, however, all Cargo versions published support a `[metadata]` section of the lock file which is transparently carried forward if encountered. This means that older Cargos compiling with a newer lock file will not verify checksums in the lock file, but they will carry forward the checksum information and prevent it from being removed. There are, however, a few situations where problems may still arise: 1. If an older Cargo takes a newer lockfile (with checksums) and updates it with a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then the `[metadata]` section will not be updated appropriately. This modification would require a newer Cargo to come in and update the checksums for such a modification. 2. Today Cargo can only calculate checksums for registry sources, but we may eventually want to support other sources like git (or just straight-up path sources). If future Cargo implements support for this sort of checksum, then it's the same problem as above where older Cargos will not know how to keep the checksum in sync
2016-02-03 19:04:07 +00:00
// it in.
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
Add sha256 checksums to the lockfile This commit changes how lock files are encoded by checksums for each package in the lockfile to the `[metadata]` section. The previous commit implemented the ability to redirect sources, but the core assumption there was that a package coming from two different locations was always the same. An inevitable case, however, is that a source gets corrupted or, worse, ships a modified version of a crate to introduce instability between two "mirrors". The purpose of adding checksums will be to resolve this discrepancy. Each crate coming from crates.io will now record its sha256 checksum in the lock file. When a lock file already exists, the new checksum for a crate will be checked against it, and if they differ compilation will be aborted. Currently only registry crates will have sha256 checksums listed, all other sources do not have checksums at this time. The astute may notice that if the lock file format is changing, then a lock file generated by a newer Cargo might be mangled by an older Cargo. In anticipation of this, however, all Cargo versions published support a `[metadata]` section of the lock file which is transparently carried forward if encountered. This means that older Cargos compiling with a newer lock file will not verify checksums in the lock file, but they will carry forward the checksum information and prevent it from being removed. There are, however, a few situations where problems may still arise: 1. If an older Cargo takes a newer lockfile (with checksums) and updates it with a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then the `[metadata]` section will not be updated appropriately. This modification would require a newer Cargo to come in and update the checksums for such a modification. 2. Today Cargo can only calculate checksums for registry sources, but we may eventually want to support other sources like git (or just straight-up path sources). If future Cargo implements support for this sort of checksum, then it's the same problem as above where older Cargos will not know how to keep the checksum in sync
2016-02-03 19:04:07 +00:00
fn unlisted_checksum_is_bad_if_we_calculate() {
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
Package::new("bar", "0.1.0").publish();
Add sha256 checksums to the lockfile This commit changes how lock files are encoded by checksums for each package in the lockfile to the `[metadata]` section. The previous commit implemented the ability to redirect sources, but the core assumption there was that a package coming from two different locations was always the same. An inevitable case, however, is that a source gets corrupted or, worse, ships a modified version of a crate to introduce instability between two "mirrors". The purpose of adding checksums will be to resolve this discrepancy. Each crate coming from crates.io will now record its sha256 checksum in the lock file. When a lock file already exists, the new checksum for a crate will be checked against it, and if they differ compilation will be aborted. Currently only registry crates will have sha256 checksums listed, all other sources do not have checksums at this time. The astute may notice that if the lock file format is changing, then a lock file generated by a newer Cargo might be mangled by an older Cargo. In anticipation of this, however, all Cargo versions published support a `[metadata]` section of the lock file which is transparently carried forward if encountered. This means that older Cargos compiling with a newer lock file will not verify checksums in the lock file, but they will carry forward the checksum information and prevent it from being removed. There are, however, a few situations where problems may still arise: 1. If an older Cargo takes a newer lockfile (with checksums) and updates it with a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then the `[metadata]` section will not be updated appropriately. This modification would require a newer Cargo to come in and update the checksums for such a modification. 2. Today Cargo can only calculate checksums for registry sources, but we may eventually want to support other sources like git (or just straight-up path sources). If future Cargo implements support for this sort of checksum, then it's the same problem as above where older Cargos will not know how to keep the checksum in sync
2016-02-03 19:04:07 +00:00
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
let p = project()
cargo fmt
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
refactor(testsuite): Replace `[project]` with `[package]`
2022-09-22 19:50:54 +00:00
[package]
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
name = "foo"
version = "0.0.1"
authors = []
[dependencies]
bar = "0.1.0"
"#,
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.file("src/lib.rs", "")
cargo fmt
2018-03-14 15:17:44 +00:00
.file(
"Cargo.lock",
r#"
Removed extraneous logic that generates [root] in cargo.lock
2017-10-03 12:18:08 +00:00
[[package]]
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
name = "foo"
Add sha256 checksums to the lockfile This commit changes how lock files are encoded by checksums for each package in the lockfile to the `[metadata]` section. The previous commit implemented the ability to redirect sources, but the core assumption there was that a package coming from two different locations was always the same. An inevitable case, however, is that a source gets corrupted or, worse, ships a modified version of a crate to introduce instability between two "mirrors". The purpose of adding checksums will be to resolve this discrepancy. Each crate coming from crates.io will now record its sha256 checksum in the lock file. When a lock file already exists, the new checksum for a crate will be checked against it, and if they differ compilation will be aborted. Currently only registry crates will have sha256 checksums listed, all other sources do not have checksums at this time. The astute may notice that if the lock file format is changing, then a lock file generated by a newer Cargo might be mangled by an older Cargo. In anticipation of this, however, all Cargo versions published support a `[metadata]` section of the lock file which is transparently carried forward if encountered. This means that older Cargos compiling with a newer lock file will not verify checksums in the lock file, but they will carry forward the checksum information and prevent it from being removed. There are, however, a few situations where problems may still arise: 1. If an older Cargo takes a newer lockfile (with checksums) and updates it with a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then the `[metadata]` section will not be updated appropriately. This modification would require a newer Cargo to come in and update the checksums for such a modification. 2. Today Cargo can only calculate checksums for registry sources, but we may eventually want to support other sources like git (or just straight-up path sources). If future Cargo implements support for this sort of checksum, then it's the same problem as above where older Cargos will not know how to keep the checksum in sync
2016-02-03 19:04:07 +00:00
version = "0.0.1"
dependencies = [
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
"bar 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
Add sha256 checksums to the lockfile This commit changes how lock files are encoded by checksums for each package in the lockfile to the `[metadata]` section. The previous commit implemented the ability to redirect sources, but the core assumption there was that a package coming from two different locations was always the same. An inevitable case, however, is that a source gets corrupted or, worse, ships a modified version of a crate to introduce instability between two "mirrors". The purpose of adding checksums will be to resolve this discrepancy. Each crate coming from crates.io will now record its sha256 checksum in the lock file. When a lock file already exists, the new checksum for a crate will be checked against it, and if they differ compilation will be aborted. Currently only registry crates will have sha256 checksums listed, all other sources do not have checksums at this time. The astute may notice that if the lock file format is changing, then a lock file generated by a newer Cargo might be mangled by an older Cargo. In anticipation of this, however, all Cargo versions published support a `[metadata]` section of the lock file which is transparently carried forward if encountered. This means that older Cargos compiling with a newer lock file will not verify checksums in the lock file, but they will carry forward the checksum information and prevent it from being removed. There are, however, a few situations where problems may still arise: 1. If an older Cargo takes a newer lockfile (with checksums) and updates it with a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then the `[metadata]` section will not be updated appropriately. This modification would require a newer Cargo to come in and update the checksums for such a modification. 2. Today Cargo can only calculate checksums for registry sources, but we may eventually want to support other sources like git (or just straight-up path sources). If future Cargo implements support for this sort of checksum, then it's the same problem as above where older Cargos will not know how to keep the checksum in sync
2016-02-03 19:04:07 +00:00
]
[[package]]
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
name = "bar"
Add sha256 checksums to the lockfile This commit changes how lock files are encoded by checksums for each package in the lockfile to the `[metadata]` section. The previous commit implemented the ability to redirect sources, but the core assumption there was that a package coming from two different locations was always the same. An inevitable case, however, is that a source gets corrupted or, worse, ships a modified version of a crate to introduce instability between two "mirrors". The purpose of adding checksums will be to resolve this discrepancy. Each crate coming from crates.io will now record its sha256 checksum in the lock file. When a lock file already exists, the new checksum for a crate will be checked against it, and if they differ compilation will be aborted. Currently only registry crates will have sha256 checksums listed, all other sources do not have checksums at this time. The astute may notice that if the lock file format is changing, then a lock file generated by a newer Cargo might be mangled by an older Cargo. In anticipation of this, however, all Cargo versions published support a `[metadata]` section of the lock file which is transparently carried forward if encountered. This means that older Cargos compiling with a newer lock file will not verify checksums in the lock file, but they will carry forward the checksum information and prevent it from being removed. There are, however, a few situations where problems may still arise: 1. If an older Cargo takes a newer lockfile (with checksums) and updates it with a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then the `[metadata]` section will not be updated appropriately. This modification would require a newer Cargo to come in and update the checksums for such a modification. 2. Today Cargo can only calculate checksums for registry sources, but we may eventually want to support other sources like git (or just straight-up path sources). If future Cargo implements support for this sort of checksum, then it's the same problem as above where older Cargos will not know how to keep the checksum in sync
2016-02-03 19:04:07 +00:00
version = "0.1.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
[metadata]
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
"checksum bar 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)" = "<none>"
cargo fmt
2018-03-14 15:17:44 +00:00
"#,
);
cargotest/support: remove internal mutability in favor of switching types Remove is_build: Cell<bool> from ProjectBuilder and introduce a new type Project. is_build==false <-> ProjectBuilder is_build==true <-> Project Also add #[must_use] to ProjectBuilder to confirm its instances are surely consumed by its build() method to produce Project. The same goes for RepoBuilder. ProjectBuilder::cargo_process() was removed as its design heavily depended on the internal mutability. Signed-off-by: NODA, Kai <nodakai@gmail.com>
2017-07-22 03:12:21 +00:00
let p = p.build();
Add sha256 checksums to the lockfile This commit changes how lock files are encoded by checksums for each package in the lockfile to the `[metadata]` section. The previous commit implemented the ability to redirect sources, but the core assumption there was that a package coming from two different locations was always the same. An inevitable case, however, is that a source gets corrupted or, worse, ships a modified version of a crate to introduce instability between two "mirrors". The purpose of adding checksums will be to resolve this discrepancy. Each crate coming from crates.io will now record its sha256 checksum in the lock file. When a lock file already exists, the new checksum for a crate will be checked against it, and if they differ compilation will be aborted. Currently only registry crates will have sha256 checksums listed, all other sources do not have checksums at this time. The astute may notice that if the lock file format is changing, then a lock file generated by a newer Cargo might be mangled by an older Cargo. In anticipation of this, however, all Cargo versions published support a `[metadata]` section of the lock file which is transparently carried forward if encountered. This means that older Cargos compiling with a newer lock file will not verify checksums in the lock file, but they will carry forward the checksum information and prevent it from being removed. There are, however, a few situations where problems may still arise: 1. If an older Cargo takes a newer lockfile (with checksums) and updates it with a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then the `[metadata]` section will not be updated appropriately. This modification would require a newer Cargo to come in and update the checksums for such a modification. 2. Today Cargo can only calculate checksums for registry sources, but we may eventually want to support other sources like git (or just straight-up path sources). If future Cargo implements support for this sort of checksum, then it's the same problem as above where older Cargos will not know how to keep the checksum in sync
2016-02-03 19:04:07 +00:00
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
p.cargo("fetch")
.with_status(101)
.with_stderr(
cargo fmt
2018-03-14 15:17:44 +00:00
"\
Update tests to new Updating msg format
2018-09-08 09:23:57 +00:00
[UPDATING] `[..]` index
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
error: checksum for `bar v0.1.0` was not previously calculated, but a checksum \
Add sha256 checksums to the lockfile This commit changes how lock files are encoded by checksums for each package in the lockfile to the `[metadata]` section. The previous commit implemented the ability to redirect sources, but the core assumption there was that a package coming from two different locations was always the same. An inevitable case, however, is that a source gets corrupted or, worse, ships a modified version of a crate to introduce instability between two "mirrors". The purpose of adding checksums will be to resolve this discrepancy. Each crate coming from crates.io will now record its sha256 checksum in the lock file. When a lock file already exists, the new checksum for a crate will be checked against it, and if they differ compilation will be aborted. Currently only registry crates will have sha256 checksums listed, all other sources do not have checksums at this time. The astute may notice that if the lock file format is changing, then a lock file generated by a newer Cargo might be mangled by an older Cargo. In anticipation of this, however, all Cargo versions published support a `[metadata]` section of the lock file which is transparently carried forward if encountered. This means that older Cargos compiling with a newer lock file will not verify checksums in the lock file, but they will carry forward the checksum information and prevent it from being removed. There are, however, a few situations where problems may still arise: 1. If an older Cargo takes a newer lockfile (with checksums) and updates it with a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then the `[metadata]` section will not be updated appropriately. This modification would require a newer Cargo to come in and update the checksums for such a modification. 2. Today Cargo can only calculate checksums for registry sources, but we may eventually want to support other sources like git (or just straight-up path sources). If future Cargo implements support for this sort of checksum, then it's the same problem as above where older Cargos will not know how to keep the checksum in sync
2016-02-03 19:04:07 +00:00
could now be calculated
this could be indicative of a few possible situations:
* the source `[..]` did not previously support checksums,
but was replaced with one that does
* newer Cargo implementations know how to checksum this source, but this
older implementation does not
* the lock file is corrupt
cargo fmt
2018-03-14 15:17:44 +00:00
",
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.run();
Add sha256 checksums to the lockfile This commit changes how lock files are encoded by checksums for each package in the lockfile to the `[metadata]` section. The previous commit implemented the ability to redirect sources, but the core assumption there was that a package coming from two different locations was always the same. An inevitable case, however, is that a source gets corrupted or, worse, ships a modified version of a crate to introduce instability between two "mirrors". The purpose of adding checksums will be to resolve this discrepancy. Each crate coming from crates.io will now record its sha256 checksum in the lock file. When a lock file already exists, the new checksum for a crate will be checked against it, and if they differ compilation will be aborted. Currently only registry crates will have sha256 checksums listed, all other sources do not have checksums at this time. The astute may notice that if the lock file format is changing, then a lock file generated by a newer Cargo might be mangled by an older Cargo. In anticipation of this, however, all Cargo versions published support a `[metadata]` section of the lock file which is transparently carried forward if encountered. This means that older Cargos compiling with a newer lock file will not verify checksums in the lock file, but they will carry forward the checksum information and prevent it from being removed. There are, however, a few situations where problems may still arise: 1. If an older Cargo takes a newer lockfile (with checksums) and updates it with a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then the `[metadata]` section will not be updated appropriately. This modification would require a newer Cargo to come in and update the checksums for such a modification. 2. Today Cargo can only calculate checksums for registry sources, but we may eventually want to support other sources like git (or just straight-up path sources). If future Cargo implements support for this sort of checksum, then it's the same problem as above where older Cargos will not know how to keep the checksum in sync
2016-02-03 19:04:07 +00:00
}
Various cosmetic improvements.
2019-02-03 04:01:23 +00:00
// If the checksum is listed in the lock file yet we cannot calculate it (e.g.,
// Git dependencies as of today), then make sure we choke.
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
Add sha256 checksums to the lockfile This commit changes how lock files are encoded by checksums for each package in the lockfile to the `[metadata]` section. The previous commit implemented the ability to redirect sources, but the core assumption there was that a package coming from two different locations was always the same. An inevitable case, however, is that a source gets corrupted or, worse, ships a modified version of a crate to introduce instability between two "mirrors". The purpose of adding checksums will be to resolve this discrepancy. Each crate coming from crates.io will now record its sha256 checksum in the lock file. When a lock file already exists, the new checksum for a crate will be checked against it, and if they differ compilation will be aborted. Currently only registry crates will have sha256 checksums listed, all other sources do not have checksums at this time. The astute may notice that if the lock file format is changing, then a lock file generated by a newer Cargo might be mangled by an older Cargo. In anticipation of this, however, all Cargo versions published support a `[metadata]` section of the lock file which is transparently carried forward if encountered. This means that older Cargos compiling with a newer lock file will not verify checksums in the lock file, but they will carry forward the checksum information and prevent it from being removed. There are, however, a few situations where problems may still arise: 1. If an older Cargo takes a newer lockfile (with checksums) and updates it with a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then the `[metadata]` section will not be updated appropriately. This modification would require a newer Cargo to come in and update the checksums for such a modification. 2. Today Cargo can only calculate checksums for registry sources, but we may eventually want to support other sources like git (or just straight-up path sources). If future Cargo implements support for this sort of checksum, then it's the same problem as above where older Cargos will not know how to keep the checksum in sync
2016-02-03 19:04:07 +00:00
fn listed_checksum_bad_if_we_cannot_compute() {
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
let git = git::new("bar", |p| {
Dedup a bunch more manifest
2018-07-24 22:35:01 +00:00
p.file("Cargo.toml", &basic_manifest("bar", "0.1.0"))
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
.file("src/lib.rs", "")
Clean up some git test support functions.
2019-08-13 05:25:36 +00:00
});
Add sha256 checksums to the lockfile This commit changes how lock files are encoded by checksums for each package in the lockfile to the `[metadata]` section. The previous commit implemented the ability to redirect sources, but the core assumption there was that a package coming from two different locations was always the same. An inevitable case, however, is that a source gets corrupted or, worse, ships a modified version of a crate to introduce instability between two "mirrors". The purpose of adding checksums will be to resolve this discrepancy. Each crate coming from crates.io will now record its sha256 checksum in the lock file. When a lock file already exists, the new checksum for a crate will be checked against it, and if they differ compilation will be aborted. Currently only registry crates will have sha256 checksums listed, all other sources do not have checksums at this time. The astute may notice that if the lock file format is changing, then a lock file generated by a newer Cargo might be mangled by an older Cargo. In anticipation of this, however, all Cargo versions published support a `[metadata]` section of the lock file which is transparently carried forward if encountered. This means that older Cargos compiling with a newer lock file will not verify checksums in the lock file, but they will carry forward the checksum information and prevent it from being removed. There are, however, a few situations where problems may still arise: 1. If an older Cargo takes a newer lockfile (with checksums) and updates it with a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then the `[metadata]` section will not be updated appropriately. This modification would require a newer Cargo to come in and update the checksums for such a modification. 2. Today Cargo can only calculate checksums for registry sources, but we may eventually want to support other sources like git (or just straight-up path sources). If future Cargo implements support for this sort of checksum, then it's the same problem as above where older Cargos will not know how to keep the checksum in sync
2016-02-03 19:04:07 +00:00
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
let p = project()
cargo fmt
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
&format!(
r#"
refactor(testsuite): Replace `[project]` with `[package]`
2022-09-22 19:50:54 +00:00
[package]
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
name = "foo"
version = "0.0.1"
authors = []
[dependencies]
bar = {{ git = '{}' }}
"#,
cargo fmt
2018-03-14 15:17:44 +00:00
git.url()
),
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.file("src/lib.rs", "")
cargo fmt
2018-03-14 15:17:44 +00:00
.file(
"Cargo.lock",
&format!(
r#"
Removed extraneous logic that generates [root] in cargo.lock
2017-10-03 12:18:08 +00:00
[[package]]
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
name = "foo"
Add sha256 checksums to the lockfile This commit changes how lock files are encoded by checksums for each package in the lockfile to the `[metadata]` section. The previous commit implemented the ability to redirect sources, but the core assumption there was that a package coming from two different locations was always the same. An inevitable case, however, is that a source gets corrupted or, worse, ships a modified version of a crate to introduce instability between two "mirrors". The purpose of adding checksums will be to resolve this discrepancy. Each crate coming from crates.io will now record its sha256 checksum in the lock file. When a lock file already exists, the new checksum for a crate will be checked against it, and if they differ compilation will be aborted. Currently only registry crates will have sha256 checksums listed, all other sources do not have checksums at this time. The astute may notice that if the lock file format is changing, then a lock file generated by a newer Cargo might be mangled by an older Cargo. In anticipation of this, however, all Cargo versions published support a `[metadata]` section of the lock file which is transparently carried forward if encountered. This means that older Cargos compiling with a newer lock file will not verify checksums in the lock file, but they will carry forward the checksum information and prevent it from being removed. There are, however, a few situations where problems may still arise: 1. If an older Cargo takes a newer lockfile (with checksums) and updates it with a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then the `[metadata]` section will not be updated appropriately. This modification would require a newer Cargo to come in and update the checksums for such a modification. 2. Today Cargo can only calculate checksums for registry sources, but we may eventually want to support other sources like git (or just straight-up path sources). If future Cargo implements support for this sort of checksum, then it's the same problem as above where older Cargos will not know how to keep the checksum in sync
2016-02-03 19:04:07 +00:00
version = "0.0.1"
dependencies = [
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
"bar 0.1.0 (git+{0})"
Add sha256 checksums to the lockfile This commit changes how lock files are encoded by checksums for each package in the lockfile to the `[metadata]` section. The previous commit implemented the ability to redirect sources, but the core assumption there was that a package coming from two different locations was always the same. An inevitable case, however, is that a source gets corrupted or, worse, ships a modified version of a crate to introduce instability between two "mirrors". The purpose of adding checksums will be to resolve this discrepancy. Each crate coming from crates.io will now record its sha256 checksum in the lock file. When a lock file already exists, the new checksum for a crate will be checked against it, and if they differ compilation will be aborted. Currently only registry crates will have sha256 checksums listed, all other sources do not have checksums at this time. The astute may notice that if the lock file format is changing, then a lock file generated by a newer Cargo might be mangled by an older Cargo. In anticipation of this, however, all Cargo versions published support a `[metadata]` section of the lock file which is transparently carried forward if encountered. This means that older Cargos compiling with a newer lock file will not verify checksums in the lock file, but they will carry forward the checksum information and prevent it from being removed. There are, however, a few situations where problems may still arise: 1. If an older Cargo takes a newer lockfile (with checksums) and updates it with a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then the `[metadata]` section will not be updated appropriately. This modification would require a newer Cargo to come in and update the checksums for such a modification. 2. Today Cargo can only calculate checksums for registry sources, but we may eventually want to support other sources like git (or just straight-up path sources). If future Cargo implements support for this sort of checksum, then it's the same problem as above where older Cargos will not know how to keep the checksum in sync
2016-02-03 19:04:07 +00:00
]
[[package]]
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
name = "bar"
Add sha256 checksums to the lockfile This commit changes how lock files are encoded by checksums for each package in the lockfile to the `[metadata]` section. The previous commit implemented the ability to redirect sources, but the core assumption there was that a package coming from two different locations was always the same. An inevitable case, however, is that a source gets corrupted or, worse, ships a modified version of a crate to introduce instability between two "mirrors". The purpose of adding checksums will be to resolve this discrepancy. Each crate coming from crates.io will now record its sha256 checksum in the lock file. When a lock file already exists, the new checksum for a crate will be checked against it, and if they differ compilation will be aborted. Currently only registry crates will have sha256 checksums listed, all other sources do not have checksums at this time. The astute may notice that if the lock file format is changing, then a lock file generated by a newer Cargo might be mangled by an older Cargo. In anticipation of this, however, all Cargo versions published support a `[metadata]` section of the lock file which is transparently carried forward if encountered. This means that older Cargos compiling with a newer lock file will not verify checksums in the lock file, but they will carry forward the checksum information and prevent it from being removed. There are, however, a few situations where problems may still arise: 1. If an older Cargo takes a newer lockfile (with checksums) and updates it with a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then the `[metadata]` section will not be updated appropriately. This modification would require a newer Cargo to come in and update the checksums for such a modification. 2. Today Cargo can only calculate checksums for registry sources, but we may eventually want to support other sources like git (or just straight-up path sources). If future Cargo implements support for this sort of checksum, then it's the same problem as above where older Cargos will not know how to keep the checksum in sync
2016-02-03 19:04:07 +00:00
version = "0.1.0"
source = "git+{0}"
[metadata]
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
"checksum bar 0.1.0 (git+{0})" = "checksum"
cargo fmt
2018-03-14 15:17:44 +00:00
"#,
git.url()
),
);
Simplify lockfile tests
2016-08-25 08:34:25 +00:00
cargotest/support: remove internal mutability in favor of switching types Remove is_build: Cell<bool> from ProjectBuilder and introduce a new type Project. is_build==false <-> ProjectBuilder is_build==true <-> Project Also add #[must_use] to ProjectBuilder to confirm its instances are surely consumed by its build() method to produce Project. The same goes for RepoBuilder. ProjectBuilder::cargo_process() was removed as its design heavily depended on the internal mutability. Signed-off-by: NODA, Kai <nodakai@gmail.com>
2017-07-22 03:12:21 +00:00
let p = p.build();
Add sha256 checksums to the lockfile This commit changes how lock files are encoded by checksums for each package in the lockfile to the `[metadata]` section. The previous commit implemented the ability to redirect sources, but the core assumption there was that a package coming from two different locations was always the same. An inevitable case, however, is that a source gets corrupted or, worse, ships a modified version of a crate to introduce instability between two "mirrors". The purpose of adding checksums will be to resolve this discrepancy. Each crate coming from crates.io will now record its sha256 checksum in the lock file. When a lock file already exists, the new checksum for a crate will be checked against it, and if they differ compilation will be aborted. Currently only registry crates will have sha256 checksums listed, all other sources do not have checksums at this time. The astute may notice that if the lock file format is changing, then a lock file generated by a newer Cargo might be mangled by an older Cargo. In anticipation of this, however, all Cargo versions published support a `[metadata]` section of the lock file which is transparently carried forward if encountered. This means that older Cargos compiling with a newer lock file will not verify checksums in the lock file, but they will carry forward the checksum information and prevent it from being removed. There are, however, a few situations where problems may still arise: 1. If an older Cargo takes a newer lockfile (with checksums) and updates it with a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then the `[metadata]` section will not be updated appropriately. This modification would require a newer Cargo to come in and update the checksums for such a modification. 2. Today Cargo can only calculate checksums for registry sources, but we may eventually want to support other sources like git (or just straight-up path sources). If future Cargo implements support for this sort of checksum, then it's the same problem as above where older Cargos will not know how to keep the checksum in sync
2016-02-03 19:04:07 +00:00
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
p.cargo("fetch")
.with_status(101)
.with_stderr(
cargo fmt
2018-03-14 15:17:44 +00:00
"\
Add sha256 checksums to the lockfile This commit changes how lock files are encoded by checksums for each package in the lockfile to the `[metadata]` section. The previous commit implemented the ability to redirect sources, but the core assumption there was that a package coming from two different locations was always the same. An inevitable case, however, is that a source gets corrupted or, worse, ships a modified version of a crate to introduce instability between two "mirrors". The purpose of adding checksums will be to resolve this discrepancy. Each crate coming from crates.io will now record its sha256 checksum in the lock file. When a lock file already exists, the new checksum for a crate will be checked against it, and if they differ compilation will be aborted. Currently only registry crates will have sha256 checksums listed, all other sources do not have checksums at this time. The astute may notice that if the lock file format is changing, then a lock file generated by a newer Cargo might be mangled by an older Cargo. In anticipation of this, however, all Cargo versions published support a `[metadata]` section of the lock file which is transparently carried forward if encountered. This means that older Cargos compiling with a newer lock file will not verify checksums in the lock file, but they will carry forward the checksum information and prevent it from being removed. There are, however, a few situations where problems may still arise: 1. If an older Cargo takes a newer lockfile (with checksums) and updates it with a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then the `[metadata]` section will not be updated appropriately. This modification would require a newer Cargo to come in and update the checksums for such a modification. 2. Today Cargo can only calculate checksums for registry sources, but we may eventually want to support other sources like git (or just straight-up path sources). If future Cargo implements support for this sort of checksum, then it's the same problem as above where older Cargos will not know how to keep the checksum in sync
2016-02-03 19:04:07 +00:00
[UPDATING] git repository `[..]`
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
error: checksum for `bar v0.1.0 ([..])` could not be calculated, but a \
Add sha256 checksums to the lockfile This commit changes how lock files are encoded by checksums for each package in the lockfile to the `[metadata]` section. The previous commit implemented the ability to redirect sources, but the core assumption there was that a package coming from two different locations was always the same. An inevitable case, however, is that a source gets corrupted or, worse, ships a modified version of a crate to introduce instability between two "mirrors". The purpose of adding checksums will be to resolve this discrepancy. Each crate coming from crates.io will now record its sha256 checksum in the lock file. When a lock file already exists, the new checksum for a crate will be checked against it, and if they differ compilation will be aborted. Currently only registry crates will have sha256 checksums listed, all other sources do not have checksums at this time. The astute may notice that if the lock file format is changing, then a lock file generated by a newer Cargo might be mangled by an older Cargo. In anticipation of this, however, all Cargo versions published support a `[metadata]` section of the lock file which is transparently carried forward if encountered. This means that older Cargos compiling with a newer lock file will not verify checksums in the lock file, but they will carry forward the checksum information and prevent it from being removed. There are, however, a few situations where problems may still arise: 1. If an older Cargo takes a newer lockfile (with checksums) and updates it with a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then the `[metadata]` section will not be updated appropriately. This modification would require a newer Cargo to come in and update the checksums for such a modification. 2. Today Cargo can only calculate checksums for registry sources, but we may eventually want to support other sources like git (or just straight-up path sources). If future Cargo implements support for this sort of checksum, then it's the same problem as above where older Cargos will not know how to keep the checksum in sync
2016-02-03 19:04:07 +00:00
checksum is listed in the existing lock file[..]
this could be indicative of a few possible situations:
* the source `[..]` supports checksums,
but was replaced with one that doesn't
* the lock file is corrupt
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
unable to verify that `bar v0.1.0 ([..])` is the same as when the lockfile was generated
Add sha256 checksums to the lockfile This commit changes how lock files are encoded by checksums for each package in the lockfile to the `[metadata]` section. The previous commit implemented the ability to redirect sources, but the core assumption there was that a package coming from two different locations was always the same. An inevitable case, however, is that a source gets corrupted or, worse, ships a modified version of a crate to introduce instability between two "mirrors". The purpose of adding checksums will be to resolve this discrepancy. Each crate coming from crates.io will now record its sha256 checksum in the lock file. When a lock file already exists, the new checksum for a crate will be checked against it, and if they differ compilation will be aborted. Currently only registry crates will have sha256 checksums listed, all other sources do not have checksums at this time. The astute may notice that if the lock file format is changing, then a lock file generated by a newer Cargo might be mangled by an older Cargo. In anticipation of this, however, all Cargo versions published support a `[metadata]` section of the lock file which is transparently carried forward if encountered. This means that older Cargos compiling with a newer lock file will not verify checksums in the lock file, but they will carry forward the checksum information and prevent it from being removed. There are, however, a few situations where problems may still arise: 1. If an older Cargo takes a newer lockfile (with checksums) and updates it with a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then the `[metadata]` section will not be updated appropriately. This modification would require a newer Cargo to come in and update the checksums for such a modification. 2. Today Cargo can only calculate checksums for registry sources, but we may eventually want to support other sources like git (or just straight-up path sources). If future Cargo implements support for this sort of checksum, then it's the same problem as above where older Cargos will not know how to keep the checksum in sync
2016-02-03 19:04:07 +00:00
cargo fmt
2018-03-14 15:17:44 +00:00
",
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.run();
Add sha256 checksums to the lockfile This commit changes how lock files are encoded by checksums for each package in the lockfile to the `[metadata]` section. The previous commit implemented the ability to redirect sources, but the core assumption there was that a package coming from two different locations was always the same. An inevitable case, however, is that a source gets corrupted or, worse, ships a modified version of a crate to introduce instability between two "mirrors". The purpose of adding checksums will be to resolve this discrepancy. Each crate coming from crates.io will now record its sha256 checksum in the lock file. When a lock file already exists, the new checksum for a crate will be checked against it, and if they differ compilation will be aborted. Currently only registry crates will have sha256 checksums listed, all other sources do not have checksums at this time. The astute may notice that if the lock file format is changing, then a lock file generated by a newer Cargo might be mangled by an older Cargo. In anticipation of this, however, all Cargo versions published support a `[metadata]` section of the lock file which is transparently carried forward if encountered. This means that older Cargos compiling with a newer lock file will not verify checksums in the lock file, but they will carry forward the checksum information and prevent it from being removed. There are, however, a few situations where problems may still arise: 1. If an older Cargo takes a newer lockfile (with checksums) and updates it with a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then the `[metadata]` section will not be updated appropriately. This modification would require a newer Cargo to come in and update the checksums for such a modification. 2. Today Cargo can only calculate checksums for registry sources, but we may eventually want to support other sources like git (or just straight-up path sources). If future Cargo implements support for this sort of checksum, then it's the same problem as above where older Cargos will not know how to keep the checksum in sync
2016-02-03 19:04:07 +00:00
}
Forward compatibility with rootless lockfiles
2016-08-20 21:27:06 +00:00
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
Regression test for lockfile format
2016-08-22 23:59:31 +00:00
fn current_lockfile_format() {
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
Package::new("bar", "0.1.0").publish();
Regression test for lockfile format
2016-08-22 23:59:31 +00:00
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
let p = project()
cargo fmt
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[package]
name = "foo"
version = "0.0.1"
authors = []
[dependencies]
bar = "0.1.0"
"#,
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.file("src/lib.rs", "");
cargotest/support: remove internal mutability in favor of switching types Remove is_build: Cell<bool> from ProjectBuilder and introduce a new type Project. is_build==false <-> ProjectBuilder is_build==true <-> Project Also add #[must_use] to ProjectBuilder to confirm its instances are surely consumed by its build() method to produce Project. The same goes for RepoBuilder. ProjectBuilder::cargo_process() was removed as its design heavily depended on the internal mutability. Signed-off-by: NODA, Kai <nodakai@gmail.com>
2017-07-22 03:12:21 +00:00
let p = p.build();
Regression test for lockfile format
2016-08-22 23:59:31 +00:00
chore: update `lockfile_compat` tests to use check
2023-02-16 00:04:09 +00:00
p.cargo("check").run();
Regression test for lockfile format
2016-08-22 23:59:31 +00:00
Simplify lockfile tests
2016-08-25 08:34:25 +00:00
let actual = p.read_lockfile();
Regression test for lockfile format
2016-08-22 23:59:31 +00:00
let expected = "\
Marking Cargo.lock as generated
2019-01-14 10:20:10 +00:00
# This file is automatically @generated by Cargo.\n# It is not intended for manual editing.
Change git dependencies to use `HEAD` by default This commit follows through with work started in #8522 to change the default behavior of `git` dependencies where if not branch/tag/etc is listed then `HEAD` is used instead of the `master` branch. This involves also changing the default lock file format, now including a `version` marker at the top of the file notably as well as changing the encoding of `branch=master` directives in `Cargo.toml`. If we did all our work correctly then this will be a seamless change. First released on stable in 1.47.0 (2020-10-08) Cargo has been emitting warnings about situations which may break in the future. This means that if you don't specify `branch = 'master'` but your HEAD branch isn't `master`, you've been getting a warning. Similarly if your dependency graph used both `branch = 'master'` as well as specifying nothing, you were receiving warnings as well. These two situations are broken by this commit, but it's hoped that by giving enough times with warnings we don't actually break anyone in practice.
2021-02-04 16:33:33 +00:00
version = 3
Removed extraneous logic that generates [root] in cargo.lock
2017-10-03 12:18:08 +00:00
[[package]]
Regression test for lockfile format
2016-08-22 23:59:31 +00:00
name = \"bar\"
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
version = \"0.1.0\"
source = \"registry+https://github.com/rust-lang/crates.io-index\"
Turn the new lock file format on by default This commit enables the support added in #7070 by default. This means that gradually over time all `Cargo.lock` files will be migrated to the new format. Cargo shipped with Rust 1.38.0 supports this new lock file format, so any project using Rust 1.38.0 or above will converge quickly onto the new lock file format and continue working. The main benefit of the new format is to be more friendly to git merge conflicts. Information is deduplicated throughout the lock file to avoid verbose `depedencies` lists and the `checksum` data is all listed inline with `[[package]]`. This has been deployed with rust-lang/rust for some time now and it subjectively at least seems to have greatly reduced the amount of bouncing that happens for touching `Cargo.lock`.
2019-11-08 23:48:04 +00:00
checksum = \"[..]\"
Regression test for lockfile format
2016-08-22 23:59:31 +00:00
[[package]]
name = \"foo\"
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
version = \"0.0.1\"
dependencies = [
Turn the new lock file format on by default This commit enables the support added in #7070 by default. This means that gradually over time all `Cargo.lock` files will be migrated to the new format. Cargo shipped with Rust 1.38.0 supports this new lock file format, so any project using Rust 1.38.0 or above will converge quickly onto the new lock file format and continue working. The main benefit of the new format is to be more friendly to git merge conflicts. Information is deduplicated throughout the lock file to avoid verbose `depedencies` lists and the `checksum` data is all listed inline with `[[package]]`. This has been deployed with rust-lang/rust for some time now and it subjectively at least seems to have greatly reduced the amount of bouncing that happens for touching `Cargo.lock`.
2019-11-08 23:48:04 +00:00
\"bar\",
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
]
Turn the new lock file format on by default This commit enables the support added in #7070 by default. This means that gradually over time all `Cargo.lock` files will be migrated to the new format. Cargo shipped with Rust 1.38.0 supports this new lock file format, so any project using Rust 1.38.0 or above will converge quickly onto the new lock file format and continue working. The main benefit of the new format is to be more friendly to git merge conflicts. Information is deduplicated throughout the lock file to avoid verbose `depedencies` lists and the `checksum` data is all listed inline with `[[package]]`. This has been deployed with rust-lang/rust for some time now and it subjectively at least seems to have greatly reduced the amount of bouncing that happens for touching `Cargo.lock`.
2019-11-08 23:48:04 +00:00
";
Don't export lines_match. Use better high-level interfaces to achieve the same thing.
2021-06-16 02:23:17 +00:00
assert_match_exact(expected, &actual);
Regression test for lockfile format
2016-08-22 23:59:31 +00:00
}
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
Forward compatibility with rootless lockfiles
2016-08-20 21:27:06 +00:00
fn lockfile_without_root() {
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
Package::new("bar", "0.1.0").publish();
Forward compatibility with rootless lockfiles
2016-08-20 21:27:06 +00:00
Marking Cargo.lock as generated
2019-01-14 10:20:10 +00:00
let lockfile = r#"
# This file is automatically @generated by Cargo.
# It is not intended for manual editing.
[[package]]
Forward compatibility with rootless lockfiles
2016-08-20 21:27:06 +00:00
name = "bar"
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
version = "0.1.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
Forward compatibility with rootless lockfiles
2016-08-20 21:27:06 +00:00
[[package]]
name = "foo"
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
version = "0.0.1"
dependencies = [
Turn the new lock file format on by default This commit enables the support added in #7070 by default. This means that gradually over time all `Cargo.lock` files will be migrated to the new format. Cargo shipped with Rust 1.38.0 supports this new lock file format, so any project using Rust 1.38.0 or above will converge quickly onto the new lock file format and continue working. The main benefit of the new format is to be more friendly to git merge conflicts. Information is deduplicated throughout the lock file to avoid verbose `depedencies` lists and the `checksum` data is all listed inline with `[[package]]`. This has been deployed with rust-lang/rust for some time now and it subjectively at least seems to have greatly reduced the amount of bouncing that happens for touching `Cargo.lock`.
2019-11-08 23:48:04 +00:00
"bar",
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
]
Forward compatibility with rootless lockfiles
2016-08-20 21:27:06 +00:00
"#;
Simplify lockfile tests
2016-08-25 08:34:25 +00:00
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
let p = project()
cargo fmt
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[package]
name = "foo"
version = "0.0.1"
authors = []
[dependencies]
bar = "0.1.0"
"#,
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.file("src/lib.rs", "")
Simplify lockfile tests
2016-08-25 08:34:25 +00:00
.file("Cargo.lock", lockfile);
cargotest/support: remove internal mutability in favor of switching types Remove is_build: Cell<bool> from ProjectBuilder and introduce a new type Project. is_build==false <-> ProjectBuilder is_build==true <-> Project Also add #[must_use] to ProjectBuilder to confirm its instances are surely consumed by its build() method to produce Project. The same goes for RepoBuilder. ProjectBuilder::cargo_process() was removed as its design heavily depended on the internal mutability. Signed-off-by: NODA, Kai <nodakai@gmail.com>
2017-07-22 03:12:21 +00:00
let p = p.build();
Forward compatibility with rootless lockfiles
2016-08-20 21:27:06 +00:00
chore: update `lockfile_compat` tests to use check
2023-02-16 00:04:09 +00:00
p.cargo("check").run();
Forward compatibility with rootless lockfiles
2016-08-20 21:27:06 +00:00
Simplify lockfile tests
2016-08-25 08:34:25 +00:00
let lock = p.read_lockfile();
Don't export lines_match. Use better high-level interfaces to achieve the same thing.
2021-06-16 02:23:17 +00:00
assert_match_exact(
Turn the new lock file format on by default This commit enables the support added in #7070 by default. This means that gradually over time all `Cargo.lock` files will be migrated to the new format. Cargo shipped with Rust 1.38.0 supports this new lock file format, so any project using Rust 1.38.0 or above will converge quickly onto the new lock file format and continue working. The main benefit of the new format is to be more friendly to git merge conflicts. Information is deduplicated throughout the lock file to avoid verbose `depedencies` lists and the `checksum` data is all listed inline with `[[package]]`. This has been deployed with rust-lang/rust for some time now and it subjectively at least seems to have greatly reduced the amount of bouncing that happens for touching `Cargo.lock`.
2019-11-08 23:48:04 +00:00
r#"# [..]
# [..]
Change git dependencies to use `HEAD` by default This commit follows through with work started in #8522 to change the default behavior of `git` dependencies where if not branch/tag/etc is listed then `HEAD` is used instead of the `master` branch. This involves also changing the default lock file format, now including a `version` marker at the top of the file notably as well as changing the encoding of `branch=master` directives in `Cargo.toml`. If we did all our work correctly then this will be a seamless change. First released on stable in 1.47.0 (2020-10-08) Cargo has been emitting warnings about situations which may break in the future. This means that if you don't specify `branch = 'master'` but your HEAD branch isn't `master`, you've been getting a warning. Similarly if your dependency graph used both `branch = 'master'` as well as specifying nothing, you were receiving warnings as well. These two situations are broken by this commit, but it's hoped that by giving enough times with warnings we don't actually break anyone in practice.
2021-02-04 16:33:33 +00:00
version = 3
Turn the new lock file format on by default This commit enables the support added in #7070 by default. This means that gradually over time all `Cargo.lock` files will be migrated to the new format. Cargo shipped with Rust 1.38.0 supports this new lock file format, so any project using Rust 1.38.0 or above will converge quickly onto the new lock file format and continue working. The main benefit of the new format is to be more friendly to git merge conflicts. Information is deduplicated throughout the lock file to avoid verbose `depedencies` lists and the `checksum` data is all listed inline with `[[package]]`. This has been deployed with rust-lang/rust for some time now and it subjectively at least seems to have greatly reduced the amount of bouncing that happens for touching `Cargo.lock`.
2019-11-08 23:48:04 +00:00
[[package]]
name = "bar"
version = "0.1.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "[..]"
[[package]]
name = "foo"
version = "0.0.1"
dependencies = [
"bar",
]
"#,
&lock,
);
Forward compatibility with rootless lockfiles
2016-08-20 21:27:06 +00:00
}
fix error message when --locked is passed but lockfile is outdated
2017-09-04 11:33:03 +00:00
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
fix error message when --locked is passed but lockfile is outdated
2017-09-04 11:33:03 +00:00
fn locked_correct_error() {
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
Package::new("bar", "0.1.0").publish();
fix error message when --locked is passed but lockfile is outdated
2017-09-04 11:33:03 +00:00
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
let p = project()
cargo fmt
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
refactor(testsuite): Replace `[project]` with `[package]`
2022-09-22 19:50:54 +00:00
[package]
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
name = "foo"
version = "0.0.1"
authors = []
[dependencies]
bar = "0.1.0"
"#,
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.file("src/lib.rs", "");
cargotest/support: remove internal mutability in favor of switching types Remove is_build: Cell<bool> from ProjectBuilder and introduce a new type Project. is_build==false <-> ProjectBuilder is_build==true <-> Project Also add #[must_use] to ProjectBuilder to confirm its instances are surely consumed by its build() method to produce Project. The same goes for RepoBuilder. ProjectBuilder::cargo_process() was removed as its design heavily depended on the internal mutability. Signed-off-by: NODA, Kai <nodakai@gmail.com>
2017-07-22 03:12:21 +00:00
let p = p.build();
fix error message when --locked is passed but lockfile is outdated
2017-09-04 11:33:03 +00:00
chore: update `lockfile_compat` tests to use check
2023-02-16 00:04:09 +00:00
p.cargo("check --locked")
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
.with_status(101)
.with_stderr(
cargo fmt
2018-03-14 15:17:44 +00:00
"\
Update tests to new Updating msg format
2018-09-08 09:23:57 +00:00
[UPDATING] `[..]` index
Specify lockfile path in --locked error msg
2018-09-20 15:51:04 +00:00
error: the lock file [CWD]/Cargo.lock needs to be updated but --locked was passed to prevent this
Adjust error message with offline and frozen.
2021-07-01 22:58:45 +00:00
If you want to try to generate the lock file without accessing the network, \
remove the --locked flag and use --offline instead.
cargo fmt
2018-03-14 15:17:44 +00:00
",
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.run();
fix error message when --locked is passed but lockfile is outdated
2017-09-04 11:33:03 +00:00
}
Optimize lock file format for git merge conflicts This commit is an attempt to refine Cargo's lock file format to generate less git merge conflicts for lock file updates as well as make it easier to manage lock file updates. The new lock file format has a few major changes: * The `[metadata]` table is no longer used to track checksums. The packages themselves now list `checksum` fields directly. * The entries in the `dependencies` key no longer unconditionally mention the version/source of the dependency. When unambiguous only the name or only the name/version are mentioned. As mentioned before the goal here is to reduce git merge conflict likelihood between two cargo updates to a lock file. By not using `[metadata]` the updates to package checksums should only happen on the package itself, not in a shared metadata table where it's easy to conflict with other updates. Additionally by making `dependencies` entries shorter it's hoped that updating a crate will only either add entries to a lock file or update lines related to just that package. It's theorized that the amount of updates necessary to a lock file are far less than today where the version has to be updated in many locations. As with all lock file format changes this new format is not turned on by default. Support is added so Cargo will preserve it if it sees it (and tests are added too), and then some time down the road we can flip the switch and turn this on by default.
2019-06-19 20:50:17 +00:00
#[cargo_test]
fn v2_format_preserved() {
let cksum = Package::new("bar", "0.1.0").publish();
let lockfile = format!(
r#"# This file is automatically @generated by Cargo.
# It is not intended for manual editing.
[[package]]
name = "bar"
version = "0.1.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "{}"
[[package]]
name = "foo"
version = "0.0.1"
dependencies = [
"bar",
]
"#,
cksum
);
let p = project()
.file(
"Cargo.toml",
r#"
refactor(testsuite): Replace `[project]` with `[package]`
2022-09-22 19:50:54 +00:00
[package]
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
name = "foo"
version = "0.0.1"
authors = []
[dependencies]
bar = "0.1.0"
"#,
Optimize lock file format for git merge conflicts This commit is an attempt to refine Cargo's lock file format to generate less git merge conflicts for lock file updates as well as make it easier to manage lock file updates. The new lock file format has a few major changes: * The `[metadata]` table is no longer used to track checksums. The packages themselves now list `checksum` fields directly. * The entries in the `dependencies` key no longer unconditionally mention the version/source of the dependency. When unambiguous only the name or only the name/version are mentioned. As mentioned before the goal here is to reduce git merge conflict likelihood between two cargo updates to a lock file. By not using `[metadata]` the updates to package checksums should only happen on the package itself, not in a shared metadata table where it's easy to conflict with other updates. Additionally by making `dependencies` entries shorter it's hoped that updating a crate will only either add entries to a lock file or update lines related to just that package. It's theorized that the amount of updates necessary to a lock file are far less than today where the version has to be updated in many locations. As with all lock file format changes this new format is not turned on by default. Support is added so Cargo will preserve it if it sees it (and tests are added too), and then some time down the road we can flip the switch and turn this on by default.
2019-06-19 20:50:17 +00:00
)
.file("src/lib.rs", "")
.file("Cargo.lock", &lockfile)
.build();
p.cargo("fetch").run();
let lock = p.read_lockfile();
Don't export lines_match. Use better high-level interfaces to achieve the same thing.
2021-06-16 02:23:17 +00:00
assert_match_exact(&lockfile, &lock);
Optimize lock file format for git merge conflicts This commit is an attempt to refine Cargo's lock file format to generate less git merge conflicts for lock file updates as well as make it easier to manage lock file updates. The new lock file format has a few major changes: * The `[metadata]` table is no longer used to track checksums. The packages themselves now list `checksum` fields directly. * The entries in the `dependencies` key no longer unconditionally mention the version/source of the dependency. When unambiguous only the name or only the name/version are mentioned. As mentioned before the goal here is to reduce git merge conflict likelihood between two cargo updates to a lock file. By not using `[metadata]` the updates to package checksums should only happen on the package itself, not in a shared metadata table where it's easy to conflict with other updates. Additionally by making `dependencies` entries shorter it's hoped that updating a crate will only either add entries to a lock file or update lines related to just that package. It's theorized that the amount of updates necessary to a lock file are far less than today where the version has to be updated in many locations. As with all lock file format changes this new format is not turned on by default. Support is added so Cargo will preserve it if it sees it (and tests are added too), and then some time down the road we can flip the switch and turn this on by default.
2019-06-19 20:50:17 +00:00
}
#[cargo_test]
fn v2_path_and_crates_io() {
let cksum010 = Package::new("a", "0.1.0").publish();
let cksum020 = Package::new("a", "0.2.0").publish();
let lockfile = format!(
r#"# This file is automatically @generated by Cargo.
# It is not intended for manual editing.
[[package]]
name = "a"
version = "0.1.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "{}"
[[package]]
name = "a"
version = "0.2.0"
[[package]]
name = "a"
version = "0.2.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "{}"
[[package]]
name = "foo"
version = "0.0.1"
dependencies = [
"a 0.1.0",
"a 0.2.0",
"a 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)",
]
"#,
cksum010, cksum020,
);
let p = project()
.file(
"Cargo.toml",
r#"
refactor(testsuite): Replace `[project]` with `[package]`
2022-09-22 19:50:54 +00:00
[package]
Optimize lock file format for git merge conflicts This commit is an attempt to refine Cargo's lock file format to generate less git merge conflicts for lock file updates as well as make it easier to manage lock file updates. The new lock file format has a few major changes: * The `[metadata]` table is no longer used to track checksums. The packages themselves now list `checksum` fields directly. * The entries in the `dependencies` key no longer unconditionally mention the version/source of the dependency. When unambiguous only the name or only the name/version are mentioned. As mentioned before the goal here is to reduce git merge conflict likelihood between two cargo updates to a lock file. By not using `[metadata]` the updates to package checksums should only happen on the package itself, not in a shared metadata table where it's easy to conflict with other updates. Additionally by making `dependencies` entries shorter it's hoped that updating a crate will only either add entries to a lock file or update lines related to just that package. It's theorized that the amount of updates necessary to a lock file are far less than today where the version has to be updated in many locations. As with all lock file format changes this new format is not turned on by default. Support is added so Cargo will preserve it if it sees it (and tests are added too), and then some time down the road we can flip the switch and turn this on by default.
2019-06-19 20:50:17 +00:00
name = "foo"
version = "0.0.1"
authors = []
[dependencies]
a = { path = 'a' }
b = { version = "0.1", package = 'a' }
c = { version = "0.2", package = 'a' }
"#,
)
.file("src/lib.rs", "")
.file(
"a/Cargo.toml",
r#"
refactor(testsuite): Replace `[project]` with `[package]`
2022-09-22 19:50:54 +00:00
[package]
Optimize lock file format for git merge conflicts This commit is an attempt to refine Cargo's lock file format to generate less git merge conflicts for lock file updates as well as make it easier to manage lock file updates. The new lock file format has a few major changes: * The `[metadata]` table is no longer used to track checksums. The packages themselves now list `checksum` fields directly. * The entries in the `dependencies` key no longer unconditionally mention the version/source of the dependency. When unambiguous only the name or only the name/version are mentioned. As mentioned before the goal here is to reduce git merge conflict likelihood between two cargo updates to a lock file. By not using `[metadata]` the updates to package checksums should only happen on the package itself, not in a shared metadata table where it's easy to conflict with other updates. Additionally by making `dependencies` entries shorter it's hoped that updating a crate will only either add entries to a lock file or update lines related to just that package. It's theorized that the amount of updates necessary to a lock file are far less than today where the version has to be updated in many locations. As with all lock file format changes this new format is not turned on by default. Support is added so Cargo will preserve it if it sees it (and tests are added too), and then some time down the road we can flip the switch and turn this on by default.
2019-06-19 20:50:17 +00:00
name = "a"
version = "0.2.0"
"#,
)
.file("a/src/lib.rs", "")
.file("Cargo.lock", &lockfile)
.build();
p.cargo("fetch").run();
p.cargo("fetch").run();
let lock = p.read_lockfile();
Don't export lines_match. Use better high-level interfaces to achieve the same thing.
2021-06-16 02:23:17 +00:00
assert_match_exact(&lockfile, &lock);
Optimize lock file format for git merge conflicts This commit is an attempt to refine Cargo's lock file format to generate less git merge conflicts for lock file updates as well as make it easier to manage lock file updates. The new lock file format has a few major changes: * The `[metadata]` table is no longer used to track checksums. The packages themselves now list `checksum` fields directly. * The entries in the `dependencies` key no longer unconditionally mention the version/source of the dependency. When unambiguous only the name or only the name/version are mentioned. As mentioned before the goal here is to reduce git merge conflict likelihood between two cargo updates to a lock file. By not using `[metadata]` the updates to package checksums should only happen on the package itself, not in a shared metadata table where it's easy to conflict with other updates. Additionally by making `dependencies` entries shorter it's hoped that updating a crate will only either add entries to a lock file or update lines related to just that package. It's theorized that the amount of updates necessary to a lock file are far less than today where the version has to be updated in many locations. As with all lock file format changes this new format is not turned on by default. Support is added so Cargo will preserve it if it sees it (and tests are added too), and then some time down the road we can flip the switch and turn this on by default.
2019-06-19 20:50:17 +00:00
}
Plan for a V3 lockfile format This commit lays the groundwork for an eventual V3 of the lock file format. The changes in this format are: * A `version` indicator will be at the top of the file so we don't have to guess what format the lock is in, we know for sure. Additionally Cargo now reading a super-from-the-future lock file format will give a better error. * Git dependencies with `Branch("master")` will be encoded with `?branch=master` instead of with nothing. The motivation for this change is to eventually switch Cargo's interpretation of default git branches.
2020-07-20 17:11:25 +00:00
#[cargo_test]
fn v3_and_git() {
let (git_project, repo) = git::new_repo("dep1", |project| {
project
.file("Cargo.toml", &basic_lib_manifest("dep1"))
.file("src/lib.rs", "")
});
let head_id = repo.head().unwrap().target().unwrap();
let lockfile = format!(
r#"# This file is automatically @generated by Cargo.
# It is not intended for manual editing.
Use `version = 3`, not `version = 1`
2020-07-23 15:14:10 +00:00
version = 3
Plan for a V3 lockfile format This commit lays the groundwork for an eventual V3 of the lock file format. The changes in this format are: * A `version` indicator will be at the top of the file so we don't have to guess what format the lock is in, we know for sure. Additionally Cargo now reading a super-from-the-future lock file format will give a better error. * Git dependencies with `Branch("master")` will be encoded with `?branch=master` instead of with nothing. The motivation for this change is to eventually switch Cargo's interpretation of default git branches.
2020-07-20 17:11:25 +00:00
[[package]]
name = "dep1"
version = "0.5.0"
source = "git+{}?branch=master#{}"
[[package]]
name = "foo"
version = "0.0.1"
dependencies = [
"dep1",
]
"#,
git_project.url(),
head_id,
);
let p = project()
.file(
"Cargo.toml",
&format!(
r#"
refactor(testsuite): Replace `[project]` with `[package]`
2022-09-22 19:50:54 +00:00
[package]
Plan for a V3 lockfile format This commit lays the groundwork for an eventual V3 of the lock file format. The changes in this format are: * A `version` indicator will be at the top of the file so we don't have to guess what format the lock is in, we know for sure. Additionally Cargo now reading a super-from-the-future lock file format will give a better error. * Git dependencies with `Branch("master")` will be encoded with `?branch=master` instead of with nothing. The motivation for this change is to eventually switch Cargo's interpretation of default git branches.
2020-07-20 17:11:25 +00:00
name = "foo"
version = "0.0.1"
authors = []
[dependencies]
dep1 = {{ git = '{}', branch = 'master' }}
"#,
git_project.url(),
),
)
.file("src/lib.rs", "")
Use `version = 3`, not `version = 1`
2020-07-23 15:14:10 +00:00
.file("Cargo.lock", "version = 3")
Plan for a V3 lockfile format This commit lays the groundwork for an eventual V3 of the lock file format. The changes in this format are: * A `version` indicator will be at the top of the file so we don't have to guess what format the lock is in, we know for sure. Additionally Cargo now reading a super-from-the-future lock file format will give a better error. * Git dependencies with `Branch("master")` will be encoded with `?branch=master` instead of with nothing. The motivation for this change is to eventually switch Cargo's interpretation of default git branches.
2020-07-20 17:11:25 +00:00
.build();
p.cargo("fetch").run();
let lock = p.read_lockfile();
Don't export lines_match. Use better high-level interfaces to achieve the same thing.
2021-06-16 02:23:17 +00:00
assert_match_exact(&lockfile, &lock);
Plan for a V3 lockfile format This commit lays the groundwork for an eventual V3 of the lock file format. The changes in this format are: * A `version` indicator will be at the top of the file so we don't have to guess what format the lock is in, we know for sure. Additionally Cargo now reading a super-from-the-future lock file format will give a better error. * Git dependencies with `Branch("master")` will be encoded with `?branch=master` instead of with nothing. The motivation for this change is to eventually switch Cargo's interpretation of default git branches.
2020-07-20 17:11:25 +00:00
}
#[cargo_test]
fn lock_from_the_future() {
let p = project()
.file(
"Cargo.toml",
r#"
refactor(testsuite): Replace `[project]` with `[package]`
2022-09-22 19:50:54 +00:00
[package]
Plan for a V3 lockfile format This commit lays the groundwork for an eventual V3 of the lock file format. The changes in this format are: * A `version` indicator will be at the top of the file so we don't have to guess what format the lock is in, we know for sure. Additionally Cargo now reading a super-from-the-future lock file format will give a better error. * Git dependencies with `Branch("master")` will be encoded with `?branch=master` instead of with nothing. The motivation for this change is to eventually switch Cargo's interpretation of default git branches.
2020-07-20 17:11:25 +00:00
name = "foo"
version = "0.0.1"
authors = []
"#,
)
.file("src/lib.rs", "")
.file("Cargo.lock", "version = 10000000")
.build();
p.cargo("fetch")
.with_stderr(
"\
error: failed to parse lock file at: [..]
Caused by:
lock file version `10000000` was found, but this version of Cargo does not \
understand this lock file, perhaps Cargo needs to be updated?
",
)
.with_status(101)
.run();
}
Update lock file encodings on changes This commit alters Cargo's lockfile encoding update strategy from its previous incarnation. Previously Cargo had two versions, one for new lock files and one for old lock files. Each of these versions were different and would affect how Cargo manages lock file updates. The intention was that we'd roll out defaults to new lock files first and then later to preexisting lock files. This requires two separate changes, though, and it's not necessarily clear when to start updating old lock files. Additionally when old lock files were opted in it would break builds using `--locked` if they simply updated Cargo because Cargo would would want to bring the lock file versions forward. The purpose of this change is to solve these issues. The new strategy for updating a lock file's encoding is to simply preserve what's already existing on the filesystem until we actually decide to write out a new lock file. When Cargo updates a lock file on-disk then it will, at that time, update the lock file encoding to whatever the current default is. This means that there's only one version number to keep track of (the default for encoding). Cargo will always preserve the preexisting encoding unless another change is required to the lock file.
2020-07-28 19:17:55 +00:00
#[cargo_test]
fn preserve_old_format_if_no_update_needed() {
let cksum = Package::new("bar", "0.1.0").publish();
let lockfile = format!(
r#"# This file is automatically @generated by Cargo.
# It is not intended for manual editing.
[[package]]
name = "bar"
version = "0.1.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
[[package]]
name = "foo"
version = "0.0.1"
dependencies = [
"bar 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
]
[metadata]
"checksum bar 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)" = "{}"
"#,
cksum
);
let p = project()
.file(
"Cargo.toml",
r#"
refactor(testsuite): Replace `[project]` with `[package]`
2022-09-22 19:50:54 +00:00
[package]
Update lock file encodings on changes This commit alters Cargo's lockfile encoding update strategy from its previous incarnation. Previously Cargo had two versions, one for new lock files and one for old lock files. Each of these versions were different and would affect how Cargo manages lock file updates. The intention was that we'd roll out defaults to new lock files first and then later to preexisting lock files. This requires two separate changes, though, and it's not necessarily clear when to start updating old lock files. Additionally when old lock files were opted in it would break builds using `--locked` if they simply updated Cargo because Cargo would would want to bring the lock file versions forward. The purpose of this change is to solve these issues. The new strategy for updating a lock file's encoding is to simply preserve what's already existing on the filesystem until we actually decide to write out a new lock file. When Cargo updates a lock file on-disk then it will, at that time, update the lock file encoding to whatever the current default is. This means that there's only one version number to keep track of (the default for encoding). Cargo will always preserve the preexisting encoding unless another change is required to the lock file.
2020-07-28 19:17:55 +00:00
name = "foo"
version = "0.0.1"
authors = []
[dependencies]
bar = "0.1.0"
"#,
)
.file("src/lib.rs", "")
.file("Cargo.lock", &lockfile)
.build();
chore: update `lockfile_compat` tests to use check
2023-02-16 00:04:09 +00:00
p.cargo("check --locked").run();
Update lock file encodings on changes This commit alters Cargo's lockfile encoding update strategy from its previous incarnation. Previously Cargo had two versions, one for new lock files and one for old lock files. Each of these versions were different and would affect how Cargo manages lock file updates. The intention was that we'd roll out defaults to new lock files first and then later to preexisting lock files. This requires two separate changes, though, and it's not necessarily clear when to start updating old lock files. Additionally when old lock files were opted in it would break builds using `--locked` if they simply updated Cargo because Cargo would would want to bring the lock file versions forward. The purpose of this change is to solve these issues. The new strategy for updating a lock file's encoding is to simply preserve what's already existing on the filesystem until we actually decide to write out a new lock file. When Cargo updates a lock file on-disk then it will, at that time, update the lock file encoding to whatever the current default is. This means that there's only one version number to keep track of (the default for encoding). Cargo will always preserve the preexisting encoding unless another change is required to the lock file.
2020-07-28 19:17:55 +00:00
}
Fix disagreement about lockfile ordering on stable/nightly This commit fixes an issue where the order of packages serialized into a lock file differs on stable vs nightly. This is due to a bug introduced in #9133 where a manual `Ord` implementation was replaced with a `#[derive]`'d one. This was an unintended consequence of #9133 and means that the same lock file produced by two different versions of Cargo only differs in what order items are serialized. With #9133 being reverted soon on the current beta channel this is intended to be the nightly fix for #9334. This will hopefully mean that those projects which don't build with beta/nightly will remain unaffected, and those affected on beta/nightly will need to switch to the new nightly ordering when it's published (which matches the current stable). The reverted beta will match this ordering as well. Closes #9334
2021-04-20 20:23:06 +00:00
#[cargo_test]
fn same_name_version_different_sources() {
let cksum = Package::new("foo", "0.1.0").publish();
let (git_project, repo) = git::new_repo("dep1", |project| {
project
.file(
"Cargo.toml",
r#"
refactor(testsuite): Replace `[project]` with `[package]`
2022-09-22 19:50:54 +00:00
[package]
Fix disagreement about lockfile ordering on stable/nightly This commit fixes an issue where the order of packages serialized into a lock file differs on stable vs nightly. This is due to a bug introduced in #9133 where a manual `Ord` implementation was replaced with a `#[derive]`'d one. This was an unintended consequence of #9133 and means that the same lock file produced by two different versions of Cargo only differs in what order items are serialized. With #9133 being reverted soon on the current beta channel this is intended to be the nightly fix for #9334. This will hopefully mean that those projects which don't build with beta/nightly will remain unaffected, and those affected on beta/nightly will need to switch to the new nightly ordering when it's published (which matches the current stable). The reverted beta will match this ordering as well. Closes #9334
2021-04-20 20:23:06 +00:00
name = "foo"
version = "0.1.0"
"#,
)
.file("src/lib.rs", "")
});
let head_id = repo.head().unwrap().target().unwrap();
// Lockfile was generated with Rust 1.51
let lockfile = format!(
r#"# This file is automatically @generated by Cargo.
# It is not intended for manual editing.
version = 3
[[package]]
name = "foo"
version = "0.1.0"
dependencies = [
"foo 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
"foo 0.1.0 (git+{url})",
]
[[package]]
name = "foo"
version = "0.1.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "{cksum}"
[[package]]
name = "foo"
version = "0.1.0"
source = "git+{url}#{sha}"
"#,
sha = head_id,
url = git_project.url(),
cksum = cksum
);
let p = project()
.file(
"Cargo.toml",
&format!(
r#"
refactor(testsuite): Replace `[project]` with `[package]`
2022-09-22 19:50:54 +00:00
[package]
Fix disagreement about lockfile ordering on stable/nightly This commit fixes an issue where the order of packages serialized into a lock file differs on stable vs nightly. This is due to a bug introduced in #9133 where a manual `Ord` implementation was replaced with a `#[derive]`'d one. This was an unintended consequence of #9133 and means that the same lock file produced by two different versions of Cargo only differs in what order items are serialized. With #9133 being reverted soon on the current beta channel this is intended to be the nightly fix for #9334. This will hopefully mean that those projects which don't build with beta/nightly will remain unaffected, and those affected on beta/nightly will need to switch to the new nightly ordering when it's published (which matches the current stable). The reverted beta will match this ordering as well. Closes #9334
2021-04-20 20:23:06 +00:00
name = "foo"
version = "0.1.0"
[dependencies]
foo = "0.1.0"
foo2 = {{ git = '{}', package = 'foo' }}
"#,
git_project.url(),
),
)
.file("src/lib.rs", "")
.file("Cargo.lock", &lockfile)
.build();
chore: update `lockfile_compat` tests to use check
2023-02-16 00:04:09 +00:00
p.cargo("check").run();
Fix disagreement about lockfile ordering on stable/nightly This commit fixes an issue where the order of packages serialized into a lock file differs on stable vs nightly. This is due to a bug introduced in #9133 where a manual `Ord` implementation was replaced with a `#[derive]`'d one. This was an unintended consequence of #9133 and means that the same lock file produced by two different versions of Cargo only differs in what order items are serialized. With #9133 being reverted soon on the current beta channel this is intended to be the nightly fix for #9334. This will hopefully mean that those projects which don't build with beta/nightly will remain unaffected, and those affected on beta/nightly will need to switch to the new nightly ordering when it's published (which matches the current stable). The reverted beta will match this ordering as well. Closes #9334
2021-04-20 20:23:06 +00:00
assert_eq!(p.read_file("Cargo.lock"), lockfile);
}
add a test
2022-03-03 18:30:44 +00:00
#[cargo_test]
fn bad_data_in_lockfile_error_meg() {
Package::new("bar", "0.0.1").publish();
let p = project()
.file(
"Cargo.toml",
r#"
[package]
name = "test"
version = "0.0.0"
[dependencies]
bar = "*"
"#,
)
.file("src/main.rs", "fn main() {}")
.file(
"Cargo.lock",
r#"# This file is automatically @generated by Cargo.
# It is not intended for manual editing.
version = 3
[[package]]
name = "bar"
version = "0.1.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "8e1b9346248cf3391ead604c4407258d327c28e37209f6d56127598165165dda"
[[package]]
name = "test"
version = "0.0.0"
dependencies = [
"bar",
]"#,
)
.build();
chore: update `lockfile_compat` tests to use check
2023-02-16 00:04:09 +00:00
p.cargo("check")
add a test
2022-03-03 18:30:44 +00:00
.with_status(101)
.with_stderr(
"\
[..]
[ERROR] failed to select a version for the requirement `bar = \"*\"` (locked to 0.1.0)
candidate versions found which didn't match: 0.0.1
location searched: `dummy-registry` index (which is replacing registry `crates-io`)
required by package `test v0.0.0 ([..])`
perhaps a crate was updated and forgotten to be re-vendored?
",
)
.run();
}
feat: prepare for the next lockfile bump The `-Znext-lockfile-bump` is added, so we can prepare for all lockfile format changes and then stabilize then all at once. `-Znext-lockfile-bump` is not intended for using outside our test suite and development. Hence it's hidden.
2023-06-17 00:57:30 +00:00
#[cargo_test]
feat(lockfile): stabilize v4 and prepare for v5
2023-10-19 18:47:04 +00:00
fn next_version_is_always_unstable() {
feat: prepare for the next lockfile bump The `-Znext-lockfile-bump` is added, so we can prepare for all lockfile format changes and then stabilize then all at once. `-Znext-lockfile-bump` is not intended for using outside our test suite and development. Hence it's hidden.
2023-06-17 00:57:30 +00:00
let p = project()
.file(
"Cargo.toml",
&format!(
r#"
[package]
name = "foo"
version = "0.0.1"
"#,
),
)
.file("src/lib.rs", "")
feat(lockfile): stabilize v4 and prepare for v5
2023-10-19 18:47:04 +00:00
.file("Cargo.lock", "version = 5")
feat: prepare for the next lockfile bump The `-Znext-lockfile-bump` is added, so we can prepare for all lockfile format changes and then stabilize then all at once. `-Znext-lockfile-bump` is not intended for using outside our test suite and development. Hence it's hidden.
2023-06-17 00:57:30 +00:00
.build();
p.cargo("fetch")
.with_status(101)
.with_stderr(
"\
error: failed to parse lock file at: [CWD]/Cargo.lock
-Znext-lockfile-bump: Don't suggest using -Z on stable
2023-06-22 18:55:42 +00:00
Caused by:
feat(lockfile): stabilize v4 and prepare for v5
2023-10-19 18:47:04 +00:00
lock file version `5` was found, but this version of Cargo does not \
-Znext-lockfile-bump: Don't suggest using -Z on stable
2023-06-22 18:55:42 +00:00
understand this lock file, perhaps Cargo needs to be updated?
",
)
.run();
// On nightly, let the user know about the `-Z` flag.
p.cargo("fetch")
.masquerade_as_nightly_cargo(&["-Znext-lockfile-bump"])
.with_status(101)
.with_stderr(
"\
error: failed to parse lock file at: [CWD]/Cargo.lock
feat: prepare for the next lockfile bump The `-Znext-lockfile-bump` is added, so we can prepare for all lockfile format changes and then stabilize then all at once. `-Znext-lockfile-bump` is not intended for using outside our test suite and development. Hence it's hidden.
2023-06-17 00:57:30 +00:00
Caused by:
feat(lockfile): stabilize v4 and prepare for v5
2023-10-19 18:47:04 +00:00
lock file version `5` requires `-Znext-lockfile-bump`
feat: prepare for the next lockfile bump The `-Znext-lockfile-bump` is added, so we can prepare for all lockfile format changes and then stabilize then all at once. `-Znext-lockfile-bump` is not intended for using outside our test suite and development. Hence it's hidden.
2023-06-17 00:57:30 +00:00
",
)
.run();
}
#[cargo_test]
fn v4_cannot_be_created_from_scratch() {
let p = project()
.file(
"Cargo.toml",
&format!(
r#"
[package]
name = "foo"
version = "0.0.1"
"#,
),
)
.file("src/lib.rs", "")
.build();
feat(lockfile): stabilize v4 and prepare for v5
2023-10-19 18:47:04 +00:00
p.cargo("fetch").run();
feat: prepare for the next lockfile bump The `-Znext-lockfile-bump` is added, so we can prepare for all lockfile format changes and then stabilize then all at once. `-Znext-lockfile-bump` is not intended for using outside our test suite and development. Hence it's hidden.
2023-06-17 00:57:30 +00:00
let lockfile = r#"# This file is automatically @generated by Cargo.
# It is not intended for manual editing.
version = 3
[[package]]
name = "foo"
version = "0.0.1"
"#;
let lock = p.read_lockfile();
assert_match_exact(lockfile, &lock);
}
test: v3 lockfile format doesn't respect url encode These tests verify the existing buggy behavior.
2023-06-17 08:16:26 +00:00
fn create_branch(repo: &git2::Repository, branch: &str, head_id: git2::Oid) {
repo.branch(branch, &repo.find_commit(head_id).unwrap(), true)
.unwrap();
}
fn create_tag(repo: &git2::Repository, tag: &str, head_id: git2::Oid) {
repo.tag(
tag,
&repo.find_object(head_id, None).unwrap(),
&repo.signature().unwrap(),
"make a new tag",
false,
)
.unwrap();
}
fn v3_and_git_url_encoded(ref_kind: &str, f: impl FnOnce(&git2::Repository, &str, git2::Oid)) {
let (git_project, repo) = git::new_repo("dep1", |project| {
project
.file("Cargo.toml", &basic_lib_manifest("dep1"))
.file("src/lib.rs", "")
});
let url = git_project.url();
let head_id = repo.head().unwrap().target().unwrap();
// Ref name with special characters
let git_ref = "a-_+#$)";
f(&repo, git_ref, head_id);
let lockfile = format!(
r#"# This file is automatically @generated by Cargo.
# It is not intended for manual editing.
version = 3
[[package]]
name = "dep1"
version = "0.5.0"
source = "git+{url}?{ref_kind}={git_ref}#{head_id}"
[[package]]
name = "foo"
version = "0.0.1"
dependencies = [
"dep1",
]
"#,
);
let p = project()
.file(
"Cargo.toml",
&format!(
r#"
[package]
name = "foo"
version = "0.0.1"
[dependencies]
dep1 = {{ git = '{url}', {ref_kind} = '{git_ref}' }}
"#,
),
)
.file("src/lib.rs", "")
.file("Cargo.lock", "version = 3")
.build();
p.cargo("check")
.with_stderr(format!(
"\
[UPDATING] git repository `{url}`
[CHECKING] dep1 v0.5.0 ({url}?{ref_kind}={git_ref}#[..])
[CHECKING] foo v0.0.1 ([CWD])
[FINISHED] dev [..]
"
))
.run();
let lock = p.read_lockfile();
assert_match_exact(&lockfile, &lock);
// v3 doesn't URL-encode URL parameters, but `url` crate does decode as it
// was URL-encoded. Therefore Cargo thinks they are from different source
// and clones the repository again.
p.cargo("check")
.with_stderr(format!(
"\
[UPDATING] git repository `{url}`
[FINISHED] dev [..]
"
))
.run();
}
#[cargo_test]
fn v3_and_git_url_encoded_branch() {
v3_and_git_url_encoded("branch", create_branch);
}
#[cargo_test]
fn v3_and_git_url_encoded_tag() {
v3_and_git_url_encoded("tag", create_tag);
}
#[cargo_test]
fn v3_and_git_url_encoded_rev() {
v3_and_git_url_encoded("rev", create_tag);
}
test: encode URL params correctly for SourceId in Cargo.lock This will happen in lockfile format v4.
2023-06-17 08:34:51 +00:00
fn v4_and_git_url_encoded(ref_kind: &str, f: impl FnOnce(&git2::Repository, &str, git2::Oid)) {
let (git_project, repo) = git::new_repo("dep1", |project| {
project
.file("Cargo.toml", &basic_lib_manifest("dep1"))
.file("src/lib.rs", "")
});
let url = git_project.url();
let head_id = repo.head().unwrap().target().unwrap();
// Ref name with special characters
let git_ref = "a-_+#$)";
let encoded_ref = "a-_%2B%23%24%29";
f(&repo, git_ref, head_id);
let lockfile = format!(
r#"# This file is automatically @generated by Cargo.
# It is not intended for manual editing.
version = 4
[[package]]
name = "dep1"
version = "0.5.0"
source = "git+{url}?{ref_kind}={encoded_ref}#{head_id}"
[[package]]
name = "foo"
version = "0.0.1"
dependencies = [
"dep1",
]
"#,
);
let p = project()
.file(
"Cargo.toml",
&format!(
r#"
[package]
name = "foo"
version = "0.0.1"
[dependencies]
dep1 = {{ git = '{url}', {ref_kind} = '{git_ref}' }}
"#,
),
)
.file("src/lib.rs", "")
.file("Cargo.lock", "version = 4")
.build();
feat(lockfile): stabilize v4 and prepare for v5
2023-10-19 18:47:04 +00:00
p.cargo("check")
test: encode URL params correctly for SourceId in Cargo.lock This will happen in lockfile format v4.
2023-06-17 08:34:51 +00:00
.with_stderr(format!(
"\
[UPDATING] git repository `{url}`
[CHECKING] dep1 v0.5.0 ({url}?{ref_kind}={git_ref}#[..])
[CHECKING] foo v0.0.1 ([CWD])
[FINISHED] dev [..]
"
))
.run();
let lock = p.read_lockfile();
assert_match_exact(&lockfile, &lock);
// Unlike v3_and_git_url_encoded, v4 encodes URL parameters so no git
// repository re-clone happen.
feat(lockfile): stabilize v4 and prepare for v5
2023-10-19 18:47:04 +00:00
p.cargo("check").with_stderr("[FINISHED] dev [..]").run();
test: encode URL params correctly for SourceId in Cargo.lock This will happen in lockfile format v4.
2023-06-17 08:34:51 +00:00
}
#[cargo_test]
fn v4_and_git_url_encoded_branch() {
v4_and_git_url_encoded("branch", create_branch);
}
#[cargo_test]
fn v4_and_git_url_encoded_tag() {
v4_and_git_url_encoded("tag", create_tag);
}
#[cargo_test]
fn v4_and_git_url_encoded_rev() {
v4_and_git_url_encoded("rev", create_tag)
}
Reference in a new issue Copy permalink