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/replace.rs

1455 lines
35 KiB
Rust
Raw Normal View History

Minor testsuite organization.
2019-11-25 02:42:45 +00:00
//! Tests for `[replace]` table source replacement.
Extract `support` directory to its own crate Extract out all our test support code to its own standalone crate so it can be shared between multiple test suites if necessary.
2019-09-12 17:14:29 +00:00
use cargo_test_support::git;
use cargo_test_support::paths;
use cargo_test_support::registry::Package;
use cargo_test_support::{basic_manifest, project};
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
Remove the test! macro This isn't really necessary and we can do setup manually in a few cases and lazily do it in all the others.
2016-05-25 20:55:42 +00:00
fn override_simple() {
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();
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +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 bar = git::repo(&paths::root().join("override"))
Dedup a bunch more manifest
2018-07-24 22:35:01 +00:00
.file("Cargo.toml", &basic_manifest("bar", "0.1.0"))
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
.file("src/lib.rs", "pub fn bar() {}")
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
.build();
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +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#"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[package]
name = "foo"
version = "0.0.1"
authors = []
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[dependencies]
bar = "0.1.0"
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[replace]
"bar:0.1.0" = {{ git = '{}' }}
"#,
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.url()
cargo fmt
2018-03-14 15:17:44 +00:00
),
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.file(
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
"src/lib.rs",
"extern crate bar; pub fn foo() { bar::bar(); }",
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.build();
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
chore: update `replace` tests to use check
2023-02-16 02:54:00 +00:00
p.cargo("check")
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
.with_stderr(
cargo fmt
2018-03-14 15:17:44 +00:00
"\
Update tests to use registry names
2021-06-27 19:18:36 +00:00
[UPDATING] `dummy-registry` index
simplify tests remove RUNNING, COMPILING, ERROR, DOCUMENTING, FRESH and UPDATING constants
2016-05-11 16:55:43 +00:00
[UPDATING] git repository `[..]`
chore: update `replace` tests to use check
2023-02-16 02:54:00 +00:00
[CHECKING] bar v0.1.0 (file://[..])
[CHECKING] foo v0.0.1 ([CWD])
Rename debug target to dev in build output This renames the debug target to dev in the build output for non-release builds. This includes the output of commands such as `cargo build`, `cargo test`, and `cargo doc`. Closes #3519
2017-01-12 01:03:36 +00:00
[FINISHED] dev [unoptimized + debuginfo] target(s) in [..]
cargo fmt
2018-03-14 15:17:44 +00:00
",
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.run();
Remove the test! macro This isn't really necessary and we can do setup manually in a few cases and lazily do it in all the others.
2016-05-25 20:55:42 +00:00
}
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
Reject when using features in replace Signed-off-by: hi-rustin <rustin.liu@gmail.com>
2021-07-12 06:56:24 +00:00
fn override_with_features() {
Package::new("bar", "0.1.0").publish();
let bar = git::repo(&paths::root().join("override"))
.file("Cargo.toml", &basic_manifest("bar", "0.1.0"))
.file("src/lib.rs", "pub fn bar() {}")
.build();
let p = project()
.file(
"Cargo.toml",
&format!(
r#"
[package]
name = "foo"
version = "0.0.1"
authors = []
[dependencies]
bar = "0.1.0"
[replace]
"bar:0.1.0" = {{ git = '{}', features = ["some_feature"] }}
"#,
bar.url()
),
)
.file(
"src/lib.rs",
"extern crate bar; pub fn foo() { bar::bar(); }",
)
.build();
chore: update `replace` tests to use check
2023-02-16 02:54:00 +00:00
p.cargo("check")
Reject when using features in replace Signed-off-by: hi-rustin <rustin.liu@gmail.com>
2021-07-12 06:56:24 +00:00
.with_stderr(
"\
[UPDATING] [..] index
Warning when using features in replace Signed-off-by: hi-rustin <rustin.liu@gmail.com>
2021-07-23 07:00:50 +00:00
[UPDATING] git repository `[..]`
[WARNING] replacement for `bar` uses the features mechanism. default-features and features \
will not take effect because the replacement dependency does not support this mechanism
chore: update `replace` tests to use check
2023-02-16 02:54:00 +00:00
[CHECKING] bar v0.1.0 (file://[..])
[CHECKING] foo v0.0.1 ([CWD])
Warning when using features in replace Signed-off-by: hi-rustin <rustin.liu@gmail.com>
2021-07-23 07:00:50 +00:00
[FINISHED] dev [unoptimized + debuginfo] target(s) in [..]
",
)
.run();
}
#[cargo_test]
fn override_with_setting_default_features() {
Package::new("bar", "0.1.0").publish();
let bar = git::repo(&paths::root().join("override"))
.file("Cargo.toml", &basic_manifest("bar", "0.1.0"))
.file("src/lib.rs", "pub fn bar() {}")
.build();
let p = project()
.file(
"Cargo.toml",
&format!(
r#"
[package]
name = "foo"
version = "0.0.1"
authors = []
[dependencies]
bar = "0.1.0"
[replace]
"bar:0.1.0" = {{ git = '{}', default-features = false, features = ["none_default_feature"] }}
"#,
bar.url()
),
)
.file(
"src/lib.rs",
"extern crate bar; pub fn foo() { bar::bar(); }",
)
.build();
Reject when using features in replace Signed-off-by: hi-rustin <rustin.liu@gmail.com>
2021-07-12 06:56:24 +00:00
chore: update `replace` tests to use check
2023-02-16 02:54:00 +00:00
p.cargo("check")
Warning when using features in replace Signed-off-by: hi-rustin <rustin.liu@gmail.com>
2021-07-23 07:00:50 +00:00
.with_stderr(
"\
[UPDATING] [..] index
[UPDATING] git repository `[..]`
[WARNING] replacement for `bar` uses the features mechanism. default-features and features \
will not take effect because the replacement dependency does not support this mechanism
chore: update `replace` tests to use check
2023-02-16 02:54:00 +00:00
[CHECKING] bar v0.1.0 (file://[..])
[CHECKING] foo v0.0.1 ([CWD])
Warning when using features in replace Signed-off-by: hi-rustin <rustin.liu@gmail.com>
2021-07-23 07:00:50 +00:00
[FINISHED] dev [unoptimized + debuginfo] target(s) in [..]
cargo fmt
2018-03-14 15:17:44 +00:00
",
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.run();
Remove the test! macro This isn't really necessary and we can do setup manually in a few cases and lazily do it in all the others.
2016-05-25 20:55:42 +00:00
}
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
Remove the test! macro This isn't really necessary and we can do setup manually in a few cases and lazily do it in all the others.
2016-05-25 20:55:42 +00:00
fn missing_version() {
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
let p = project()
cargo fmt
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[package]
name = "foo"
version = "0.0.1"
authors = []
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[dependencies]
bar = "0.1.0"
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[replace]
bar = { git = 'https://example.com' }
"#,
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
.build();
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
chore: update `replace` tests to use check
2023-02-16 02:54:00 +00:00
p.cargo("check")
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
.with_status(101)
.with_stderr(
cargo fmt
2018-03-14 15:17:44 +00:00
"\
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
error: failed to parse manifest at `[..]`
Caused by:
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
replacements must specify a version to replace, but `[..]bar` does not
cargo fmt
2018-03-14 15:17:44 +00:00
",
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.run();
Remove the test! macro This isn't really necessary and we can do setup manually in a few cases and lazily do it in all the others.
2016-05-25 20:55:42 +00:00
}
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
Show an error messager for invalid semver spec for packages in the [replace] section. The [replace] section in the Cargo.toml file doesn't allow invalid semver specs for packages, so something like this: [dependencies] foo = "*" [replace] "foo:*" = { git = 'https://example.com' } It's not valid. In this case we will display an error message like this: error: failed to parse manifest at `Cargo.toml` Caused by: replacements must specify a valid semver version to replace, but `foo:*` does not
2016-09-30 11:27:10 +00:00
fn invalid_semver_version() {
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
let p = project()
cargo fmt
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[package]
name = "foo"
version = "0.0.1"
authors = []
Show an error messager for invalid semver spec for packages in the [replace] section. The [replace] section in the Cargo.toml file doesn't allow invalid semver specs for packages, so something like this: [dependencies] foo = "*" [replace] "foo:*" = { git = 'https://example.com' } It's not valid. In this case we will display an error message like this: error: failed to parse manifest at `Cargo.toml` Caused by: replacements must specify a valid semver version to replace, but `foo:*` does not
2016-09-30 11:27:10 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[dependencies]
bar = "*"
Show an error messager for invalid semver spec for packages in the [replace] section. The [replace] section in the Cargo.toml file doesn't allow invalid semver specs for packages, so something like this: [dependencies] foo = "*" [replace] "foo:*" = { git = 'https://example.com' } It's not valid. In this case we will display an error message like this: error: failed to parse manifest at `Cargo.toml` Caused by: replacements must specify a valid semver version to replace, but `foo:*` does not
2016-09-30 11:27:10 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[replace]
"bar:*" = { git = 'https://example.com' }
"#,
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
.build();
Show an error messager for invalid semver spec for packages in the [replace] section. The [replace] section in the Cargo.toml file doesn't allow invalid semver specs for packages, so something like this: [dependencies] foo = "*" [replace] "foo:*" = { git = 'https://example.com' } It's not valid. In this case we will display an error message like this: error: failed to parse manifest at `Cargo.toml` Caused by: replacements must specify a valid semver version to replace, but `foo:*` does not
2016-09-30 11:27:10 +00:00
chore: update `replace` tests to use check
2023-02-16 02:54:00 +00:00
p.cargo("check")
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
.with_status(101)
.with_stderr_contains(
cargo fmt
2018-03-14 15:17:44 +00:00
"\
Show an error messager for invalid semver spec for packages in the [replace] section. The [replace] section in the Cargo.toml file doesn't allow invalid semver specs for packages, so something like this: [dependencies] foo = "*" [replace] "foo:*" = { git = 'https://example.com' } It's not valid. In this case we will display an error message like this: error: failed to parse manifest at `Cargo.toml` Caused by: replacements must specify a valid semver version to replace, but `foo:*` does not
2016-09-30 11:27:10 +00:00
error: failed to parse manifest at `[..]`
Caused by:
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
replacements must specify a valid semver version to replace, but `bar:*` does not
cargo fmt
2018-03-14 15:17:44 +00:00
",
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.run();
Show an error messager for invalid semver spec for packages in the [replace] section. The [replace] section in the Cargo.toml file doesn't allow invalid semver specs for packages, so something like this: [dependencies] foo = "*" [replace] "foo:*" = { git = 'https://example.com' } It's not valid. In this case we will display an error message like this: error: failed to parse manifest at `Cargo.toml` Caused by: replacements must specify a valid semver version to replace, but `foo:*` does not
2016-09-30 11:27:10 +00:00
}
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
Remove the test! macro This isn't really necessary and we can do setup manually in a few cases and lazily do it in all the others.
2016-05-25 20:55:42 +00:00
fn different_version() {
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.2.0").publish();
Package::new("bar", "0.1.0").publish();
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
let p = project()
cargo fmt
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[package]
name = "foo"
version = "0.0.1"
authors = []
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[dependencies]
bar = "0.1.0"
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[replace]
"bar:0.1.0" = "0.2.0"
"#,
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.file("src/lib.rs", "")
cargotest/support: remove internal mutability in favor of switching types Remove is_build: Cell<bool> from ProjectBuilder and introduce a new type Project. is_build==false <-> ProjectBuilder is_build==true <-> Project Also add #[must_use] to ProjectBuilder to confirm its instances are surely consumed by its build() method to produce Project. The same goes for RepoBuilder. ProjectBuilder::cargo_process() was removed as its design heavily depended on the internal mutability. Signed-off-by: NODA, Kai <nodakai@gmail.com>
2017-07-22 03:12:21 +00:00
.build();
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
chore: update `replace` tests to use check
2023-02-16 02:54:00 +00:00
p.cargo("check")
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
.with_status(101)
.with_stderr(
cargo fmt
2018-03-14 15:17:44 +00:00
"\
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
error: failed to parse manifest at `[..]`
Caused by:
replacements cannot specify a version requirement, but found one for [..]
cargo fmt
2018-03-14 15:17:44 +00:00
",
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.run();
Remove the test! macro This isn't really necessary and we can do setup manually in a few cases and lazily do it in all the others.
2016-05-25 20:55:42 +00:00
}
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
Remove the test! macro This isn't really necessary and we can do setup manually in a few cases and lazily do it in all the others.
2016-05-25 20:55:42 +00:00
fn transitive() {
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();
Package::new("baz", "0.2.0")
.dep("bar", "0.1.0")
.file("src/lib.rs", "extern crate bar; fn baz() { bar::bar(); }")
cargo fmt
2018-03-14 15:17:44 +00:00
.publish();
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
let foo = git::repo(&paths::root().join("override"))
Dedup a bunch more manifest
2018-07-24 22:35:01 +00:00
.file("Cargo.toml", &basic_manifest("bar", "0.1.0"))
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
.file("src/lib.rs", "pub fn bar() {}")
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
.build();
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +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#"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[package]
name = "foo"
version = "0.0.1"
authors = []
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[dependencies]
baz = "0.2.0"
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[replace]
"bar:0.1.0" = {{ git = '{}' }}
"#,
cargo fmt
2018-03-14 15:17:44 +00:00
foo.url()
),
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
.build();
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
chore: update `replace` tests to use check
2023-02-16 02:54:00 +00:00
p.cargo("check")
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
.with_stderr(
cargo fmt
2018-03-14 15:17:44 +00:00
"\
Update tests to use registry names
2021-06-27 19:18:36 +00:00
[UPDATING] `dummy-registry` index
simplify tests remove RUNNING, COMPILING, ERROR, DOCUMENTING, FRESH and UPDATING constants
2016-05-11 16:55:43 +00:00
[UPDATING] git repository `[..]`
Review comments!
2018-09-14 20:33:18 +00:00
[DOWNLOADING] crates ...
[DOWNLOADED] baz v0.2.0 (registry [..])
chore: update `replace` tests to use check
2023-02-16 02:54:00 +00:00
[CHECKING] bar v0.1.0 (file://[..])
[CHECKING] baz v0.2.0
[CHECKING] foo v0.0.1 ([CWD])
Rename debug target to dev in build output This renames the debug target to dev in the build output for non-release builds. This includes the output of commands such as `cargo build`, `cargo test`, and `cargo doc`. Closes #3519
2017-01-12 01:03:36 +00:00
[FINISHED] dev [unoptimized + debuginfo] target(s) in [..]
cargo fmt
2018-03-14 15:17:44 +00:00
",
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.run();
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
Fix some test output validation.
2023-11-15 22:33:27 +00:00
p.cargo("check").with_stderr("[FINISHED] [..]").run();
Remove the test! macro This isn't really necessary and we can do setup manually in a few cases and lazily do it in all the others.
2016-05-25 20:55:42 +00:00
}
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
Remove the test! macro This isn't really necessary and we can do setup manually in a few cases and lazily do it in all the others.
2016-05-25 20:55:42 +00:00
fn persists_across_rebuilds() {
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();
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
let foo = git::repo(&paths::root().join("override"))
Dedup a bunch more manifest
2018-07-24 22:35:01 +00:00
.file("Cargo.toml", &basic_manifest("bar", "0.1.0"))
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
.file("src/lib.rs", "pub fn bar() {}")
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
.build();
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +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#"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[package]
name = "foo"
version = "0.0.1"
authors = []
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[dependencies]
bar = "0.1.0"
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[replace]
"bar:0.1.0" = {{ git = '{}' }}
"#,
cargo fmt
2018-03-14 15:17:44 +00:00
foo.url()
),
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.file(
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
"src/lib.rs",
"extern crate bar; pub fn foo() { bar::bar(); }",
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.build();
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
chore: update `replace` tests to use check
2023-02-16 02:54:00 +00:00
p.cargo("check")
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
.with_stderr(
cargo fmt
2018-03-14 15:17:44 +00:00
"\
Update tests to use registry names
2021-06-27 19:18:36 +00:00
[UPDATING] `dummy-registry` index
Resolve conflicts from upstream.
2018-09-09 23:59:48 +00:00
[UPDATING] git repository `file://[..]`
chore: update `replace` tests to use check
2023-02-16 02:54:00 +00:00
[CHECKING] bar v0.1.0 (file://[..])
[CHECKING] foo v0.0.1 ([CWD])
Rename debug target to dev in build output This renames the debug target to dev in the build output for non-release builds. This includes the output of commands such as `cargo build`, `cargo test`, and `cargo doc`. Closes #3519
2017-01-12 01:03:36 +00:00
[FINISHED] dev [unoptimized + debuginfo] target(s) in [..]
cargo fmt
2018-03-14 15:17:44 +00:00
",
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.run();
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
Fix some test output validation.
2023-11-15 22:33:27 +00:00
p.cargo("check").with_stderr("[FINISHED] [..]").run();
Remove the test! macro This isn't really necessary and we can do setup manually in a few cases and lazily do it in all the others.
2016-05-25 20:55:42 +00:00
}
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
Remove the test! macro This isn't really necessary and we can do setup manually in a few cases and lazily do it in all the others.
2016-05-25 20:55:42 +00:00
fn replace_registry_with_path() {
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();
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
let _ = project()
.at("bar")
Dedup a bunch more manifest
2018-07-24 22:35:01 +00:00
.file("Cargo.toml", &basic_manifest("bar", "0.1.0"))
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
.file("src/lib.rs", "pub fn bar() {}")
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
.build();
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
let p = project()
cargo fmt
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[package]
name = "foo"
version = "0.0.1"
authors = []
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[dependencies]
bar = "0.1.0"
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[replace]
"bar:0.1.0" = { path = "../bar" }
"#,
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.file(
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
"src/lib.rs",
"extern crate bar; pub fn foo() { bar::bar(); }",
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.build();
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
chore: update `replace` tests to use check
2023-02-16 02:54:00 +00:00
p.cargo("check")
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
.with_stderr(
cargo fmt
2018-03-14 15:17:44 +00:00
"\
Update tests to use registry names
2021-06-27 19:18:36 +00:00
[UPDATING] `dummy-registry` index
chore: update `replace` tests to use check
2023-02-16 02:54:00 +00:00
[CHECKING] bar v0.1.0 ([ROOT][..]/bar)
[CHECKING] foo v0.0.1 ([CWD])
Rename debug target to dev in build output This renames the debug target to dev in the build output for non-release builds. This includes the output of commands such as `cargo build`, `cargo test`, and `cargo doc`. Closes #3519
2017-01-12 01:03:36 +00:00
[FINISHED] dev [unoptimized + debuginfo] target(s) in [..]
cargo fmt
2018-03-14 15:17:44 +00:00
",
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.run();
Remove the test! macro This isn't really necessary and we can do setup manually in a few cases and lazily do it in all the others.
2016-05-25 20:55:42 +00:00
}
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
Remove the test! macro This isn't really necessary and we can do setup manually in a few cases and lazily do it in all the others.
2016-05-25 20:55:42 +00:00
fn use_a_spec_to_select() {
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("baz", "0.1.1")
.file("src/lib.rs", "pub fn baz1() {}")
cargo fmt
2018-03-14 15:17:44 +00:00
.publish();
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("baz", "0.2.0").publish();
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
Package::new("bar", "0.1.1")
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
.dep("baz", "0.2")
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
.file(
"src/lib.rs",
"extern crate baz; pub fn bar() { baz::baz3(); }",
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.publish();
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
let foo = git::repo(&paths::root().join("override"))
Dedup a bunch more manifest
2018-07-24 22:35:01 +00:00
.file("Cargo.toml", &basic_manifest("baz", "0.2.0"))
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
.file("src/lib.rs", "pub fn baz3() {}")
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
.build();
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +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#"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[package]
name = "foo"
version = "0.0.1"
authors = []
[dependencies]
bar = "0.1"
baz = "0.1"
[replace]
"baz:0.2.0" = {{ git = '{}' }}
"#,
cargo fmt
2018-03-14 15:17:44 +00:00
foo.url()
),
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.file(
cargo fmt
2018-03-14 15:17:44 +00:00
"src/lib.rs",
"
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
extern crate 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
extern crate baz;
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
fix test_cargo_overrides
2016-05-20 11:47:39 +00:00
pub fn local() {
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
baz::baz1();
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
bar::bar();
}
cargo fmt
2018-03-14 15:17:44 +00:00
",
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.build();
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
chore: update `replace` tests to use check
2023-02-16 02:54:00 +00:00
p.cargo("check")
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
.with_stderr(
cargo fmt
2018-03-14 15:17:44 +00:00
"\
Update tests to use registry names
2021-06-27 19:18:36 +00:00
[UPDATING] `dummy-registry` index
simplify tests remove RUNNING, COMPILING, ERROR, DOCUMENTING, FRESH and UPDATING constants
2016-05-11 16:55:43 +00:00
[UPDATING] git repository `[..]`
Review comments!
2018-09-14 20:33:18 +00:00
[DOWNLOADING] crates ...
[DOWNLOADED] [..]
[DOWNLOADED] [..]
chore: update `replace` tests to use check
2023-02-16 02:54:00 +00:00
[CHECKING] [..]
[CHECKING] [..]
[CHECKING] [..]
[CHECKING] foo v0.0.1 ([CWD])
Rename debug target to dev in build output This renames the debug target to dev in the build output for non-release builds. This includes the output of commands such as `cargo build`, `cargo test`, and `cargo doc`. Closes #3519
2017-01-12 01:03:36 +00:00
[FINISHED] dev [unoptimized + debuginfo] target(s) in [..]
cargo fmt
2018-03-14 15:17:44 +00:00
",
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.run();
Remove the test! macro This isn't really necessary and we can do setup manually in a few cases and lazily do it in all the others.
2016-05-25 20:55:42 +00:00
}
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
Remove the test! macro This isn't really necessary and we can do setup manually in a few cases and lazily do it in all the others.
2016-05-25 20:55:42 +00:00
fn override_adds_some_deps() {
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("baz", "0.1.1").publish();
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
Package::new("bar", "0.1.0").publish();
let foo = git::repo(&paths::root().join("override"))
cargo fmt
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[package]
name = "bar"
version = "0.1.0"
authors = []
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[dependencies]
baz = "0.1"
"#,
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
.build();
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +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#"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[package]
name = "foo"
version = "0.0.1"
authors = []
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[dependencies]
bar = "0.1"
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[replace]
"bar:0.1.0" = {{ git = '{}' }}
"#,
cargo fmt
2018-03-14 15:17:44 +00:00
foo.url()
),
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
.build();
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
chore: update `replace` tests to use check
2023-02-16 02:54:00 +00:00
p.cargo("check")
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
.with_stderr(
cargo fmt
2018-03-14 15:17:44 +00:00
"\
Update tests to use registry names
2021-06-27 19:18:36 +00:00
[UPDATING] `dummy-registry` index
simplify tests remove RUNNING, COMPILING, ERROR, DOCUMENTING, FRESH and UPDATING constants
2016-05-11 16:55:43 +00:00
[UPDATING] git repository `[..]`
Review comments!
2018-09-14 20:33:18 +00:00
[DOWNLOADING] crates ...
[DOWNLOADED] baz v0.1.1 (registry [..])
chore: update `replace` tests to use check
2023-02-16 02:54:00 +00:00
[CHECKING] baz v0.1.1
[CHECKING] bar v0.1.0 ([..])
[CHECKING] foo v0.0.1 ([CWD])
Rename debug target to dev in build output This renames the debug target to dev in the build output for non-release builds. This includes the output of commands such as `cargo build`, `cargo test`, and `cargo doc`. Closes #3519
2017-01-12 01:03:36 +00:00
[FINISHED] dev [unoptimized + debuginfo] target(s) in [..]
cargo fmt
2018-03-14 15:17:44 +00:00
",
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.run();
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
Fix some test output validation.
2023-11-15 22:33:27 +00:00
p.cargo("check").with_stderr("[FINISHED] [..]").run();
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +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
Package::new("baz", "0.1.2").publish();
fix(update): Make `-p` more convenient by being positional Generally, cargo avoids positional arguments. Mostly for the commands that might forward arguments to another command, like `cargo test`. It also allows some flexibility in turning flags into options. For `cargo add` and `cargo remove`, we decided to accept positionals because the motivations didn't seem to apply as much (similar to `cargo install`). This applies the pattern to `cargo update` as well which is in the same category of commands as `cargo add` and `cargo remove`. As for `--help` formatting, I'm mixed on whether `[SPEC]...` should be at the top like other positionals or should be relegated to "Package selection". I went with the latter mostly to make it easier to visualize the less common choice. Switching to a positional for `cargo update` (while keeping `-p` for backwards compatibility) was referenced in #12425.
2023-08-23 14:13:34 +00:00
p.cargo("update")
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
.arg(&format!("{}#bar", foo.url()))
.with_stderr(
Don't abort resolution on transitive updates This commit is directed at fixing #4127, allowing the resolver to automatically perform transitive updates when required. A few use casese and tagged links are hanging off #4127 itself, but the crux of the issue happens when you either add a dependency or update a version requirement in `Cargo.toml` which conflicts with something listed in your `Cargo.lock`. In this case Cargo would previously provide an obscure "cannot resolve" error whereas this commit updates Cargo to automatically perform a conservative re-resolution of the dependency graph. It's hoped that this commit will help reduce the number of "unresolvable" dependency graphs we've seen in the wild and otherwise make Cargo a little more ergonomic to use as well. More details can be found in the source's comments! Closes #4127 Closes #5182
2018-03-06 05:21:47 +00:00
"\
Resolve conflicts from upstream.
2018-09-09 23:59:48 +00:00
[UPDATING] git repository `file://[..]`
Update tests to use registry names
2021-06-27 19:18:36 +00:00
[UPDATING] `dummy-registry` index
Don't abort resolution on transitive updates This commit is directed at fixing #4127, allowing the resolver to automatically perform transitive updates when required. A few use casese and tagged links are hanging off #4127 itself, but the crux of the issue happens when you either add a dependency or update a version requirement in `Cargo.toml` which conflicts with something listed in your `Cargo.lock`. In this case Cargo would previously provide an obscure "cannot resolve" error whereas this commit updates Cargo to automatically perform a conservative re-resolution of the dependency graph. It's hoped that this commit will help reduce the number of "unresolvable" dependency graphs we've seen in the wild and otherwise make Cargo a little more ergonomic to use as well. More details can be found in the source's comments! Closes #4127 Closes #5182
2018-03-06 05:21:47 +00:00
",
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.run();
fix(update): Make `-p` more convenient by being positional Generally, cargo avoids positional arguments. Mostly for the commands that might forward arguments to another command, like `cargo test`. It also allows some flexibility in turning flags into options. For `cargo add` and `cargo remove`, we decided to accept positionals because the motivations didn't seem to apply as much (similar to `cargo install`). This applies the pattern to `cargo update` as well which is in the same category of commands as `cargo add` and `cargo remove`. As for `--help` formatting, I'm mixed on whether `[SPEC]...` should be at the top like other positionals or should be relegated to "Package selection". I went with the latter mostly to make it easier to visualize the less common choice. Switching to a positional for `cargo update` (while keeping `-p` for backwards compatibility) was referenced in #12425.
2023-08-23 14:13:34 +00:00
p.cargo("update https://github.com/rust-lang/crates.io-index#bar")
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
.with_stderr(
Don't abort resolution on transitive updates This commit is directed at fixing #4127, allowing the resolver to automatically perform transitive updates when required. A few use casese and tagged links are hanging off #4127 itself, but the crux of the issue happens when you either add a dependency or update a version requirement in `Cargo.toml` which conflicts with something listed in your `Cargo.lock`. In this case Cargo would previously provide an obscure "cannot resolve" error whereas this commit updates Cargo to automatically perform a conservative re-resolution of the dependency graph. It's hoped that this commit will help reduce the number of "unresolvable" dependency graphs we've seen in the wild and otherwise make Cargo a little more ergonomic to use as well. More details can be found in the source's comments! Closes #4127 Closes #5182
2018-03-06 05:21:47 +00:00
"\
Update tests to use registry names
2021-06-27 19:18:36 +00:00
[UPDATING] `dummy-registry` index
Don't abort resolution on transitive updates This commit is directed at fixing #4127, allowing the resolver to automatically perform transitive updates when required. A few use casese and tagged links are hanging off #4127 itself, but the crux of the issue happens when you either add a dependency or update a version requirement in `Cargo.toml` which conflicts with something listed in your `Cargo.lock`. In this case Cargo would previously provide an obscure "cannot resolve" error whereas this commit updates Cargo to automatically perform a conservative re-resolution of the dependency graph. It's hoped that this commit will help reduce the number of "unresolvable" dependency graphs we've seen in the wild and otherwise make Cargo a little more ergonomic to use as well. More details can be found in the source's comments! Closes #4127 Closes #5182
2018-03-06 05:21:47 +00:00
",
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.run();
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
Fix some test output validation.
2023-11-15 22:33:27 +00:00
p.cargo("check").with_stderr("[FINISHED] [..]").run();
Remove the test! macro This isn't really necessary and we can do setup manually in a few cases and lazily do it in all the others.
2016-05-25 20:55:42 +00:00
}
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
Remove the test! macro This isn't really necessary and we can do setup manually in a few cases and lazily do it in all the others.
2016-05-25 20:55:42 +00:00
fn locked_means_locked_yes_no_seriously_i_mean_locked() {
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
// this in theory exercises #2041
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("baz", "0.1.0").publish();
Package::new("baz", "0.2.0").publish();
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
Package::new("bar", "0.1.0").publish();
let foo = git::repo(&paths::root().join("override"))
cargo fmt
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[package]
name = "bar"
version = "0.1.0"
authors = []
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[dependencies]
baz = "*"
"#,
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
.build();
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +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#"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[package]
name = "foo"
version = "0.0.1"
authors = []
[dependencies]
bar = "0.1"
baz = "0.1"
[replace]
"bar:0.1.0" = {{ git = '{}' }}
"#,
cargo fmt
2018-03-14 15:17:44 +00:00
foo.url()
),
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
.build();
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
chore: update `replace` tests to use check
2023-02-16 02:54:00 +00:00
p.cargo("check").run();
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
Fix some test output validation.
2023-11-15 22:33:27 +00:00
p.cargo("check").with_stderr("[FINISHED] [..]").run();
p.cargo("check").with_stderr("[FINISHED] [..]").run();
Remove the test! macro This isn't really necessary and we can do setup manually in a few cases and lazily do it in all the others.
2016-05-25 20:55:42 +00:00
}
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
Remove the test! macro This isn't really necessary and we can do setup manually in a few cases and lazily do it in all the others.
2016-05-25 20:55:42 +00:00
fn override_wrong_name() {
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("baz", "0.1.0").publish();
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
let foo = git::repo(&paths::root().join("override"))
Dedup a bunch more manifest
2018-07-24 22:35:01 +00:00
.file("Cargo.toml", &basic_manifest("bar", "0.1.0"))
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
.file("src/lib.rs", "")
.build();
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +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#"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[package]
name = "foo"
version = "0.0.1"
authors = []
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[dependencies]
baz = "0.1"
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[replace]
"baz:0.1.0" = {{ git = '{}' }}
"#,
cargo fmt
2018-03-14 15:17:44 +00:00
foo.url()
),
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
.build();
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
chore: update `replace` tests to use check
2023-02-16 02:54:00 +00:00
p.cargo("check")
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
.with_status(101)
.with_stderr(
cargo fmt
2018-03-14 15:17:44 +00:00
"\
Update tests to new Updating msg format
2018-09-08 09:23:57 +00:00
[UPDATING] [..] index
fix test_cargo_overrides
2016-05-20 11:47:39 +00:00
[UPDATING] git repository [..]
Add path to the failure to load a dependency.
2020-02-27 16:17:18 +00:00
[ERROR] failed to get `baz` as a dependency of package `foo v0.0.1 ([..])`
Provide extra context on a query failure.
2020-02-25 18:17:11 +00:00
Caused by:
Extend pkgid syntax with `@` support In addition to `foo:1.2.3`, we now support `foo@1.2.3` for pkgids. We are also making it the default way of rendering pkgid's for the user. With cargo-add in #10472, we've decided to only use `@` in it and to add it as an alternative to `:` in the rest of cargo. `cargo-add` originally used `@`. When preparing it for merge, I switched to `:` to be consistent with pkgids. When discussing this, it was felt `@` has precedence in too many tools to switch to `:` but that we should instead switch pkgid's to use `@`, in a backwards compatible way. See also https://internals.rust-lang.org/t/feedback-on-cargo-add-before-its-merged/16024/26?u=epage
2022-04-19 21:00:15 +00:00
no matching package for override `[..]baz@0.1.0` found
Improve git error messages a bit This commit is targeted at further improving the error messages generated from git errors. For authentication errors the actual URL fetched is now printed out as well if it's different from the original URL. This should help handle `insteadOf` logic where SSH urls are used instead of HTTPS urls and users can know to track that down. Otherwise the logic about recommending `net.git-fetch-with-cli` was tweaked a bit and moved to the same location as the rest of our error reporting. Note that a change piggy-backed here as well is that `Caused by:` errors are now automatically all tabbed over a bit instead of only having the first line tabbed over. This required a good number of tests to be updated, but it's just an updated in renderings.
2020-06-25 15:25:52 +00:00
location searched: file://[..]
version required: =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
)
.run();
Remove the test! macro This isn't really necessary and we can do setup manually in a few cases and lazily do it in all the others.
2016-05-25 20:55:42 +00:00
}
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
Remove the test! macro This isn't really necessary and we can do setup manually in a few cases and lazily do it in all the others.
2016-05-25 20:55:42 +00:00
fn override_with_nothing() {
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();
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
let foo = git::repo(&paths::root().join("override"))
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
.file("src/lib.rs", "")
.build();
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +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#"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[package]
name = "foo"
version = "0.0.1"
authors = []
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[dependencies]
bar = "0.1"
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[replace]
"bar:0.1.0" = {{ git = '{}' }}
"#,
cargo fmt
2018-03-14 15:17:44 +00:00
foo.url()
),
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
.build();
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
chore: update `replace` tests to use check
2023-02-16 02:54:00 +00:00
p.cargo("check")
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
.with_status(101)
.with_stderr(
cargo fmt
2018-03-14 15:17:44 +00:00
"\
Update tests to new Updating msg format
2018-09-08 09:23:57 +00:00
[UPDATING] [..] index
fix test_cargo_overrides
2016-05-20 11:47:39 +00:00
[UPDATING] git repository [..]
Add path to the failure to load a dependency.
2020-02-27 16:17:18 +00:00
[ERROR] failed to get `bar` as a dependency of package `foo v0.0.1 ([..])`
Provide extra context on a query failure.
2020-02-25 18:17:11 +00:00
Caused by:
failed to load source for dependency `bar`
Add flags to assert lock/cache behavior to Cargo If a lock file is generated and some equivalent of `cargo fetch` is run then Cargo shouldn't ever touch the network or modify `Cargo.lock` until any `Cargo.toml` later changes, but this often wants to be asserted in some build environments where it's a programmer error if Cargo attempts to access the network. The `--locked` flag added here will assert that `Cargo.lock` does not need to change to proceed. That is, if `Cargo.lock` would be modified (as it automatically is by default) this is turned into a hard error instead. This `--frozen` will not only assert that `Cargo.lock` doesn't change (the same behavior as `--locked`), but it will also will manually prevent Cargo from touching the network by ensuring that all network requests return an error. These flags can be used in environments where it is *expected* that no network access happens (or no lockfile changes happen) because it has been pre-arranged for Cargo to not happen. Examples of this include: * CI for projects want to pass `--locked` to ensure that `Cargo.lock` is up to date before changes are checked in. * Environments with vendored dependencies want to pass `--frozen` as touching the network indicates a programmer error that something wasn't vendored correctly. A crucial property of these two flags is that **they do not change the behavior of Cargo**. They are simply assertions at a few locations in Cargo to ensure that actions expected to not happen indeed don't happen. Some documentation has also been added to this effect. Closes #2111
2016-06-28 17:39:46 +00:00
Caused by:
Resolve conflicts from upstream.
2018-09-09 23:59:48 +00:00
Unable to update file://[..]
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
Caused by:
Could not find Cargo.toml in `[..]`
cargo fmt
2018-03-14 15:17:44 +00:00
",
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.run();
Remove the test! macro This isn't really necessary and we can do setup manually in a few cases and lazily do it in all the others.
2016-05-25 20:55:42 +00:00
}
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
Remove the test! macro This isn't really necessary and we can do setup manually in a few cases and lazily do it in all the others.
2016-05-25 20:55:42 +00:00
fn override_wrong_version() {
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
let p = project()
cargo fmt
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[package]
name = "foo"
version = "0.0.1"
authors = []
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[replace]
"bar:0.1.0" = { git = 'https://example.com', version = '0.2.0' }
"#,
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.file("src/lib.rs", "")
cargotest/support: remove internal mutability in favor of switching types Remove is_build: Cell<bool> from ProjectBuilder and introduce a new type Project. is_build==false <-> ProjectBuilder is_build==true <-> Project Also add #[must_use] to ProjectBuilder to confirm its instances are surely consumed by its build() method to produce Project. The same goes for RepoBuilder. ProjectBuilder::cargo_process() was removed as its design heavily depended on the internal mutability. Signed-off-by: NODA, Kai <nodakai@gmail.com>
2017-07-22 03:12:21 +00:00
.build();
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
chore: update `replace` tests to use check
2023-02-16 02:54:00 +00:00
p.cargo("check")
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
.with_status(101)
.with_stderr(
cargo fmt
2018-03-14 15:17:44 +00:00
"\
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
error: failed to parse manifest at `[..]`
Caused by:
Extend pkgid syntax with `@` support In addition to `foo:1.2.3`, we now support `foo@1.2.3` for pkgids. We are also making it the default way of rendering pkgid's for the user. With cargo-add in #10472, we've decided to only use `@` in it and to add it as an alternative to `:` in the rest of cargo. `cargo-add` originally used `@`. When preparing it for merge, I switched to `:` to be consistent with pkgids. When discussing this, it was felt `@` has precedence in too many tools to switch to `:` but that we should instead switch pkgid's to use `@`, in a backwards compatible way. See also https://internals.rust-lang.org/t/feedback-on-cargo-add-before-its-merged/16024/26?u=epage
2022-04-19 21:00:15 +00:00
replacements cannot specify a version requirement, but found one for `[..]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
)
.run();
Remove the test! macro This isn't really necessary and we can do setup manually in a few cases and lazily do it in all the others.
2016-05-25 20:55:42 +00:00
}
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
Remove the test! macro This isn't really necessary and we can do setup manually in a few cases and lazily do it in all the others.
2016-05-25 20:55:42 +00:00
fn multiple_specs() {
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();
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +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 bar = git::repo(&paths::root().join("override"))
Dedup a bunch more manifest
2018-07-24 22:35:01 +00:00
.file("Cargo.toml", &basic_manifest("bar", "0.1.0"))
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
.file("src/lib.rs", "pub fn bar() {}")
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
.build();
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +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#"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[package]
name = "foo"
version = "0.0.1"
authors = []
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[dependencies]
bar = "0.1.0"
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[replace]
"bar:0.1.0" = {{ git = '{0}' }}
Implement source redirection This commit implements a scheme for .cargo/config files where sources can be redirected to other sources. The purpose of this will be to override crates.io for a few use cases: * Replace it with a mirror site that is sync'd to crates.io * Replace it with a "directory source" or some other local source This major feature of this redirection, however, is that none of it is encoded into the lock file. If one source is redirected to another then it is assumed that packages from both are exactly the same (e.g. `foo v0.0.1` is the same in both location). The lock file simply encodes the canonical soure (e.g. crates.io) rather than the replacement source. In the end this means that Cargo.lock files can be generated from any replacement source and shipped to other locations without the lockfile oscillating about where packages came from. Eventually this support will be extended to `Cargo.toml` itself (which will be encoded into the lock file), but that support is not implemented today. The syntax for what was implemented today looks like: # .cargo/config [source.my-awesome-registry] registry = 'https://example.com/path/to/index' [source.crates-io] replace-with = 'my-awesome-registry' Each source will have a canonical name and will be configured with the various keys underneath it (today just 'registry' and 'directory' will be accepted). The global `crates-io` source represents crates from the standard registry, and this can be replaced with other mirror sources. All tests have been modified to use this new infrastructure instead of the old `registry.index` configuration. This configuration is now also deprecated and will emit an unconditional warning about how it will no longer be used in the future. Finally, all subcommands now use this "source map" except for `cargo publish`, which will always publish to the default registry (in this case crates.io).
2016-02-03 18:54:07 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[replace."https://github.com/rust-lang/crates.io-index#bar:0.1.0"]
git = '{0}'
"#,
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.url()
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
.build();
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
chore: update `replace` tests to use check
2023-02-16 02:54:00 +00:00
p.cargo("check")
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
.with_status(101)
.with_stderr(
cargo fmt
2018-03-14 15:17:44 +00:00
"\
Update tests to new Updating msg format
2018-09-08 09:23:57 +00:00
[UPDATING] [..] index
fix test_cargo_overrides
2016-05-20 11:47:39 +00:00
[UPDATING] git repository [..]
Add path to the failure to load a dependency.
2020-02-27 16:17:18 +00:00
[ERROR] failed to get `bar` as a dependency of package `foo v0.0.1 ([..])`
Provide extra context on a query failure.
2020-02-25 18:17:11 +00:00
Caused by:
overlapping replacement specifications found:
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
Improve git error messages a bit This commit is targeted at further improving the error messages generated from git errors. For authentication errors the actual URL fetched is now printed out as well if it's different from the original URL. This should help handle `insteadOf` logic where SSH urls are used instead of HTTPS urls and users can know to track that down. Otherwise the logic about recommending `net.git-fetch-with-cli` was tweaked a bit and moved to the same location as the rest of our error reporting. Note that a change piggy-backed here as well is that `Caused by:` errors are now automatically all tabbed over a bit instead of only having the first line tabbed over. This required a good number of tests to be updated, but it's just an updated in renderings.
2020-06-25 15:25:52 +00:00
* [..]
* [..]
Implement top-level overrides This commit is an implementation of top-level overrides to be encoded into the manifest itself directly. This style of override is distinct from the existing `paths` support in `.cargo/config` in two important ways: * Top level overrides are intended to be checked in and shared amongst all developers of a project. * Top level overrides are reflected in `Cargo.lock`. The second point is crucially important here as it will ensure that an override on one machine behaves the same as an override on another machine. This solves many long-standing problems with `paths`-based overrides which suffer from some level of nondeterminism as they're not encoded. From a syntactical point of view, an override looks like: ```toml [replace] "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' } ``` This declaration indicates that whenever resolution would otherwise encounter the `libc` package version 0.2.0 from crates.io, it should instead replace it with the custom git dependency on a specific branch. The key "libc:0.2.0" here is actually a package id specification which will allow selecting various components of a graph. For example the same named package coming from two distinct locations can be selected against, as well as multiple versions of one crate in a dependency graph. The replacement dependency has the same syntax as the `[dependencies]` section of Cargo.toml. One of the major uses of this syntax will be, for example, using a temporary fork of a crate while the changes are pushed upstream to the original repo. This will avoid the need to change the intermediate projects immediately, and over time once fixes have landed upstream the `[replace]` section in a `Cargo.toml` can be removed. There are also two crucial restrictions on overrides. * A crate with the name `foo` can only get overridden with packages also of the name `foo`. * A crate can only get overridden with a crate of the exact same version. A consequence of these restrictions is that crates.io cannot be used to replace anything from crates.io. There's only one version of something on crates.io, so there's nothing else to replace it with (name/version are a unique key). Closes #942
2016-02-09 23:42:17 +00:00
Improve git error messages a bit This commit is targeted at further improving the error messages generated from git errors. For authentication errors the actual URL fetched is now printed out as well if it's different from the original URL. This should help handle `insteadOf` logic where SSH urls are used instead of HTTPS urls and users can know to track that down. Otherwise the logic about recommending `net.git-fetch-with-cli` was tweaked a bit and moved to the same location as the rest of our error reporting. Note that a change piggy-backed here as well is that `Caused by:` errors are now automatically all tabbed over a bit instead of only having the first line tabbed over. This required a good number of tests to be updated, but it's just an updated in renderings.
2020-06-25 15:25:52 +00:00
both specifications match: bar v0.1.0
cargo fmt
2018-03-14 15:17:44 +00:00
",
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.run();
Remove the test! macro This isn't really necessary and we can do setup manually in a few cases and lazily do it in all the others.
2016-05-25 20:55:42 +00:00
}
Don't throw away errors with `-p` arguments This was unfortunately ignoring errors which would helpfully tell you how to rerun a command with a more precise specification. Closes #2641
2016-05-20 21:25:43 +00:00
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
Remove the test! macro This isn't really necessary and we can do setup manually in a few cases and lazily do it in all the others.
2016-05-25 20:55:42 +00:00
fn test_override_dep() {
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();
Don't throw away errors with `-p` arguments This was unfortunately ignoring errors which would helpfully tell you how to rerun a command with a more precise specification. Closes #2641
2016-05-20 21:25:43 +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 bar = git::repo(&paths::root().join("override"))
Dedup a bunch more manifest
2018-07-24 22:35:01 +00:00
.file("Cargo.toml", &basic_manifest("bar", "0.1.0"))
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
.file("src/lib.rs", "pub fn bar() {}")
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
.build();
Don't throw away errors with `-p` arguments This was unfortunately ignoring errors which would helpfully tell you how to rerun a command with a more precise specification. Closes #2641
2016-05-20 21:25:43 +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#"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[package]
name = "foo"
version = "0.0.1"
authors = []
Don't throw away errors with `-p` arguments This was unfortunately ignoring errors which would helpfully tell you how to rerun a command with a more precise specification. Closes #2641
2016-05-20 21:25:43 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[dependencies]
bar = "0.1.0"
Don't throw away errors with `-p` arguments This was unfortunately ignoring errors which would helpfully tell you how to rerun a command with a more precise specification. Closes #2641
2016-05-20 21:25:43 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[replace]
"bar:0.1.0" = {{ git = '{0}' }}
"#,
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.url()
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
.build();
Don't throw away errors with `-p` arguments This was unfortunately ignoring errors which would helpfully tell you how to rerun a command with a more precise specification. Closes #2641
2016-05-20 21:25:43 +00:00
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
p.cargo("test -p bar")
.with_status(101)
.with_stderr_contains(
cargo fmt
2018-03-14 15:17:44 +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
error: There are multiple `bar` packages in your project, and the [..]
Don't throw away errors with `-p` arguments This was unfortunately ignoring errors which would helpfully tell you how to rerun a command with a more precise specification. Closes #2641
2016-05-20 21:25:43 +00:00
Please re-run this command with [..]
Extend pkgid syntax with `@` support In addition to `foo:1.2.3`, we now support `foo@1.2.3` for pkgids. We are also making it the default way of rendering pkgid's for the user. With cargo-add in #10472, we've decided to only use `@` in it and to add it as an alternative to `:` in the rest of cargo. `cargo-add` originally used `@`. When preparing it for merge, I switched to `:` to be consistent with pkgids. When discussing this, it was felt `@` has precedence in too many tools to switch to `:` but that we should instead switch pkgid's to use `@`, in a backwards compatible way. See also https://internals.rust-lang.org/t/feedback-on-cargo-add-before-its-merged/16024/26?u=epage
2022-04-19 21:00:15 +00:00
[..]#bar@0.1.0
[..]#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
)
.run();
Remove the test! macro This isn't really necessary and we can do setup manually in a few cases and lazily do it in all the others.
2016-05-25 20:55:42 +00:00
}
Don't lock overrides if we're updating them There was already a function for this, `keep`, it was just forgotten to be called. Closes #2766
2016-06-05 07:19:55 +00:00
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
Don't lock overrides if we're updating them There was already a function for this, `keep`, it was just forgotten to be called. Closes #2766
2016-06-05 07:19:55 +00:00
fn update() {
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();
Don't lock overrides if we're updating them There was already a function for this, `keep`, it was just forgotten to be called. Closes #2766
2016-06-05 07:19:55 +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 bar = git::repo(&paths::root().join("override"))
Dedup a bunch more manifest
2018-07-24 22:35:01 +00:00
.file("Cargo.toml", &basic_manifest("bar", "0.1.0"))
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
.file("src/lib.rs", "pub fn bar() {}")
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
.build();
Don't lock overrides if we're updating them There was already a function for this, `keep`, it was just forgotten to be called. Closes #2766
2016-06-05 07:19:55 +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#"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[package]
name = "foo"
version = "0.0.1"
authors = []
Don't lock overrides if we're updating them There was already a function for this, `keep`, it was just forgotten to be called. Closes #2766
2016-06-05 07:19:55 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[dependencies]
bar = "0.1.0"
Don't lock overrides if we're updating them There was already a function for this, `keep`, it was just forgotten to be called. Closes #2766
2016-06-05 07:19:55 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[replace]
"bar:0.1.0" = {{ git = '{0}' }}
"#,
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.url()
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
.build();
Don't lock overrides if we're updating them There was already a function for this, `keep`, it was just forgotten to be called. Closes #2766
2016-06-05 07:19:55 +00:00
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
p.cargo("generate-lockfile").run();
p.cargo("update")
.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
Don't lock overrides if we're updating them There was already a function for this, `keep`, it was just forgotten to be called. Closes #2766
2016-06-05 07:19:55 +00:00
[UPDATING] git repository `[..]`
cargo fmt
2018-03-14 15:17:44 +00:00
",
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.run();
Don't lock overrides if we're updating them There was already a function for this, `keep`, it was just forgotten to be called. Closes #2766
2016-06-05 07:19:55 +00:00
}
Add minimal version of #2595 to test suite (test currently fails)
2016-07-14 08:44: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
// foo -> near -> far
Add minimal version of #2595 to test suite (test currently fails)
2016-07-14 08:44:31 +00:00
// near is overridden with itself
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
Add minimal version of #2595 to test suite (test currently fails)
2016-07-14 08:44:31 +00:00
fn no_override_self() {
let deps = git::repo(&paths::root().join("override"))
Dedup a bunch more manifest
2018-07-24 22:35:01 +00:00
.file("far/Cargo.toml", &basic_manifest("far", "0.1.0"))
Add minimal version of #2595 to test suite (test currently fails)
2016-07-14 08:44:31 +00:00
.file("far/src/lib.rs", "")
cargo fmt
2018-03-14 15:17:44 +00:00
.file(
"near/Cargo.toml",
r#"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[package]
name = "near"
version = "0.1.0"
authors = []
Add minimal version of #2595 to test suite (test currently fails)
2016-07-14 08:44:31 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[dependencies]
far = { path = "../far" }
"#,
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.file("near/src/lib.rs", "#![no_std] pub extern crate far;")
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
.build();
Add minimal version of #2595 to test suite (test currently fails)
2016-07-14 08:44: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",
&format!(
r#"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[package]
name = "foo"
version = "0.0.1"
authors = []
Add minimal version of #2595 to test suite (test currently fails)
2016-07-14 08:44:31 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[dependencies]
near = {{ git = '{0}' }}
Add minimal version of #2595 to test suite (test currently fails)
2016-07-14 08:44:31 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[replace]
"near:0.1.0" = {{ git = '{0}' }}
"#,
cargo fmt
2018-03-14 15:17:44 +00:00
deps.url()
),
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.file("src/lib.rs", "#![no_std] pub extern crate near;")
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
.build();
Add minimal version of #2595 to test suite (test currently fails)
2016-07-14 08:44:31 +00:00
chore: update `replace` tests to use check
2023-02-16 02:54:00 +00:00
p.cargo("check --verbose").run();
Add minimal version of #2595 to test suite (test currently fails)
2016-07-14 08:44:31 +00:00
}
Warn about path overrides that won't work Cargo has a long-standing [bug] in path overrides where they will cause spurious rebuilds of crates in the crate graph. This can be very difficult to diagnose and be incredibly frustrating as well. Unfortunately, though, it's behavior that fundamentally can't be fixed in Cargo. The crux of the problem happens when a `path` replacement changes something about the list of dependencies of the crate that it's replacing. This alteration to the list of dependencies *cannot be tracked by Cargo* as the lock file was previously emitted. In the best case this ends up causing random recompiles. In the worst case it cause infinite registry updates that always result in recompiles. A solution to this intention, changing the dependency graph of an overridden dependency, was [implemented] with the `[replace]` feature in Cargo awhile back. With that in mind, this commit implements a *warning* whenever a bad dependency replacement is detected. The message here is pretty wordy, but it's intended to convey that you should switch to using `[replace]` for a more robust impelmentation, and it can also give security to anyone using `path` overrides that if they get past this warning everything should work as intended. [bug]: https://github.com/rust-lang/cargo/issues/2041 [implemented]: http://doc.crates.io/specifying-dependencies.html#overriding-dependencies Closes #2041
2016-09-29 23:35:22 +00:00
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
Load [replace] sections from lock files This commit fixes a bug in Cargo where path-based [replace] dependencies were accidentally not loaded from lock files. This meant that even with a lock file some compilations could accidentally become nondeterministic. The fix here is to just look at all path dependencies, even those specified through [replace] Closes #3216
2016-10-21 02:02:38 +00:00
fn override_an_override() {
cargo fmt
2018-03-14 15:17:44 +00:00
Package::new("chrono", "0.2.0")
.dep("serde", "< 0.9")
.publish();
Load [replace] sections from lock files This commit fixes a bug in Cargo where path-based [replace] dependencies were accidentally not loaded from lock files. This meant that even with a lock file some compilations could accidentally become nondeterministic. The fix here is to just look at all path dependencies, even those specified through [replace] Closes #3216
2016-10-21 02:02:38 +00:00
Package::new("serde", "0.7.0")
.file("src/lib.rs", "pub fn serde07() {}")
.publish();
Package::new("serde", "0.8.0")
.file("src/lib.rs", "pub fn serde08() {}")
.publish();
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
let p = project()
cargo fmt
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[package]
name = "foo"
version = "0.0.1"
authors = []
Load [replace] sections from lock files This commit fixes a bug in Cargo where path-based [replace] dependencies were accidentally not loaded from lock files. This meant that even with a lock file some compilations could accidentally become nondeterministic. The fix here is to just look at all path dependencies, even those specified through [replace] Closes #3216
2016-10-21 02:02:38 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[dependencies]
chrono = "0.2"
serde = "0.8"
Load [replace] sections from lock files This commit fixes a bug in Cargo where path-based [replace] dependencies were accidentally not loaded from lock files. This meant that even with a lock file some compilations could accidentally become nondeterministic. The fix here is to just look at all path dependencies, even those specified through [replace] Closes #3216
2016-10-21 02:02:38 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[replace]
"chrono:0.2.0" = { path = "chrono" }
"serde:0.8.0" = { path = "serde" }
"#,
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.file(
cargo fmt
2018-03-14 15:17:44 +00:00
"Cargo.lock",
r#"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[[package]]
name = "foo"
version = "0.0.1"
dependencies = [
"chrono 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)",
"serde 0.8.0 (registry+https://github.com/rust-lang/crates.io-index)",
]
[[package]]
name = "chrono"
version = "0.2.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
replace = "chrono 0.2.0"
[[package]]
name = "chrono"
version = "0.2.0"
dependencies = [
"serde 0.7.0 (registry+https://github.com/rust-lang/crates.io-index)",
]
[[package]]
name = "serde"
version = "0.7.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
[[package]]
name = "serde"
version = "0.8.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
replace = "serde 0.8.0"
[[package]]
name = "serde"
version = "0.8.0"
"#,
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.file(
cargo fmt
2018-03-14 15:17:44 +00:00
"src/lib.rs",
"
Load [replace] sections from lock files This commit fixes a bug in Cargo where path-based [replace] dependencies were accidentally not loaded from lock files. This meant that even with a lock file some compilations could accidentally become nondeterministic. The fix here is to just look at all path dependencies, even those specified through [replace] Closes #3216
2016-10-21 02:02:38 +00:00
extern crate chrono;
extern crate serde;
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
pub fn foo() {
Load [replace] sections from lock files This commit fixes a bug in Cargo where path-based [replace] dependencies were accidentally not loaded from lock files. This meant that even with a lock file some compilations could accidentally become nondeterministic. The fix here is to just look at all path dependencies, even those specified through [replace] Closes #3216
2016-10-21 02:02:38 +00:00
chrono::chrono();
serde::serde08_override();
}
cargo fmt
2018-03-14 15:17:44 +00:00
",
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.file(
cargo fmt
2018-03-14 15:17:44 +00:00
"chrono/Cargo.toml",
r#"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[package]
name = "chrono"
version = "0.2.0"
authors = []
Load [replace] sections from lock files This commit fixes a bug in Cargo where path-based [replace] dependencies were accidentally not loaded from lock files. This meant that even with a lock file some compilations could accidentally become nondeterministic. The fix here is to just look at all path dependencies, even those specified through [replace] Closes #3216
2016-10-21 02:02:38 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[dependencies]
serde = "< 0.9"
"#,
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.file(
cargo fmt
2018-03-14 15:17:44 +00:00
"chrono/src/lib.rs",
"
Load [replace] sections from lock files This commit fixes a bug in Cargo where path-based [replace] dependencies were accidentally not loaded from lock files. This meant that even with a lock file some compilations could accidentally become nondeterministic. The fix here is to just look at all path dependencies, even those specified through [replace] Closes #3216
2016-10-21 02:02:38 +00:00
extern crate serde;
pub fn chrono() {
serde::serde07();
}
cargo fmt
2018-03-14 15:17:44 +00:00
",
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.file("serde/Cargo.toml", &basic_manifest("serde", "0.8.0"))
Declare one-line files on one line, in test projects
2018-07-25 00:30:32 +00:00
.file("serde/src/lib.rs", "pub fn serde08_override() {}")
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
.build();
Load [replace] sections from lock files This commit fixes a bug in Cargo where path-based [replace] dependencies were accidentally not loaded from lock files. This meant that even with a lock file some compilations could accidentally become nondeterministic. The fix here is to just look at all path dependencies, even those specified through [replace] Closes #3216
2016-10-21 02:02:38 +00:00
chore: update `replace` tests to use check
2023-02-16 02:54:00 +00:00
p.cargo("check -v").run();
Load [replace] sections from lock files This commit fixes a bug in Cargo where path-based [replace] dependencies were accidentally not loaded from lock files. This meant that even with a lock file some compilations could accidentally become nondeterministic. The fix here is to just look at all path dependencies, even those specified through [replace] Closes #3216
2016-10-21 02:02:38 +00:00
}
Default urls in [replace] to crates.io The intention was to do this, and it mistakenly didn't happen! Closes #3235
2016-11-02 17:32:35 +00:00
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
Default urls in [replace] to crates.io The intention was to do this, and it mistakenly didn't happen! Closes #3235
2016-11-02 17:32:35 +00:00
fn overriding_nonexistent_no_spurious() {
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").dep("baz", "0.1").publish();
Package::new("baz", "0.1.0").publish();
Default urls in [replace] to crates.io The intention was to do this, and it mistakenly didn't happen! Closes #3235
2016-11-02 17:32:35 +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 bar = git::repo(&paths::root().join("override"))
cargo fmt
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[package]
name = "bar"
version = "0.1.0"
authors = []
Default urls in [replace] to crates.io The intention was to do this, and it mistakenly didn't happen! Closes #3235
2016-11-02 17:32:35 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[dependencies]
baz = { path = "baz" }
"#,
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.file("src/lib.rs", "pub fn bar() {}")
Dedup a bunch more manifest
2018-07-24 22:35:01 +00:00
.file("baz/Cargo.toml", &basic_manifest("baz", "0.1.0"))
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
.file("baz/src/lib.rs", "pub fn baz() {}")
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
.build();
Default urls in [replace] to crates.io The intention was to do this, and it mistakenly didn't happen! Closes #3235
2016-11-02 17:32:35 +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#"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[package]
name = "foo"
version = "0.0.1"
authors = []
[dependencies]
bar = "0.1.0"
[replace]
"bar:0.1.0" = {{ git = '{url}' }}
"baz:0.1.0" = {{ git = '{url}' }}
"#,
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
url = bar.url()
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
.build();
Default urls in [replace] to crates.io The intention was to do this, and it mistakenly didn't happen! Closes #3235
2016-11-02 17:32:35 +00:00
chore: update `replace` tests to use check
2023-02-16 02:54:00 +00:00
p.cargo("check").run();
p.cargo("check")
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
.with_stderr(
"\
Extend pkgid syntax with `@` support In addition to `foo:1.2.3`, we now support `foo@1.2.3` for pkgids. We are also making it the default way of rendering pkgid's for the user. With cargo-add in #10472, we've decided to only use `@` in it and to add it as an alternative to `:` in the rest of cargo. `cargo-add` originally used `@`. When preparing it for merge, I switched to `:` to be consistent with pkgids. When discussing this, it was felt `@` has precedence in too many tools to switch to `:` but that we should instead switch pkgid's to use `@`, in a backwards compatible way. See also https://internals.rust-lang.org/t/feedback-on-cargo-add-before-its-merged/16024/26?u=epage
2022-04-19 21:00:15 +00:00
[WARNING] package replacement is not used: [..]baz@0.1.0
Default urls in [replace] to crates.io The intention was to do this, and it mistakenly didn't happen! Closes #3235
2016-11-02 17:32:35 +00:00
[FINISHED] [..]
cargo fmt
2018-03-14 15:17:44 +00:00
",
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.with_stdout("")
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
.run();
Default urls in [replace] to crates.io The intention was to do this, and it mistakenly didn't happen! Closes #3235
2016-11-02 17:32:35 +00:00
}
Fix regression with path overrides If an override points to a path dependency then that's not locked, so we're missing information for that, but it's already warned about, so no need to worry.
2016-11-04 00:00:13 +00:00
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
Fix false positive about unused replace
2017-03-29 09:58:45 +00:00
fn no_warnings_when_replace_is_used_in_another_workspace_member() {
Package::new("bar", "0.1.0").publish();
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("baz", "0.1.0").publish();
Fix false positive about unused replace
2017-03-29 09:58:45 +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 false positive about unused replace
2017-03-29 09:58:45 +00:00
[workspace]
members = [ "first_crate", "second_crate"]
[replace]
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
"bar:0.1.0" = { path = "local_bar" }
"#,
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.file(
cargo fmt
2018-03-14 15:17:44 +00:00
"first_crate/Cargo.toml",
r#"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[package]
name = "first_crate"
version = "0.1.0"
Fix false positive about unused replace
2017-03-29 09:58:45 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[dependencies]
bar = "0.1.0"
"#,
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.file("first_crate/src/lib.rs", "")
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
.file(
"second_crate/Cargo.toml",
&basic_manifest("second_crate", "0.1.0"),
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.file("second_crate/src/lib.rs", "")
Dedup a bunch more manifest
2018-07-24 22:35:01 +00:00
.file("local_bar/Cargo.toml", &basic_manifest("bar", "0.1.0"))
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
.file("local_bar/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
.build();
Fix false positive about unused replace
2017-03-29 09:58:45 +00:00
chore: update `replace` tests to use check
2023-02-16 02:54:00 +00:00
p.cargo("check")
Testsuite: Make `cwd()` relative to project root. It's a fairly common pattern, and it seemed natural to me.
2019-03-20 23:34:56 +00:00
.cwd("first_crate")
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
.with_stdout("")
.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
chore: update `replace` tests to use check
2023-02-16 02:54:00 +00:00
[CHECKING] bar v0.1.0 ([..])
[CHECKING] first_crate v0.1.0 ([..])
cargo fmt
2018-03-14 15:17:44 +00:00
[FINISHED] [..]",
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.run();
cargo fmt
2018-03-14 15:17:44 +00:00
chore: update `replace` tests to use check
2023-02-16 02:54:00 +00:00
p.cargo("check")
Testsuite: Make `cwd()` relative to project root. It's a fairly common pattern, and it seemed natural to me.
2019-03-20 23:34:56 +00:00
.cwd("second_crate")
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
.with_stdout("")
.with_stderr(
cargo fmt
2018-03-14 15:17:44 +00:00
"\
chore: update `replace` tests to use check
2023-02-16 02:54:00 +00:00
[CHECKING] second_crate v0.1.0 ([..])
cargo fmt
2018-03-14 15:17:44 +00:00
[FINISHED] [..]",
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.run();
Fix false positive about unused replace
2017-03-29 09:58:45 +00:00
}
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
Fix regression with path overrides If an override points to a path dependency then that's not locked, so we're missing information for that, but it's already warned about, so no need to worry.
2016-11-04 00:00:13 +00:00
fn replace_to_path_dep() {
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").dep("baz", "0.1").publish();
Package::new("baz", "0.1.0").publish();
Fix regression with path overrides If an override points to a path dependency then that's not locked, so we're missing information for that, but it's already warned about, so no need to worry.
2016-11-04 00:00:13 +00:00
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
let p = project()
cargo fmt
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[package]
name = "foo"
version = "0.0.1"
authors = []
Fix regression with path overrides If an override points to a path dependency then that's not locked, so we're missing information for that, but it's already warned about, so no need to worry.
2016-11-04 00:00:13 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[dependencies]
bar = "0.1.0"
Fix regression with path overrides If an override points to a path dependency then that's not locked, so we're missing information for that, but it's already warned about, so no need to worry.
2016-11-04 00:00:13 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[replace]
"bar:0.1.0" = { path = "bar" }
"#,
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.file("src/lib.rs", "extern crate bar;")
cargo fmt
2018-03-14 15:17:44 +00:00
.file(
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/Cargo.toml",
cargo fmt
2018-03-14 15:17:44 +00:00
r#"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[package]
name = "bar"
version = "0.1.0"
authors = []
Fix regression with path overrides If an override points to a path dependency then that's not locked, so we're missing information for that, but it's already warned about, so no need to worry.
2016-11-04 00:00:13 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[dependencies]
baz = { path = "baz" }
"#,
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.file(
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
"bar/src/lib.rs",
"extern crate baz; pub fn bar() { baz::baz(); }",
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.file("bar/baz/Cargo.toml", &basic_manifest("baz", "0.1.0"))
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
.file("bar/baz/src/lib.rs", "pub fn baz() {}")
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
.build();
Fix regression with path overrides If an override points to a path dependency then that's not locked, so we're missing information for that, but it's already warned about, so no need to worry.
2016-11-04 00:00:13 +00:00
chore: update `replace` tests to use check
2023-02-16 02:54:00 +00:00
p.cargo("check").run();
Fix regression with path overrides If an override points to a path dependency then that's not locked, so we're missing information for that, but it's already warned about, so no need to worry.
2016-11-04 00:00:13 +00:00
}
Test for bad path overrides with summaries Bad path overrides are currently detected to issue warnings in cases where path overrides are not suitable and have exhibited buggy behavior in the past. Unfortunately though it looks like some false positives are being issued, causing unnecessary confusion about `paths` overrides. This commit fixes the detection of these "bad path overrides" by comparing `Summary` dependencies (what's written down in `Cargo.toml`) rather than comparing the `Cargo.toml` of the override with `Cargo.lock`. We're guaranteed that the package we're overridding has already been resolved into `Cargo.lock`, so we know that if the two `Cargo.toml` files are equivalent we'll continue with the same crate graph. I'm not actually entirely sure why I originally thought it'd be better to go through the `Cargo.lock` comparison route. Unfortunately that doesn't take into account optional deps which aren't in `Cargo.lock` but are in `Cargo.toml` of the override, causing the false positive. This method, however, simply ensures that the two dependency lists are the same. Closes #3313
2016-11-28 16:51:36 +00:00
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
Fix overriding mixing with default features Previously Cargo had a bug where if a crate *without* a default feature was overridden with one that did indeed have a default feature then the default may not end up getting activated by accident. The fix was to avoid returning too quickly hen activating dependencies until after we've inspected and learned about replacements. Closes #3812
2017-03-17 23:12:11 +00:00
fn override_with_default_feature() {
Package::new("another", "0.1.0").publish();
cargo fmt
2018-03-14 15:17:44 +00:00
Package::new("another", "0.1.1").dep("bar", "0.1").publish();
Fix overriding mixing with default features Previously Cargo had a bug where if a crate *without* a default feature was overridden with one that did indeed have a default feature then the default may not end up getting activated by accident. The fix was to avoid returning too quickly hen activating dependencies until after we've inspected and learned about replacements. Closes #3812
2017-03-17 23:12:11 +00:00
Package::new("bar", "0.1.0").publish();
Rework some test projects to use the "foo" default Generally that means either switching "foo" and "bar" around (reversing the arrow), or it means push "foo" to "bar" (and sometimes "bar" to "baz", etc..) to free up "foo". For trivia that leaves 80/1222 outliers, therefore 93.4% of test project use the default. :)
2018-07-20 17:41:44 +00:00
let p = project()
cargo fmt
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[package]
name = "foo"
version = "0.0.1"
authors = []
Fix overriding mixing with default features Previously Cargo had a bug where if a crate *without* a default feature was overridden with one that did indeed have a default feature then the default may not end up getting activated by accident. The fix was to avoid returning too quickly hen activating dependencies until after we've inspected and learned about replacements. Closes #3812
2017-03-17 23:12:11 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[dependencies]
bar = { path = "bar", default-features = false }
another = "0.1"
another2 = { path = "another2" }
Fix overriding mixing with default features Previously Cargo had a bug where if a crate *without* a default feature was overridden with one that did indeed have a default feature then the default may not end up getting activated by accident. The fix was to avoid returning too quickly hen activating dependencies until after we've inspected and learned about replacements. Closes #3812
2017-03-17 23:12:11 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[replace]
'bar:0.1.0' = { path = "bar" }
"#,
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.file("src/main.rs", "extern crate bar; fn main() { bar::bar(); }")
cargo fmt
2018-03-14 15:17:44 +00:00
.file(
"bar/Cargo.toml",
r#"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[package]
name = "bar"
version = "0.1.0"
authors = []
Fix overriding mixing with default features Previously Cargo had a bug where if a crate *without* a default feature was overridden with one that did indeed have a default feature then the default may not end up getting activated by accident. The fix was to avoid returning too quickly hen activating dependencies until after we've inspected and learned about replacements. Closes #3812
2017-03-17 23:12:11 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[features]
default = []
"#,
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.file(
cargo fmt
2018-03-14 15:17:44 +00:00
"bar/src/lib.rs",
r#"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
#[cfg(feature = "default")]
pub fn bar() {}
"#,
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.file(
cargo fmt
2018-03-14 15:17:44 +00:00
"another2/Cargo.toml",
r#"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[package]
name = "another2"
version = "0.1.0"
authors = []
Fix overriding mixing with default features Previously Cargo had a bug where if a crate *without* a default feature was overridden with one that did indeed have a default feature then the default may not end up getting activated by accident. The fix was to avoid returning too quickly hen activating dependencies until after we've inspected and learned about replacements. Closes #3812
2017-03-17 23:12:11 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[dependencies]
bar = { version = "0.1", default-features = false }
"#,
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.file("another2/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
.build();
Fix overriding mixing with default features Previously Cargo had a bug where if a crate *without* a default feature was overridden with one that did indeed have a default feature then the default may not end up getting activated by accident. The fix was to avoid returning too quickly hen activating dependencies until after we've inspected and learned about replacements. Closes #3812
2017-03-17 23:12:11 +00:00
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
p.cargo("run").run();
Fix overriding mixing with default features Previously Cargo had a bug where if a crate *without* a default feature was overridden with one that did indeed have a default feature then the default may not end up getting activated by accident. The fix was to avoid returning too quickly hen activating dependencies until after we've inspected and learned about replacements. Closes #3812
2017-03-17 23:12:11 +00:00
}
Detect cyclic dependencies through [replace] Previously this'd cause a stack overflow in Cargo later in the compilation graph, but this is intended to get caught during resolution. Closes #3831
2017-03-20 19:43:44 +00:00
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
Detect cyclic dependencies through [replace] Previously this'd cause a stack overflow in Cargo later in the compilation graph, but this is intended to get caught during resolution. Closes #3831
2017-03-20 19:43:44 +00:00
fn override_plus_dep() {
Package::new("bar", "0.1.0").publish();
Remove the argument from the `project` test support function By rewriting the tests, with rerast (https://github.com/google/rerast), to use the newly introduced "at" method. First I added the following temporary function to cargotest::support: pub fn project_foo() -> ProjectBuilder { project("foo") } Then I defined the following rewrite.rs: use cargotest::support::{ project, project_foo }; fn rule1(a: &'static str) { replace!(project("foo") => project_foo()); replace!(project(a) => project_foo().at(a)); } Then I ran rerast: cargo +nightly rerast --rules_file=rewrite.rs --force --targets tests --file tests/testsuite/main.rs Finally I searched and replaced the references to project_foo with argument-less project (a little awkardly on macOS with a git clean). find tests -type f -exec sed -i -e 's/project_foo/project/g' {} + git clean -d tests
2018-07-20 11:47:47 +00:00
let p = project()
cargo fmt
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[package]
name = "foo"
version = "0.0.1"
authors = []
Detect cyclic dependencies through [replace] Previously this'd cause a stack overflow in Cargo later in the compilation graph, but this is intended to get caught during resolution. Closes #3831
2017-03-20 19:43:44 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[dependencies]
bar = "0.1"
Detect cyclic dependencies through [replace] Previously this'd cause a stack overflow in Cargo later in the compilation graph, but this is intended to get caught during resolution. Closes #3831
2017-03-20 19:43:44 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[replace]
'bar:0.1.0' = { path = "bar" }
"#,
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(
"bar/Cargo.toml",
r#"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[package]
name = "bar"
version = "0.1.0"
authors = []
[dependencies]
foo = { path = ".." }
"#,
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.file("bar/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
.build();
Detect cyclic dependencies through [replace] Previously this'd cause a stack overflow in Cargo later in the compilation graph, but this is intended to get caught during resolution. Closes #3831
2017-03-20 19:43:44 +00:00
chore: update `replace` tests to use check
2023-02-16 02:54:00 +00:00
p.cargo("check")
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
.with_status(101)
.with_stderr_contains("error: cyclic package dependency: [..]")
.run();
Detect cyclic dependencies through [replace] Previously this'd cause a stack overflow in Cargo later in the compilation graph, but this is intended to get caught during resolution. Closes #3831
2017-03-20 19:43:44 +00:00
}
test(replace): Show behavior post-#12614 PR #12614 - Changed ignored replaces to not-ignored - Has bugs in matching replaces
2023-10-10 21:18:56 +00:00
#[cargo_test]
fix(replace): Error, rather than assert, on version mismatch
2023-10-11 02:31:31 +00:00
fn override_generic_matching_other_versions() {
test(replace): Show behavior post-#12614 PR #12614 - Changed ignored replaces to not-ignored - Has bugs in matching replaces
2023-10-10 21:18:56 +00:00
Package::new("bar", "0.1.0+a").publish();
let bar = git::repo(&paths::root().join("override"))
.file("Cargo.toml", &basic_manifest("bar", "0.1.0"))
.file("src/lib.rs", "pub fn bar() {}")
.build();
let p = project()
.file(
"Cargo.toml",
&format!(
r#"
[package]
name = "foo"
version = "0.0.1"
authors = []
[dependencies]
bar = "0.1.0"
[replace]
"bar:0.1.0" = {{ git = '{}' }}
"#,
bar.url()
),
)
.file(
"src/lib.rs",
"extern crate bar; pub fn foo() { bar::bar(); }",
)
.build();
p.cargo("check")
.with_stderr(
"\
[UPDATING] `dummy-registry` index
[UPDATING] git repository `[..]`
fix(replace): Error, rather than assert, on version mismatch
2023-10-11 02:31:31 +00:00
[ERROR] failed to get `bar` as a dependency of package `foo v0.0.1 ([..]/foo)`
Caused by:
replacement specification `https://github.com/rust-lang/crates.io-index#bar@0.1.0` matched 0.1.0+a and tried to override it with 0.1.0
avoid matching unrelated packages by being more specific
test(replace): Show behavior post-#12614 PR #12614 - Changed ignored replaces to not-ignored - Has bugs in matching replaces
2023-10-10 21:18:56 +00:00
",
)
.with_status(101)
.run();
}
#[cargo_test]
fix(spec): Ensure PackageIdSpec respects version 'build' field
2023-10-10 21:39:46 +00:00
fn override_respects_spec_metadata() {
test(replace): Show behavior post-#12614 PR #12614 - Changed ignored replaces to not-ignored - Has bugs in matching replaces
2023-10-10 21:18:56 +00:00
Package::new("bar", "0.1.0+a").publish();
let bar = git::repo(&paths::root().join("override"))
.file("Cargo.toml", &basic_manifest("bar", "0.1.0+a"))
.file("src/lib.rs", "pub fn bar() {}")
.build();
let p = project()
.file(
"Cargo.toml",
&format!(
r#"
[package]
name = "foo"
version = "0.0.1"
authors = []
[dependencies]
bar = "0.1.0"
[replace]
"bar:0.1.0+notTheBuild" = {{ git = '{}' }}
"#,
bar.url()
),
)
.file(
"src/lib.rs",
"extern crate bar; pub fn foo() { bar::bar(); }",
)
.build();
p.cargo("check")
.with_stderr(
"\
[UPDATING] `dummy-registry` index
fix(spec): Ensure PackageIdSpec respects version 'build' field
2023-10-10 21:39:46 +00:00
[WARNING] package replacement is not used: https://github.com/rust-lang/crates.io-index#bar@0.1.0+notTheBuild
[DOWNLOADING] crates ...
[DOWNLOADED] bar v0.1.0+a (registry `dummy-registry`)
[CHECKING] bar v0.1.0+a
[CHECKING] foo v0.0.1 ([..]/foo)
[..]
[..]
[..]
[..]
[..]
[..]
[..]
Update test for override respects spec metadata
2023-11-29 16:30:07 +00:00
error: could not compile `foo` (lib) due to 1 previous error
test(replace): Show behavior post-#12614 PR #12614 - Changed ignored replaces to not-ignored - Has bugs in matching replaces
2023-10-10 21:18:56 +00:00
",
)
fix(spec): Ensure PackageIdSpec respects version 'build' field
2023-10-10 21:39:46 +00:00
.with_status(101)
test(replace): Show behavior post-#12614 PR #12614 - Changed ignored replaces to not-ignored - Has bugs in matching replaces
2023-10-10 21:18:56 +00:00
.run();
}
#[cargo_test]
test(replace): Clarify name for remaining new test
2023-10-11 02:35:02 +00:00
fn override_spec_metadata_is_optional() {
test(replace): Show behavior post-#12614 PR #12614 - Changed ignored replaces to not-ignored - Has bugs in matching replaces
2023-10-10 21:18:56 +00:00
Package::new("bar", "0.1.0+a").publish();
let bar = git::repo(&paths::root().join("override"))
.file("Cargo.toml", &basic_manifest("bar", "0.1.0+a"))
.file("src/lib.rs", "pub fn bar() {}")
.build();
let p = project()
.file(
"Cargo.toml",
&format!(
r#"
[package]
name = "foo"
version = "0.0.1"
authors = []
[dependencies]
bar = "0.1.0"
[replace]
"bar:0.1.0" = {{ git = '{}' }}
"#,
bar.url()
),
)
.file(
"src/lib.rs",
"extern crate bar; pub fn foo() { bar::bar(); }",
)
.build();
p.cargo("check")
.with_stderr(
"\
[UPDATING] `dummy-registry` index
[UPDATING] git repository `[..]`
[CHECKING] bar v0.1.0+a (file://[..])
[CHECKING] foo v0.0.1 ([CWD])
[FINISHED] dev [unoptimized + debuginfo] target(s) in [..]
",
)
.run();
}
Reference in a new issue Copy permalink