* 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
Import `cargo fix` directly in to Cargo
This commit imports the `cargo fix` subcommand in rust-lang-nursery/rustfix
directly into Cargo as a subcommand. This should allow us to ease our
distribution story of `cargo fix` as we prepare for the upcoming 2018 edition
release.
It's been attempted here to make the code as idiomatic as possible for Cargo's
own codebase. Additionally all tests from cargo-fix were imported into Cargo's
test suite as well. After this lands and is published in nightly the `cargo-fix`
command in rust-lang-nursery/rustfix will likely be removed.
cc rust-lang/rust#52272
This commit imports the `cargo fix` subcommand in rust-lang-nursery/rustfix
directly into Cargo as a subcommand. This should allow us to ease our
distribution story of `cargo fix` as we prepare for the upcoming 2018 edition
release.
It's been attempted here to make the code as idiomatic as possible for Cargo's
own codebase. Additionally all tests from cargo-fix were imported into Cargo's
test suite as well. After this lands and is published in nightly the `cargo-fix`
command in rust-lang-nursery/rustfix will likely be removed.
cc rust-lang/rust#52272
most sorts can be unstable
Inspired by [this](94f7058a48/src/bin/cargo/main.rs (L112-L122)) witch was improved in #5691, I did a quick review of `sort`s in the code. Most can be unstable, some can use a `_key` form, and none had unnecessary allocation.
implement default-run option to set default binary for cargo run
The implementation is not pretty but as good as I could make it. The fact that all this logic in `cargo_run` is for diagnosis only and essentially just re-implements the filtering done elsewhere really threw me off.
Fixes#2200
Make index lookup robust to _ vs -, but don't let the user get it wrong.
This does a brute force search thru combinations of hyphen and underscores to allow queries of crates to pass the wrong one.
This is a small first step of fixing #2775
Where is best to add test?
Add document-private-items flag to cargo doc
Add a `--document-private-items` flag to `cargo doc`, that mimics the equivalent `cargo rustdoc -- --document-private-items`. This works by relaying the flag to the underlying rustdoc call.
help: display external subcommand help
When invoking `cargo help <subcommand>`, if the subcommand isn't found, but it *is* an external subcommand, call that subcommand with `--help`.
A test should probably be written for this, but I'm not sure how best to mock an external subcommand.
Some logic which was tweaked around the dependencies of build script targets was
tweaked slightly in a way that causes cargo to stack overflow by accientally
adding a dependency loop. This commit implements one of the strategies discussed
in #5711 to fix this situation.
The problem here is that when calculating the deps of a build script we need the
build scripts of *other* packages, but the exact profile is somewhat difficult
to guess at the moment we're generating our build script unit. To solve this the
dependencies towards other build scripts' executions is added in a different
pass after all other units have been assembled. At this point we should know for
sure that all build script executions are in the dependency graph, and we just
need to add a few more edges.
Closes#5708
Fix the shell_quoting test
r? @alexcrichton
add-on to #5666
- Added `mod shell_quoting;` to testsuite/main.rs, so it actually runs
- fixed bugs in the test
Fix doctests linking too many libs.
Fixes#5650. cc #5435
As part of my recent work on profiles, I introduced some situations where a
library can be compiled multiple times with different settings. Doctests were
greedily grabbing all dependencies for a package, regardless of which target
is was for. This can cause doctests to fail if it links multiple copies of
the same library.
One way to trigger this is `cargo test --release` if you have dependencies, a
build script, and `panic="abort"`. There are other (more obscure) ways to
trigger it with profile overrides.
[needs test] always shell-escape command arguments after failure
cc @joshtriplett
fixes#5665
Removes the `debug_string` method, in favour of always using the
`fmt::Display` impl. `debug_string` didn’t escape the command
arguments, so that’s why we ended up with unescaped arguments after
compilation failed.
Don't merge this yet, because I still want to add a regression test. I don't think there's any tests on shell quoting yet, so I'll probably add a new test file including tests for the "Running <command>" output too. I still have to figure out how to write tests, and don't have the energy to do that tonight 😴
I just wanted to say, by the way, I was pleasantly surprised with how clean the code is in this repo, especially compared to rustc. It made it really easy to find the relevant part of the code and implement these changes.
It is possible to get invalid lockfile after an automatic merge, so it
make sense to print a little bit more details by defaults than just
"failed to parse a lockfile".
skip test if not nightly; fix for #5648closes#5648
The alternative was to use `set_var` to emulate `masquerade_as_nightly_cargo` but we worried that it would not get unset correctly. Although I think each test is its own process, so it should work.
Fix avoiding a rebuild when moving around a workspace
There's a case where Cargo will recompile a project even if the fingerprint
looks like it's fresh, when some output files are missing. This was intended to
cover the case where an output file was deleted manually or otherwise messed
with. The check here was a bit too eager, however. It checked not only the
actual output destination of the compiler but *also* the location that we hard
link the output file up to.
Due to recent changes in #5460 we don't always create the hard links for path
dependencies in the top-level dir, and this meant that if the library were
compiled and then tested later on the test may recompile the original library by
accident.
The fix in this commit is to cease looking for the hardlink if it exists or not.
This way we only check for the presence of the output file itself and only
recompile if that file is missing. The reason for this is that we
unconditionally relink files into place whether it's fresh or not, so we'll
always recreate the hard link anyway if it's missing.
cc rust-lang/rust#51717
There's a case where Cargo will recompile a project even if the fingerprint
looks like it's fresh, when some output files are missing. This was intended to
cover the case where an output file was deleted manually or otherwise messed
with. The check here was a bit too eager, however. It checked not only the
actual output destination of the compiler but *also* the location that we hard
link the output file up to.
Due to recent changes in #5460 we don't always create the hard links for path
dependencies in the top-level dir, and this meant that if the library were
compiled and then tested later on the test may recompile the original library by
accident.
The fix in this commit is to cease looking for the hardlink if it exists or not.
This way we only check for the presence of the output file itself and only
recompile if that file is missing. The reason for this is that we
unconditionally relink files into place whether it's fresh or not, so we'll
always recreate the hard link anyway if it's missing.
cc rust-lang/rust#51717
