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.
Added tests for the environment variable RUSTC_LINKER that is
passed to the build script.
Also slightly improved readability of the code responsible for
passing the env var.
In Rust 2015 absence of the configuration makes it default to not
include auto-discovered targets (i.e false), with a warnings message.
In Rust 2018 absence makes it default to include auto-discovered
targets (i.e true).
Fixes#5330
Print "Checking" for cargo check
I often alternate between `check` and `build` and I'd like to be able to tell which is currently happening (short-term memory being what it is, and "compiling" implying to me that codegen is occurring). Changing the message to "Checking" seemed to be reasonable (and there was precedent for `doc` with "Documenting").
Enable new behavior of `--feature`
So far, the feedback on https://internals.rust-lang.org/t/help-us-test-the-breaking-bug-fix-to-cargo-features/7317 has been positive, so here's a PR to try this in nightly.
Note that the logic is slightly tweak for the case `cargo build -p not-a-workspace-member`: we want not only to resolve all ws members in this case, but to enable all of their features as well!
As a sanity check, this seems to be forward compatible with further improvements to features:
1) when we solve the grand bug of features being unified across the whole workspace, `cargo build -p not-a-member` would hopefully just work without additional contortions.
2) we might add a way to specify features per package, like `cargo build -p foo -p bar --features "foo/serde bar/serde"`
cargotest: Fix `with_*_does_not_contain` to support `[..]` and macro matching.
I changed it so that it is essentially the opposite of `with_*_contains` to keep it symmetric.
Any in-flight PRs using the old style will need to be updated (else they will incorrectly silently pass). Alternatively, we could rename the method to avoid that.
The following tests contained brackets, so they were not checking what they thought they were checking. I did a cursory look at them, but perhaps someone else could double-check that they make sense. Asserting what *doesn't* happen can be tricky since there is an infinite number of things that won't happen. Preferably a test would assert that it appears in one scenario and not another (like `incremental_profile` does), but some of them don't or can't.
```
build::incremental_profile
build::incremental_config
build::cargo_compile_with_workspace_excluded
build::build_all_exclude
build::targets_selected_default
check::targets_selected_default
check::check_filters
rustc::targets_selected_default
rustc_info_cache::rustc_info_cache
warn_on_failure::no_warning_on_bin_failure
warn_on_failure::warning_on_lib_failure
```
BTW, would you be interested in a PR that adds some documentation to `cargotest`?
I've discovered things I didn't know where there. I think some docstrings on some of the methods, and a short guide for new contributors would be helpful.
Rustc cache
This implements rustc caching, to speed-up no-op builds.
The cache is per-project, and stored in `target` directory. To implement this, I had to move `rustc` from `Config` down to `BuildConfig`.
closes https://github.com/rust-lang/cargo/issues/5315
