.. with mutliple calls of:
fastmod --accept-all '\.cargo\("([^"]+)"\)\.arg\("([^"]+)"\)' '.cargo("${1} ${2}")' tests/testsuite/
until no changes are left.
* Collapse the nested cargotest::support module into the cargotest
module (merge the mod.rs's)
* Rename the cargotest module to support
* Nest the top-level hamcrest module into support
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. :)
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
This fixes an accidental regression introduced in #5012 where the
`--all-features` CLI flag was only propagated to the "main crate" as opposed to
all workspace packages. This behavior has [already been deemed][pr] as
"basically not what you want", but for now it's best to avoid the regression.
Closes#5518
[pr]: https://github.com/rust-lang/cargo/pull/5353
Show elapsed time in minutes if >= 60 secs
In large projects with long compile times, seeing "428.65 secs" isn't as clear to humans as seeing the number of minutes (and seconds).
**Old**:
```
Finished dev [unoptimized + debuginfo] target(s) in 2.23 secs
Finished dev [unoptimized + debuginfo] target(s) in 63.94 secs
Finished dev [unoptimized + debuginfo] target(s) in 428.65 secs
```
**New**:
```
Finished dev [unoptimized + debuginfo] target(s) in 2.23s
Finished dev [unoptimized + debuginfo] target(s) in 1m 3.94s
Finished dev [unoptimized + debuginfo] target(s) in 7m 8.65s
```
Note that I also changed `secs` to `s`, because `7 mins 8.65 secs` and `7m 8.65 secs` both look strange IMO. But if you disagree and you'd prefer `secs`, just tell me and I'll change it.
I *didn't* add a check for `secs >= 3600` to print the time in hours. I *hope* this is not necessary...
This fixes an accidental bug introduced in #5300 by ensuring a local map keeps
track of the fact that there can be multiple dependencies for one name
Closes#5453
Introduction of namespaced features (see #1286)
I think this basically covers all of the plans from #1286, although it still needs a bunch of tests and documentation updates. Submitting this PR to get some early feedback on the direction.
Historically, feature-related flags like `--all-features`,
`--no-default-features` and `--features` operated on the *current*
package. That is, `cargo --package foo --feature feat` would activate
`feat` for the package at the current working directory, and not for the
`foo` package. `-Z package-features` flag implements the more obvious
semantics for this combination of flags. This changes behavior, and that
is why we want to start with an unstable opt-in. The changes are:
* `--feature` flag affects the selected package. It is an error to
specify `--feature` with more than a single `-p`, or with `-p` outside
workspace (the latter could work in theory, but would be hard to
implement).
* `--all-features` and `--no-default-features` affect all selected
packages, and not the one at cwd.
* The package in `cwd` is not implicitly enabled when doing feature
selection. That is, `cargo build -Z package-features -p foo` could
select *less* features for various packages than `cargo build -p foo`.
needs a test where we have an activation_error the then try activate something that dose not work and backtrack to where we had the activation_error then:
- Hit fast backtracking that go past the crate with the missing features
- Or give a bad error message that does not mention the activation_error.
The test will pass, but there is code that is not yet justified by tests
