Set an environment variable for tests to find executables.
This adds the environment variable `CARGO_BIN_EXE_<name>` so that integration tests can find binaries to execute, instead of doing things like inspecting `env::current_exe()`.
The use of uppercase is primarily motivated by Windows whose Rust implementation behaves in a strange way. It always ascii-upper-cases keys to implement case-insensitive matching (which loses the original case). Seems less likely to result in confusion?
Closes#5758.
Fix BuildScriptOutput when a build script is run multiple times.
When I implemented profile build overrides, I created a scenario where a build script could run more than once for different scenarios. See the test for an example.
However, the `BuildScriptOutputs` map did not take this into consideration. This caused multiple build script runs to stomp on the output of previous runs. This is further exacerbated by the new feature resolver in #7820 where build scripts can run with different features enabled.
The solution is to make the map key unique for the Unit it is running for. Since this map must be updated on different threads, `Unit` cannot be used as a key, so I chose just using the metadata hash which is hopefully unique. Most of this patch is involved with the fussiness of getting the correct metadata hash (we want the RunCustomBuild unit's hash). I also added some checks to avoid collisions and assert assumptions.
Format placeholder code when generating a crate
When generating source files in `cargo new` and `cargo init`, try to run `rustfmt` CLI on them.
If it fails, log the error and proceed.
Tests:
* Works for `cargo init --lib`
* No changes in behavior if `rustfmt` is missing
Closes#7656
Generalized `clippy_is_available` and renamed as `command_is_available`.
No checks in `ignores_failure_to_format_source`, it's not supposed to
use `rustfmt` even if it's available
Fix rebuild_sub_package_then_while_package on HFS.
This test was flaky on HFS ([azure failure](https://dev.azure.com/rust-lang/cargo/_build/results?buildId=20144&view=logs&j=a5e52b91-c83f-5429-4a68-c246fc63a4f7&t=d4864165-4be3-5e34-b483-a6b05303aa68&l=2018)), resulting in this error:
```
Compiling foo v0.0.1 (/Users/runner/runners/2.164.7/work/1/s/target/cit/t750/foo)
error[E0460]: found possibly newer version of crate `b` which `a` depends on
--> src/lib.rs:1:1
|
1 | extern crate a; extern crate b; pub fn toplevel() {}
| ^^^^^^^^^^^^^^^
|
= note: perhaps that crate needs to be recompiled?
= note: the following crate versions were found:
crate `b`: /Users/runner/runners/2.164.7/work/1/s/target/cit/t750/foo/target/debug/deps/libb-98160c67a5811c37.rlib
crate `b`: /Users/runner/runners/2.164.7/work/1/s/target/cit/t750/foo/target/debug/deps/libb-98160c67a5811c37.rmeta
crate `a`: /Users/runner/runners/2.164.7/work/1/s/target/cit/t750/foo/target/debug/deps/liba-7d2b9ccd932a36e9.rmeta
```
There are two race-condition bugs here.
Race 1: The second cargo build command (`cargo build -pb`) would sometimes not build, because it thought `b` is fresh. This can happen when the first build finishes and changing `b/src/lib.rs` happen within the same second. (#5918) The test silently ignored this failure, this is not the cause of the CI failure, though.
Race 2: The first and second build commands work as expected. The third build command fails because it thinks both `a` and `b` are "fresh". However, `b` was just rebuilt, and `a` depends on it, so `a` should have been rebuilt. It thinks `a` is fresh because `a`'s mtime is equal to `b` when `b` finishes compiling within the same second that the first build finished.
The solution here is to make sure the second step happens well after the first. The underlying problem is #5918.
Fix using global options before an alias.
Options before an alias were being ignored (like `cargo -v b`). The solution is to extract those global options before expanding an alias, and then merging it later.
An alternative to this is to try to avoid discarding the options during expansion, but I couldn't figure out a way to get the position of the subcommand in the argument list. Clap only provides a way to get the arguments *following* the subcommand.
I also cleaned up some of the code in `Config::configure`, which was carrying some weird baggage from previous refactorings.
Fixes#7834
Stabilize config-profile.
This is a proposal to stabilize config-profiles. This feature was proposed in [RFC 2282](https://github.com/rust-lang/rfcs/pull/2282) and implemented in #5506. Tracking issue is rust-lang/rust#48683.
This is intended to land in 1.43 which will reach the stable channel on April 23rd.
This is a fairly straightforward extension of profiles where the exact same syntax from `Cargo.toml` can be specified in a config file. Environment variables are supported for everything except the `package` override table, where we do not support the ability to read arbitrary keys in the environment name.
Search for root manifest with ephemeral workspaces
Fixes#5495.
This seems like it's too simple to just work like this, but after trying a few different things, this was the only solution which worked reliably for me.
I've verified that no `/target` is present in the actual checkout location, the target directory used is actually the one created in `/tmp`.
I've also verified that both workspaces and "normal" packages still install through git and that a normal `cargo install --path` works too (though that doesn't use ephemeral workspaces anyways).
Test 1: init a library crate with a `rustfmt.toml` config file in it.
Expect the generated source files to be formatted according to the
config file.
Test 2: same as test 1, but with missing `rustfmt`. Expect `cargo init`
to ignore the absence of `rustfmt` and generate source files
with default formatting.
Add tests for `cargo owner -a/-r` / `cargo yank --undo`
Follow up 5e15286.
There were no tests for `cargo owner -a/-r` and `cargo yank --undo`. However, These commands in tests had empty response. So I also update response handling with reference to 7dd0f932a8.
Load credentials only when needed
Credentials are always loaded, even if these are not used. If
access to confidential files such as credentials is not given,
`cargo build` fails despite not using credentials.
Fixes#7624.
There's an existing bug (#7782) in Cargo which exacerbates the issue
here but in general having a stack of errors is a bit easier to read and
work with than having a big long error message.
Fix .gitignore of Cargo.lock in a subdirectory.
The code for checking if `Cargo.lock` is ignored was erroneously assuming it was at the root of the git repo. This would cause a problem if `Cargo.lock` is in `.gitignore` in a subdirectory.
Fixes issue noted in https://github.com/rust-lang/cargo/issues/7705#issuecomment-572027382
The `anyhow` crate interoperates with the `std::error::Error` trait
rather than a custom `Fail` trait, and this is the general trend of
error handling in Rust as well.
Note that this is mostly mechanical (sed) and intended to get the test
suite passing. As usual there's still more idiomatic cleanup that can
happen, but that's left to later commits.
Credentials are always loaded, even if these are not used. If
access to confidential files such as credentials is not given,
`cargo build` fails despite not using credentials.
Fixes#7624.
Fix CARGO_TARGET_triple_LINKER environment variable.
#7649 caused an unfortunate regression where the `CARGO_TARGET_triple_LINKER` environment variable stopped working. I did not realize `serde(flatten)` caused serde to switch to `deserialize_map` which does not support environment variables.
The solution here is to essentially revert back to how the `[target]` table used to be loaded by loading each key individually.
This also removes the `ar` field which is not used by `rustc`.
Remove metadata dep_kinds duplicates.
In `cargo metadata`, an entry could appear multiple times in the `dep_kinds` array if it is used by multiple workspace members with different features activated. This fixes it by de-duplicating the entries.
This is kinda related to `cargo metadata` not handling workspaces and features very well. But workspaces and features are a bit awkward overall.
Fixes#7752
