Allow `cargo update` to operate with the --offline flag
Closes#9248
Limiting to `--precise` operations as the package should be cached locally prior to the usage of offline.
Added an additional test to [offline.rs](tests/testsuite/offline.rs).
Add report if `cargo fix --edition` changes features.
This adds a small report if using `cargo fix --edition` to transition from 2018 to 2021 to determine if the new resolver will result in different features.
There is a gauntlet of checks that must pass before it even tries to show the differences:
* If the resolver is already specified, skip.
* If in a virtual workspace, skip (no way to specify global edition).
* If not migrating the root package, skip. The edition only changes the resolver in the root package.
* If not migrating all targets, skip. It's uncertain if the user intends to set the package edition or not.
Closes#9048
Fix --feature pkg/feat for V1 resolver for non-member.
#8997 had an unintended regression where `-p foo --feature foo/feat` syntax where `foo` is an **optional non-member** fails with an error that `foo` did not match any packages. The issue is that the member/feature selection routine needed to slot this into the features for the package in the current working directory (it was incorrectly treating `foo` as a workspace member).
V2 outright does not allow specifying features for non-workspace members.
Fixes#9265
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.
Fixes#5539.
Package ID specification urls must contain a host
Resolves https://github.com/rust-lang/cargo/issues/9041
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.
<details>
<summary>See console output</summary>
cargo of rust 1.46
```console
$ cargo +1.46 -vV
cargo 1.46.0 (149022b1d 2020-07-17)
release: 1.46.0
commit-hash: 149022b1d8f382e69c1616f6a46b69ebf59e2dea
commit-date: 2020-07-17
$ cargo +1.46 pkgid /path
error: package ID specification `/path` matched no packages
```
cargo of rust 1.47
```console
$ cargo +1.47 -vV
cargo 1.47.0 (f3c7e066a 2020-08-28)
release: 1.47.0
commit-hash: f3c7e066ad66e05439cf8eab165a2de580b41aaf
commit-date: 2020-08-28
$ 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
```
cargo on commit 149022b1d8f382e69c1616f6a46b69ebf59e2dea
```console
$ git checkout 149022b1d8f382e69c1616f6a46b69ebf59e2dea
$ cargo run -- pkgid /path
Compiling cargo-platform v0.1.1 ([..]/cargo/crates/cargo-platform)
Compiling crates-io v0.31.1 ([..]/cargo/crates/crates-io)
Compiling cargo v0.47.0 ([..]/cargo)
Finished dev [unoptimized + debuginfo] target(s) in 22.90s
Running `target/debug/cargo pkgid /path`
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src/cargo/core/package_id_spec.rs:234:50
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
</details>
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.
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.
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.
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.
Closes https://github.com/rust-lang/cargo/issues/7088.
r? `@joshtriplett`
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?
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?
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.
Throw error if CARGO_TARGET_DIR is an empty string
This pull request makes the target dir to be target/ if `CARGO_TARGET_DIR` is `` with spaces trimmed and not delete the current project.
Fixes: #8866
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.
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.
Fixes#5539.
