Previously, `execute_subcommand` was called recursively, and each call
would `.configure` the `config` again. It worked, but seemed rather
fragile.
This commit handles aliases more explicitly, ensures that `.configure`
is called once and, as a bonus, adds a warning for when an alias is
shadowed by the built in.
Partially revert change to testing examples.
Fixes#5437
I don't think changing the behavior was quite the correct thing to do. This new behavior is very similar to the old with a few small differences:
```
cargo test
ORGINAL: Only builds examples.
NEW: Builds all examples. Any example with `test` set is tested.
cargo test --tests
ORIGINAL: Runs all examples as tests.
NEW: Only runs examples as tests if `test` is set.
cargo test --examples
ORIGINAL: Runs all examples as tests.
NEW: (SAME)
cargo test --example foo
ORIGINAL: Runs the given example as a test.
NEW: (SAME)
cargo test --all-targets
ORIGINAL: Runs all examples as tests.
NEW: (SAME)
```
Fixes#5437
I don't think changing the behavior was quite the correct thing to do. This new behavior is very similar to the old with a few small differences:
```
cargo test
ORGINAL: Only builds examples.
NEW: Builds all examples. Any example with `test` set is tested.
cargo test --tests
ORIGINAL: Runs all examples as tests.
NEW: Only runs examples as tests if `test` is set.
cargo test --examples
ORIGINAL: Runs all examples as tests.
NEW: (SAME)
cargo test --example foo
ORIGINAL: Runs the given example as a test.
NEW: (SAME)
cargo test --all-targets
ORIGINAL: Runs all examples as tests.
NEW: (SAME)
```
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...
Track panic mode in fingerprint
Ensure that if we've previously compiled a crate with panic=abort and we later
need it for panic=unwind we correctly recompile it.
Closes#5445
Fix optional dependencies and required dev-deps
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
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.
Revert "Enable new behavior of `--feature`"
This reverts commit 038eec5cb3bd25a0855b0be6ad2aeba5391c6c6e.
As discussed at https://github.com/rust-lang/cargo/issues/5364, the new behavior unfortunately causes real-life breakage, so we have to revert it.
This is kinda sad, this is a part of the larger issue with feature selection, which, at the moment, has a behavior which I would classify (loosely speaking) as unsound:
* `cargo build -p foo` and `cargo build -p foo -p bar` might produce different artifacts for `foo` ([repro](https://github.com/matklad/workspace-vs-feaures))
* `cargo build -p foo` might produce different artifacts, depending on cwd ([repro](https://github.com/matklad/features-cwd))
The new feature behavior specifically addressed the second point.
It is unclear what we could do with this... One option, instead of flatly erroring out, as the revreted commit does, is to print a warning, but change the set of activated features. It will still be a breaking change, but it at least has a chance of working by accident.
r? @alexcrichton
Previously there was a verification in manifest parsing that the same dependency
must come from the same source, but this erroneously triggered an error to get
emitted when the `package` key was used to rename crates. The first change here
was to update that clause to key off the `rename` field rather than the `name`
field.
Afterwards, though, this exposed an existing bug in the implementation. During
compilation we have a `Resolve` which is a graph of crates, but we don't know
*why* each edge in the dependency graph exists. In other words we don't know,
when looking at an edge of the graph, what `Dependency` caused that edge to be
drawn. We need to know this when passing `--extern` flags because the
`Dependency` is what lists what's being renamed.
This commit then primarily refactors `Resolve::deps` from an iterator of package
ids to an iterator of a tuples. The first element is the package id from before
and the second element is a list of `Dependency` directives which caused the
edge to ber driven.
This refactoring cleaned up a few places in the backend where we had to work
around the lack of this knowledge. Namely this also fixes the extra test added
here.
Closes#5413
cargo-fetch: add option to fetch for a target
Teach cargo-fetch how to optionally fetch dependencies based on a target
platform by specifying the target triple via `--target <TRIPLE>`.
#5216
Teach cargo-fetch how to optionally fetch dependencies based on a target
platform by specifying the target triple via `--target <TRIPLE>`.
Signed-off-by: Brandon Williams <bmwill@google.com>
Pass linker path to build script
This change adds the environment variable LINKER to pass the path of the linker used by cargo to the build script. This complements the variable RUSTC (the rustc binary used) to give the build script full knowledge of its environment.
A specific usage example would be automatically generating bindings to system headers in cross compilation, e.g. by locating jni.h for android targets.
