bors [Mon, 15 Mar 2021 16:58:26 +0000 (16:58 +0000)]
Auto merge of #9204 - jonhoo:patch-in-config, r=alexcrichton
Support [patch] in .cargo/config files
This patch adds support for `[patch]` sections in `.cargo/config.toml`
files. Patches from config files defer to `[patch]` in `Cargo.toml` if
both provide a patch for the same crate.
The current implementation merge config patches into the workspace
manifest patches. It's unclear if that's the right long-term plan, or
whether these patches should be stored separately (though likely still
in the manifest). Regardless, they _should_ likely continue to be
parsed when the manifest is parsed so that errors and such occur in the
same place regardless of where a patch is specified.
bors [Sun, 14 Mar 2021 23:15:17 +0000 (23:15 +0000)]
Auto merge of #9262 - Matt-Gleich:master, r=Eh2406
🍱 Crop favicon
Hello! At first glance I found doc.rust-lang.org/cargo's favicon to be a bit small compared to other site's favicons. Looked into it and found that the logo hasn't been cropped. All I did was crop the favicon in this PR. As you can see from the image below (new favicon on the right) it looks much better:
bors [Sat, 13 Mar 2021 01:18:40 +0000 (01:18 +0000)]
Auto merge of #9252 - ehuss:prefer-dynamic-ws, r=alexcrichton
Fix logic for determining prefer-dynamic for a dylib.
The logic for determining if a dylib should use `prefer-dynamic` used to be something like "do not use prefer-dynamic if it is the current package".
The current logic has a strange behavior where it works as intended if there is only one package in the workspace, but a workspace with multiple packages will always use `prefer-dynamic`.
Instead of using `current_opt`, which isn't a good concept to use in a workspace, I switched this to be "primary" (a package selected on the command-line).
**History**
* 9879a0a5f621a4ae44b2d9dc62a0175404c05f8f Initial prefer-dynamic behavior.
* #3221 changed to the faulty logic (see comments at https://github.com/rust-lang/cargo/pull/3221#discussion_r88535221). I think there was some confusion there.
* #3478 fixed the logic for one of the changed conditions, but not the one for prefer-dynamic
bors [Thu, 11 Mar 2021 19:57:49 +0000 (19:57 +0000)]
Auto merge of #9255 - ehuss:fix-deps-filtering, r=Eh2406
Fix issue with filtering exclusive target dependencies.
#8777 incorrectly changed the filtering logic for dependencies. Essentially it split `filter(any(A && B && C && D))` into two parts `filter(any(A && B)).filter(any(C && D))` which doesn't have the same meaning. The solution here is to pass a closure so that the conditions are joined again.
bors [Wed, 10 Mar 2021 15:22:00 +0000 (15:22 +0000)]
Auto merge of #9249 - ehuss:doc-pkgid-spec, r=alexcrichton
Update pkgid-spec docs.
The old docs for the pkgid spec weren't correct. Specs never supported abbreviated URLs or aliases for the index (like `crates.io`). This tries to correct that and add a little more detail.
bors [Tue, 9 Mar 2021 22:46:30 +0000 (22:46 +0000)]
Auto merge of #9233 - alexcrichton:reword-edition, r=ehuss
Wordsmith the edition documentation a bit more
This hopes to clear up a few recent PRs about the `edition` key in the
manifest. It shuffles things around so the defaults are talked about in
two different paragraphs. The first one talks about how `cargo new` uses
the 2018 edition and is the only paragraph to use the word "default".
The second section talks about the usage of 2015 with no `edition` field
present.
This didn't end up being quite as clear as I hoped it might be, but I'm
hoping that this provides a bit more emphasis or otherwise just
restructures things a bit to be more clear.
Not sure which commit breaks this. Cargo shipped with rust 1.46 didn't unwrap on a `None` but 1.47 did. Even checkouted to 149022b1d8f382e69c1616f6a46b69ebf59e2dea (cargo of rust 1.46), it still unwrap unexpectedly.
So I ended up following the [Specification grammer](https://doc.rust-lang.org/cargo/reference/pkgid-spec.html#specification-grammar) to make sure there is a `host` in the pkgid urls.
$ cargo +1.47 pkgid /path
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src/tools/cargo/src/cargo/core/package_id_spec.rs:234:50
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
bors [Mon, 8 Mar 2021 16:10:17 +0000 (16:10 +0000)]
Auto merge of #9246 - ehuss:fix-filter_platform, r=Eh2406
Fix filter_platform to run on targets other than x86.
The issue is that the `dependencies` array was hard-coded to be sorted by `[none, 'cfg(foobar)', 'wasm32-unknown-unknown', host_target]` where `host_target` is usually a target that starts with "x". However, running the test on a target that sorts less than `wasm32` causes the test to fail (such as `aarch64`). The order of arrays used to be ignored until #8489. The solution here is to just sort the expected order of dependencies. An alternate solution would be to extend `with_json` with more options on comparison (such as ignoring array order), but this seems simple enough.
bors [Fri, 5 Mar 2021 22:07:23 +0000 (22:07 +0000)]
Auto merge of #8825 - Aaron1011:feature/report-future-incompat, r=ehuss
Implement future incompatibility report support
cc rust-lang/rust#71249
This implements the Cargo side of 'Cargo report future-incompat'
Based on feedback from alexcrichton and est31, I'm implemented this a
flag `--future-compat-report` on `cargo check/build/rustc`, rather than
a separate `cargo describe-future-incompatibilities` command. This
allows us to avoid writing additional information to disk (beyond the
pre-existing recording of rustc command outputs).
This PR contains:
* Gating of all functionality behind `-Z report-future-incompat`.
Without this flag, all user output is unchanged.
* Passing `-Z emit-future-incompat-report` to rustc when
`-Z report-future-incompat` is enabled
* Parsing the rustc JSON future incompat report, and displaying it
it a user-readable format.
* Emitting a warning at the end of a build if any crates had
future-incompat reports
* A `--future-incompat-report` flag, which shows the full report for
each affected crate.
* Tests for all of the above.
At the moment, we can use the `array_into_iter` to write a test.
However, we might eventually get to a point where rustc is not currently
emitting future-incompat reports for any lints. What would we want the
cargo tests to do in this situation?
This functionality didn't require any significant internal changes to
Cargo, with one exception: we now process captured command output for
all units, not just ones where we want to display warnings. This may
result in a slightly longer time to run `cargo build/check/rustc` from
a full cache. since we do slightly more work for each upstream
dependency. Doing this seems unavoidable with the current architecture,
since we need to process captured command outputs to detect
any future-incompat-report messages that were emitted.
Aaron Hill [Thu, 29 Oct 2020 21:48:09 +0000 (17:48 -0400)]
Implement future incompatibility report support
cc rust-lang/rust#71249
This implements the Cargo side of 'Cargo report future-incompat'
Based on feedback from alexcrichton and est31, I'm implemented this a
flag `--future-compat-report` on `cargo check/build/rustc`, rather than
a separate `cargo describe-future-incompatibilities` command. This
allows us to avoid writing additional information to disk (beyond the
pre-existing recording of rustc command outputs).
This PR contains:
* Gating of all functionality behind `-Z report-future-incompat`.
Without this flag, all user output is unchanged.
* Passing `-Z emit-future-incompat-report` to rustc when
`-Z report-future-incompat` is enabled
* Parsing the rustc JSON future incompat report, and displaying it
it a user-readable format.
* Emitting a warning at the end of a build if any crates had
future-incompat reports
* A `--future-incompat-report` flag, which shows the full report for
each affected crate.
* Tests for all of the above.
At the moment, we can use the `array_into_iter` to write a test.
However, we might eventually get to a point where rustc is not currently
emitting future-incompat reports for any lints. What would we want the
cargo tests to do in this situation?
This functionality didn't require any significant internal changes to
Cargo, with one exception: we now process captured command output for
all units, not just ones where we want to display warnings. This may
result in a slightly longer time to run `cargo build/check/rustc` from
a full cache. since we do slightly more work for each upstream
dependency. Doing this seems unavoidable with the current architecture,
since we need to process captured command outputs to detect
any future-incompat-report messages that were emitted.
bors [Thu, 4 Mar 2021 19:50:20 +0000 (19:50 +0000)]
Auto merge of #9022 - nagisa:nagisa/manifest_path, r=alexcrichton
Add the path to the manifest in json output
This allows consumers of the json messages to avoid guessing where
exactly the package root is. Having access to the package root is
difficult by virtue of requiring logic to guess its location by e.g.
walking filesystem from the source file.
This guessing logic becomes further complicated in presence of
workspaces and nigh impossible to implement correctly in instances where
artifacts end up produced from paths above the package root (e.g.
`../foo.rs`).
Since Cargo has access to this data in the first place, there doesn't
seem to be much reason to force consumers to invent their own, possibly
flawed, logic.
This allows consumers of the json messages to avoid guessing where
exactly the package root is. Having access to the package root is
difficult by virtue of requiring logic to guess its location by e.g.
walking filesystem from the source file.
This guessing logic becomes further complicated in presence of
workspaces and nigh impossible to implement correctly in instances where
artifacts end up produced from paths above the package root (e.g.
`../foo.rs`).
Since Cargo has access to this data in the first place, there doesn't
seem to be much reason to force consumers to invent their own, possibly
flawed, logic.
bors [Thu, 4 Mar 2021 18:01:51 +0000 (18:01 +0000)]
Auto merge of #9230 - kornelski:nobinaries, r=alexcrichton
Explain `cargo install` is not for libraries
On a few occasions I've seen novice users assume that `cargo install` works like `npm install` or `apt install`, and they're confused that they can't use library dependencies this way.
I've expanded the error message to hopefully clarify the misconception.
bors [Wed, 3 Mar 2021 15:15:41 +0000 (15:15 +0000)]
Auto merge of #9231 - joshtriplett:clear-to-eol-if-color, r=alexcrichton
Use ANSI clear-to-EOL if color is force-enabled
When running cargo with output not going to a TTY, and with the progress
bar and color force-enabled, this makes cargo clean up its right-aligned
output properly.
This doesn't fix the case where progress is force-enabled and color
isn't, but it fixes the case where both are force-enabled.
bors [Wed, 3 Mar 2021 03:19:33 +0000 (03:19 +0000)]
Auto merge of #9181 - jyn514:computer-says-no, r=ehuss
Forbid setting `RUSTC_BOOTSTRAP` from a build script on stable
Instead, recommend `RUSTC_BOOTSTRAP=crate_name`. If cargo is using a nightly toolchain, or if RUSTC_BOOTSTRAP was set in *cargo*'s build environment, the error is downgraded to a warning, since the variable won't affect the build.
This is mostly the same as suggested in https://github.com/rust-lang/cargo/issues/7088#issuecomment-713867773, except that `RUSTC_BOOTSTRAP=` values other than 1 are treated the same as `RUSTC_BOOTSTRAP=1`. My reasoning was that https://github.com/rust-lang/rust/pull/77802 is now on 1.50 stable, so some crates may have started using it, and I would still prefer not to give hard errors when there's no workaround.
Alex Crichton [Tue, 2 Mar 2021 22:05:06 +0000 (14:05 -0800)]
Wordsmith the edition documentation a bit more
This hopes to clear up a few recent PRs about the `edition` key in the
manifest. It shuffles things around so the defaults are talked about in
two different paragraphs. The first one talks about how `cargo new` uses
the 2018 edition and is the only paragraph to use the word "default".
The second section talks about the usage of 2015 with no `edition` field
present.
This didn't end up being quite as clear as I hoped it might be, but I'm
hoping that this provides a bit more emphasis or otherwise just
restructures things a bit to be more clear.
Josh Triplett [Tue, 2 Mar 2021 21:31:23 +0000 (13:31 -0800)]
Use ANSI clear-to-EOL if color is force-enabled
When running cargo with output not going to a TTY, and with the progress
bar and color force-enabled, this makes cargo clean up its right-aligned
output properly.
This doesn't fix the case where progress is force-enabled and color
isn't, but it fixes the case where both are force-enabled.
bors [Tue, 2 Mar 2021 18:26:29 +0000 (18:26 +0000)]
Auto merge of #9226 - matklad:utf8everywhere, r=alexcrichton
Don't panic when printing JSON with non-utf8 paths
Before:
λ cd \Xff/foo/ && cargo verify-project && cargo metadata
{"success":"true"}
warning: please specify `--format-version` flag explicitly to avoid compatibility problems
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error("path contains invalid UTF-8 characters", line: 0, column: 0)', /rustc/a5a775e3f9e8043dad405e00aee0ae60882a7b71/src/tools/cargo/src/cargo/core/shell.rs:346:51
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
After:
λ cd \Xff/foo/ && $cargo verify-project && $cargo metadata
{"success":"true"}
warning: please specify `--format-version` flag explicitly to avoid compatibility problems
error: path contains invalid UTF-8 characters
I am pretty sure that this has zero real-world impact, but the diff is
small, so why not handle it?
Aleksey Kladov [Tue, 2 Mar 2021 07:41:57 +0000 (10:41 +0300)]
Don't panic when printing JSON with non-utf8 paths
Before:
λ cd \Xff/foo/ && cargo verify-project && cargo metadata
{"success":"true"}
warning: please specify `--format-version` flag explicitly to avoid compatibility problems
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error("path contains invalid UTF-8 characters", line: 0, column: 0)', /rustc/a5a775e3f9e8043dad405e00aee0ae60882a7b71/src/tools/cargo/src/cargo/core/shell.rs:346:51
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
After:
λ cd \Xff/foo/ && $cargo verify-project && $cargo metadata
{"success":"true"}
warning: please specify `--format-version` flag explicitly to avoid compatibility problems
error: path contains invalid UTF-8 characters
I am pretty sure that this has zero real-world impact, but the diff is
small, so why not handle it?
bors [Tue, 2 Mar 2021 15:40:54 +0000 (15:40 +0000)]
Auto merge of #9223 - ehuss:fingerprint-target, r=alexcrichton
Detect changes for JSON spec targets.
This adds the contents of a JSON spec target file to the fingerprint hash so that changing the contents will trigger a rebuild. This also deals with the target info cache in a similar fashion.
bors [Tue, 2 Mar 2021 15:13:11 +0000 (15:13 +0000)]
Auto merge of #9225 - ehuss:fix-target-dir-env-test, r=alexcrichton
Fix `cargo_target_empty_cfg` test with env var.
The test `cargo_target_empty_cfg` does not work if the environment variable `CARGO_TARGET_DIR` is set. `Config` should not be looking at the "real" environment, but instead `self.env` which is controlled during tests.
bors [Mon, 1 Mar 2021 15:13:36 +0000 (15:13 +0000)]
Auto merge of #9213 - ehuss:registry-api-errors, r=alexcrichton
Minor update to registry API error messages.
This is a minor update to the registry API errors, trying to make them a little clearer and more helpful. My concerns were:
* `api errors (status 200 OK): some error message` — why was there both an error and 200 OK?
* `api errors` — What is an "api error" anyways? The user is probably not familiar with the "registry API".
* Adds the URL of the server it is actually talking to, in case you may be confused when using a registry other than crates.io. This also tries to make it clearer that the message is coming from the remote server, and not cargo itself.
bors [Thu, 25 Feb 2021 19:06:49 +0000 (19:06 +0000)]
Auto merge of #9207 - ehuss:testsuite-splitdebug, r=Eh2406
testsuite: Use split debuginfo on macos.
This switches the testsuite to use "unpacked" debuginfo on macos, which is a substantial performance boost. On my system, the testsuite runs 1.55 times faster with this change. Along with #9206, total testsuite time is 3.1 times faster.
bors [Thu, 25 Feb 2021 17:24:58 +0000 (17:24 +0000)]
Auto merge of #9206 - ehuss:testsuite-rustup, r=Eh2406
testsuite: Improve performance when using rustup.
The rustup wrapper adds a considerable amount of overhead when running processes like `rustc`. This overrides `PATH` when running the testsuite to prioritize the actual executables to avoid the wrapper.
I'm not 100% confident this won't break something somewhere, but it seems like it should be safe.
In my tests, this makes the testsuite 1.5 to 1.7 times faster.
Jon Gjengset [Wed, 24 Feb 2021 22:14:43 +0000 (14:14 -0800)]
Support [patch] in .cargo/config files
This patch adds support for `[patch]` sections in `.cargo/config.toml`
files. Patches from config files defer to `[patch]` in `Cargo.toml` if
both provide a patch for the same crate.
The current implementation merge config patches into the workspace
manifest patches. It's unclear if that's the right long-term plan, or
whether these patches should be stored separately (though likely still
in the manifest). Regardless, they _should_ likely continue to be
parsed when the manifest is parsed so that errors and such occur in the
same place regardless of where a patch is specified.
Joshua Nelson [Wed, 24 Feb 2021 19:35:51 +0000 (14:35 -0500)]
Make `nightly_features_allowed` a field instead of a function
`nightly_features_allowed()` is no longer doing any work, so it can be
accessed directly. This also renames the `enable_nightly_features` field
to `nightly_features_allowed`.
Joshua Nelson [Thu, 18 Feb 2021 18:46:31 +0000 (13:46 -0500)]
Fix `masquerade_as_nightly_cargo` in work threads
Previously, since `ENABLE_NIGHTLY_FEATURES` and
`NIGHTLY_FEATURES_ENABLED` were thread locals, reading them in any other
thread would always say nightly features were disabled. Now, they are
tied to the `Context` itself, so it is both more clear how the variables
are being set and fixes the behavior within work threads.
Note that `Context` is not thread-safe, so this passes a boolean through
to `BuildOutput::parse`.
Joshua Nelson [Wed, 17 Feb 2021 17:37:01 +0000 (12:37 -0500)]
Suggest RUSTC_BOOTSTRAP=crate instead of RUSTC_BOOTSTRAP=1
This was the whole point of https://github.com/rust-lang/rust/pull/77802.
- Pass `pkg.name()` to `parse()`. This can't pass the `Package` directly
because `PackageInner` is an `Rc` and therefore not thread-safe. Note
that `pkg_name` was previously a *description* of the package, not the
name passed with `--crate-name`.
bors [Wed, 24 Feb 2021 16:51:20 +0000 (16:51 +0000)]
Auto merge of #9128 - poliorcetics:respect-shortness-rustdoc, r=ehuss
Pass the error message format to rustdoc
- Goes with rust-lang/rust#81675.
- Will help with rust-lang/rust#81662.
This is my first PR to Cargo and I haven't finished reading the contributor guide yet, how should I add tests for this ? Did I had the code in the correct place ?
bors [Wed, 24 Feb 2021 15:19:55 +0000 (15:19 +0000)]
Auto merge of #9203 - ehuss:fix-target_in_environment_contains_lower_case, r=alexcrichton
Fix test target_in_environment_contains_lower_case
This test will fail if you actually have the x86_64-unknown-linux-musl target installed. Instead of assuming it will fail, this uses the host target instead, which should only fail on windows due to case-insensitive environment keys.
bors [Wed, 24 Feb 2021 04:40:06 +0000 (04:40 +0000)]
Auto merge of #9201 - ehuss:close-error-during-drain, r=Eh2406
Fix hang on broken stderr.
If stderr is closed and cargo tries to print a status message such as "Compiling", cargo can get into a hung state. This is because the `DrainState::run` function would insert the job into the `active` queue, and then return an error without starting the job. Since the job isn't started, there is nothing to remove it from the `active` queue, and thus cargo hangs forever waiting for it to finish.
The solution is to move the call to `note_working_on` earlier before the job is placed into the active queue.
This addresses the issue noted in https://github.com/rust-lang/cargo/issues/8714#issuecomment-783787163.
bors [Wed, 24 Feb 2021 03:59:28 +0000 (03:59 +0000)]
Auto merge of #9195 - guswynn:test_name, r=ehuss
Make it more clear which module is being tested when running cargo test
I recently asked in zulip if this is a good idea, as I find it hard to find the module thats being tested from the complex path with the hash.
Output of `cargo test`:
```
2021-02-21 13:29:33 I > ~/repos/cargo/target/debug/cargo test
Finished test [unoptimized + debuginfo] target(s) in 0.42s
Running unittests (target/debug/deps/test_tests-759130ea61f71571)
running 1 test
test tests::unit_test ... ok
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in
0.00s