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

500 lines
11 KiB
Rust
Raw Normal View History

Upgrade to Rust 2018
2018-12-06 19:17:36 +00:00
use crate::support::git;
use crate::support::registry::Package;
use crate::support::{basic_manifest, lines_match, 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
#[test]
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
cargo fmt
2018-03-14 15:17:44 +00:00
let expected_lockfile = r#"[[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"
[[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 = [
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)",
Removed extraneous logic that generates [root] in cargo.lock
2017-10-03 12:18:08 +00:00
]
[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)" = "[..]"
Removed extraneous logic that generates [root] in cargo.lock
2017-10-03 12:18:08 +00:00
"#;
cargo fmt
2018-03-14 15:17:44 +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#"
Simplify lockfile tests
2016-08-25 08:34:25 +00:00
[project]
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"
Simplify lockfile tests
2016-08-25 08:34:25 +00:00
version = "0.0.1"
authors = []
[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"
cargo fmt
2018-03-14 15:17:44 +00:00
"#,
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();
for (l, r) in expected_lockfile.lines().zip(lock.lines()) {
assert!(lines_match(l, r), "Lines differ:\n{}\n\n{}", l, r);
Updated test to ensure cargo update transforms Cargo.lock
2017-10-03 14:05:57 +00:00
}
Updated old lockfile tests
2017-10-03 14:57:49 +00:00
assert_eq!(lock.lines().count(), expected_lockfile.lines().count());
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
}
Don't update lockfiles from previous Cargo versions if `--locked` is passed
2017-10-30 19:56:46 +00:00
#[test]
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#"
Don't update lockfiles from previous Cargo versions if `--locked` is passed
2017-10-30 19:56:46 +00:00
[project]
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"
authors = []
[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"
cargo fmt
2018-03-14 15:17:44 +00:00
"#,
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();
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
p.cargo("build --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();
for (l, r) in old_lockfile.lines().zip(lock.lines()) {
assert!(lines_match(l, r), "Lines differ:\n{}\n\n{}", l, r);
}
assert_eq!(lock.lines().count(), old_lockfile.lines().count());
}
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
#[test]
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#"
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
[project]
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"
authors = []
[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"
cargo fmt
2018-03-14 15:17:44 +00:00
"#,
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
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
p.cargo("build").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();
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
assert!(lock.starts_with(
r#"
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"
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 = [
"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
[metadata]
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
"#
.trim()
));
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
}
#[test]
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#"
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
[project]
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"
authors = []
[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"
cargo fmt
2018-03-14 15:17:44 +00:00
"#,
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
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
p.cargo("build")
.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
* a replacement source in use (e.g. a mirror) returned a different checksum
* 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
}
// If the checksum is unlisted in the lockfile (e.g. <none>) yet we can
// calculate it (e.g. it's a registry dep), then we should in theory just fill
// it in.
#[test]
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#"
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
[project]
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"
authors = []
[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"
cargo fmt
2018-03-14 15:17:44 +00:00
"#,
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
}
// If the checksum is listed in the lockfile yet we cannot calculate it (e.g.
// git dependencies as of today), then make sure we choke.
#[test]
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", "")
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
})
.unwrap();
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#"
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
[project]
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"
authors = []
[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 = {{ 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
Regression test for lockfile format
2016-08-22 23:59:31 +00:00
#[test]
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#"
Regression test for lockfile format
2016-08-22 23:59:31 +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"
Regression test for lockfile format
2016-08-22 23:59:31 +00:00
version = "0.0.1"
authors = []
[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"
cargo fmt
2018-03-14 15:17:44 +00:00
"#,
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
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
p.cargo("build").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 = "\
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\"
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 = [
\"bar 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)\",
]
Regression test for lockfile format
2016-08-22 23:59:31 +00:00
[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)\" = \"[..]\"";
Regression test for lockfile format
2016-08-22 23:59:31 +00:00
for (l, r) in expected.lines().zip(actual.lines()) {
assert!(lines_match(l, r), "Lines differ:\n{}\n\n{}", l, r);
}
assert_eq!(actual.lines().count(), expected.lines().count());
}
Forward compatibility with rootless lockfiles
2016-08-20 21:27:06 +00:00
#[test]
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
let lockfile = r#"[[package]]
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 = [
"bar 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
]
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#"
Simplify lockfile tests
2016-08-25 08:34:25 +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"
Simplify lockfile tests
2016-08-25 08:34:25 +00:00
version = "0.0.1"
authors = []
[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"
cargo fmt
2018-03-14 15:17:44 +00:00
"#,
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
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
p.cargo("build").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();
Forward compatibility with rootless lockfiles
2016-08-20 21:27:06 +00:00
assert!(lock.starts_with(lockfile.trim()));
}
fix error message when --locked is passed but lockfile is outdated
2017-09-04 11:33:03 +00:00
#[test]
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#"
fix error message when --locked is passed but lockfile is outdated
2017-09-04 11:33:03 +00:00
[project]
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"
fix error message when --locked is passed but lockfile is outdated
2017-09-04 11:33:03 +00:00
version = "0.0.1"
authors = []
[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"
cargo fmt
2018-03-14 15:17:44 +00:00
"#,
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
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
p.cargo("build --locked")
.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
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
}
Reference in a new issue Copy permalink