And enables the use of the `--profile` CLI option to choose a profile by name.
Another key change here is that cargo now only uses a single profile per command. Previously, some commands such as `cargo test` would use a mix of profiles based on which package and target were being built.
### Summary of new behavior
* Profiles can now have arbitrary names. New profiles require the `inherits` key.
* The `--profile` flag is now available on all build commands.
* The `CompileMode` is no longer considered for choosing the profile, only one profile will be used. Previously, building a test, benchmark, or doctest would use the test or bench profile, and all dependencies would use the dev/release profiles. This change is done to arguably make it easier to understand, and to possibly give more desired and intuitive behavior.
* The `test` profile now inherits settings from the `dev` profile (and `bench` from `release`).
### Deviations from the original RFC and implementation
* The original RFC indicated that `--all-targets` without `--profile` would retain the old behavior where it would use different profiles for different targets. However, the implementation uses a single profile, to avoid confusion and to keep things simple.
* The `dir-name` key is not exposed to the user. The implementation is retained to handle mapping of built-in profile names (test/dev→debug, bench→release). This can be exposed in the future if necessary.
### Notes about this PR
* Fixed an issue where the duplicate package override check would randomly return matches for inherited profiles like `test`.
* I left some of the old, vestigial code behind to possibly make it easier to revert this PR if necessary. If this does land, I think it can be eventually removed (code using `Feature::named_profiles` and various things using `named_profiles_enabled`).
* Added `target` to reserved list, just because.
* Adds a warning if `--release` is combined with `--profile` in `cargo rustc`, `check`, or `fix`. The `--release` flag was being ignored.
### Hazards and concerns
* This has had very little real-world testing.
* Custom profile directories may conflict with other things in the `target` directory. We have reserved profile names that currently conflict (such as `doc` or `package`). However, they can still collide with target names. This also presents a hazard if Cargo ever wants to add new things to that top directory. We decided to proceed with this because:
* We currently have no plans to add new built-in profiles.
* We have reserved several profile names (including anything starting with "cargo"), and the profile name syntax is deliberately limited (so cargo is still free to add `.` prefixed hidden directories).
* A user creating a profile that collides with a target name resides in the "don't do that" territory. Also, that shouldn't be catastrophic, as the directories are still somewhat organized differently.
* Artifacts may no longer be shared in some circumstances. This can lead to substantially increased `target` directory sizes (and build times), particularly if the `test` profile is not the same as the `dev` profile. Previously, dependencies would use the `dev` profile for both. If the user wants to retain the old behavior, they can use an override like `[profile.test.package."*"]` and set the same settings as `dev`.
* This may break existing workflows. It is possible, though unlikely, that changes to the profile settings will cause changes to how things build in such a way to break behavior.
* Another example is using something like `cargo build` to prime a cache that is used for `cargo test`, and there is a custom `test` profile, the cache will no longer be primed.
* The legacy behavior with `cargo rustc`, `cargo check`, and `cargo fix` may be confusing. We may in the future consider something like a `--mode` flag to formalize that behavior.
* The `PROFILE` environment variable in build scripts may cause confusion or cause problems since it only sets `release` or `debug`. Some people may be using that to determine if `--release` should be used for a recursive `cargo` invocation. Currently I noted in the documentation that it shouldn't be used. However, I think it could be reasonable to maybe add a separate environment variable (`PROFILE_NAME`?) that exposes the actual profile used. We felt that changing the existing value could cause too much breakage (and the mapping of debug→dev is a little awkward).
bors [Tue, 5 Oct 2021 18:16:42 +0000 (18:16 +0000)]
Auto merge of #9847 - weihanglo:issue-9840, r=Eh2406
Distinguish lockfile version req from normal dep in resolver error message
Resolves #9840
This PR adds a new variant `OptVersionReq::Locked` as #9840 described.
The new variant represents as a locked version requirement that contains
an exact locked version and the original version requirement.
Previously we use exact version req to synthesize locked version req.
Now we make those need a truly locked to be `OptVersionReq::Locked`,
including:
- `[patch]`: previous used exact version req to emulate locked version,
and it only need to lock dep version but not source ID, so we make
an extra method `Dependency::lock_version` for it.
- Dependencies from lock files: No need to change the call site.
bors [Fri, 1 Oct 2021 16:59:58 +0000 (16:59 +0000)]
Auto merge of #9951 - relrelb:completion, r=alexcrichton
Add shell completion for shorthand commands
Currently `cargo` has shell completion for most (if not all) builtin commands such as `build`, `run`, `check` etc.
However, it doesn't have shell completion for the short forms of these commands, such as `b`, `r`, `c` etc.
This PR adds both bash and zsh completions for command shorthands.
relrelb [Fri, 1 Oct 2021 08:14:45 +0000 (11:14 +0300)]
Add shell completion for shorthand commands
Currently `cargo` has shell completion for most (if not all) builtin
commands such as `build`, `run`, `check` etc.
However, it doesn't have shell completion for the short forms of these
commands, such as `b`, `r`, `c` etc.
This commit adds both bash and zsh completions for command shorthands.
Auto merge of #9945 - ehuss:update-precise-metadata, r=alexcrichton
Allow `cargo update --precise` with metadata.
`cargo update --precise` would require that the version matches *exactly*, including build metadata. Usually the build metadata is ignored (like in dependency declarations), but in this circumstance it isn't. This can be awkward in some cases where it can be more convenient to type just the version number without the build metadata.
This changes it so that if the metadata isn't provided, then it will be ignored when matching. Otherwise, it will be honored. This is slightly different from a version requirement like `=1.2.3+foo` which ignores the metadata completely.
This also adds a slightly better error message if you don't type in valid syntax for a version number (previously it would just emit the `no matching package` error).
Auto merge of #9866 - nipunn1313:pkg_in_repo2, r=ehuss
Support path_in_vcs as part of cargo_vcs_metadata
Depends on #9865 - this PR will look simpler once that one lands. I can't target my PR to the base branch of #9865 as an external contributor (since it's in my fork). For now just review the latest commit of this one.
This is a backward compatible change that is an alternative to #9837
Auto merge of #9921 - ehuss:fetch-smoke, r=alexcrichton
Add fetch smoke test.
This adds a test with a statically built curl to check if running `cargo fetch` works. This adds a few minutes to CI time, but I think it is worthwhile to try to catch some regressions.
Note that macOS uses system curl to match the rust-lang/rust build mode.
Auto merge of #9934 - ehuss:progress-test, r=alexcrichton
Differentiate tests in progress bar.
Some people have expressed confusion when the progress bar includes the package name twice, such as:
```
Building [=======================> ] 301/307: rustc_interface, rustc_interface
```
This can happen in a variety of circumstances, but a common one is `cargo test`. This causes the library to be built in parallel with the library being built for unittests. This PR adds some additional markers to differentiate what is being built:
- Lib as test: `lib_name(test)`
- Binary as test: `bin_name(bin test)`
- Example as test: `example_name(example test)`
Merge branch 'master' of https://github.com/rust-lang/cargo into help
* 'master' of https://github.com/rust-lang/cargo: (21 commits)
Remove TOML incompatibility hacks
Use a more compact way to compare versions
Remove broken link in contrib docs.
Change diesel compatibility messages
Temporarily revert curl-sys update.
Update curl-sys
Bump Cargo's curl requirement to 7.79.0
Revert "When a dependency does not have a version, git or path, fails directly"
Fix warnings from better precision of `dead_code` lint
Improve "wrong output" error.
Add some contributor docs for debugging testsuite tests.
Fix warnings when documenting with `--document-private-items`
Update changelog for 1.56
Bump to 0.58.0
Fix rustc --profile=dev unstable check.
config.md: fix typo
Enable some tests on windows.
Fix `cargo fix --edition` on stable.
Enable strip test on macos.
Remove log
...
Auto merge of #9927 - weiznich:diesel_2021_edition, r=ehuss
Change diesel compatibility messages
Diesel 1.4.8 fixes the critical behaviour. This commit changes the
corresponding messages for `cargo fix` and normal builds to prompt the
user to just update the diesel version to fix the corresponding
compilation errors.
As discussed in https://github.com/rust-lang/rust/issues/88903#issuecomment-923061946
Georg Semmler [Mon, 20 Sep 2021 19:20:26 +0000 (21:20 +0200)]
Change diesel compatibility messages
Diesel 1.4.8 fixes the critical behaviour. This commit changes the
corresponding messages for `cargo fix` and normal builds to promt the
user to just update the diesel version to fix the corresponding
compilation errors.
Weihang Lo [Mon, 20 Sep 2021 03:31:41 +0000 (11:31 +0800)]
Compare version fields' equalities directly
Instead of creating another VersionReq, this can reduce some extra
efforts on version matching logic. Though it also may introduces
divergence from semver's matching logic. Accordingly, we borrow unit
tests from semver crate and compare the matching results to prevent
future breaks.
Auto merge of #9903 - jyn514:rustdoc-warnings, r=alexcrichton
Fix warnings when documenting with `--document-private-items`
- Use hyperlinks for URLs
- Fix broken intra-doc links
This doesn't fix the following warning, since I wasn't sure what change
was appropriate:
```
warning: public documentation for `rustc_process` links to private item `self::core::compiler::Context::primary_packages`
--> src/cargo/core/compiler/compilation.rs:164:22
|
164 | /// flag), see [`crate::core::compiler::Context::primary_packages`].
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ this item is private
|
= note: `#[warn(rustdoc::private_intra_doc_links)]` on by default
= note: this link resolves only because you passed `--document-private-items`, but will break without
```
To avoid noise, this doesn't add an `allow` either.
Joshua Nelson [Sat, 11 Sep 2021 17:33:45 +0000 (12:33 -0500)]
Fix warnings when documenting with `--document-private-items`
- Use hyperlinks for URLs
- Fix broken intra-doc links
This doesn't fix the following warning, since I wasn't sure what change
was appropriate:
```
warning: public documentation for `rustc_process` links to private item `self::core::compiler::Context::primary_packages`
--> src/cargo/core/compiler/compilation.rs:164:22
|
164 | /// flag), see [`crate::core::compiler::Context::primary_packages`].
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ this item is private
|
= note: `#[warn(rustdoc::private_intra_doc_links)]` on by default
= note: this link resolves only because you passed `--document-private-items`, but will break without
```
To avoid noise, this doesn't add an `allow` either.
Auto merge of #9898 - ehuss:rustc-profile-dev, r=alexcrichton
Fix rustc --profile=dev unstable check.
This fixes an oversight from #9685 where `cargo rustc --profile=dev` was accidentally changed to require `-Zunstable-options`. 1.54 and earlier supported that [here](https://github.com/rust-lang/cargo/blob/rust-1.54.0/src/bin/cargo/commands/rustc.rs#L490.
Auto merge of #9893 - ehuss:windows-echo, r=alexcrichton
Enable some tests on windows.
This enables some more tests on windows that were disabled because `echo` is not always available. It's pretty easy to make a custom `echo`, so that's what this does. I'm generally not comfortable with disabling tests just because there is an inconvenience like this.
Usually when I care about pulling in a patch of one of my dependencies using `[patch.crates-io]`, this is the ref that I want to depend on. None of the alternatives are good:
- `{ git = "the fork", branch = "the-pr-branch" }` — this is second closest to what I want, except that when the PR merges and the PR author deletes their fork, it'll breaks.
- `{ git = "the fork", rev = "commithash" }` — same failure mode as the previous. Also doesn't stay up to date with PR, which is sometimes what I want.
- `{ git = "the upstream", rev = "commithash" }` — doesn't work until the PR is merged or the repo owner creates a named branch or tag containing the PR commit among its ancestors, because otherwise the commit doesn't participate in Cargo's fetch.
- `{ git = "my own fork of PR author's repo", branch = "the-pr-branch" }` — doesn't stay up to date with PR.
This PR adds support for specifying a git dependency on the head of a pull request via the existing `rev` setting of git dependencies: `{ git = "the upstream", rev = "refs/pull/9859/head" }`.
Previously this would fail because the `cargo::sources::git::fetch` function touched in this pull request did not fetch the refspec that we care about. The failures look like:
```console
error: failed to get `mockall` as a dependency of package `testing v0.0.0`
Caused by:
failed to load source for dependency `mockall`
Caused by:
Unable to update https://github.com/asomers/mockall?rev=refs/pull/330/head
If dual purposing `rev` for this is not appealing, I would alternatively propose `{ git = "the upstream", pull-request = "9859" }` which Cargo will interpret using GitHub's ref naming convention as `refs/pull/9859/head`.
Auto merge of #9869 - nipunn1313:errmsg, r=alexcrichton
Improve error message when unable to initialize git index repo
With this - it'll be more obvious which git repo
couldn't be initialized.
Looks like this
```
➜ cargo RUST_BACKTRACE=1 target/debug/cargo build
error: failed to get `anyhow` as a dependency of package `cargo v0.57.0 (/Users/nipunn/src/cargo)`
Caused by:
failed to initialize index git repository (in "/Users/nipunn/.cargo/registry/index/github.com-1ecc6299db9ec823")
Caused by:
failed to parse config file: invalid configuration key (in /Users/nipunn/.config/git/config:1); class=Config (7)
```
Does the best we can with #9854 - since I don't think it can actually be fixed.
Fixes #9854
projects / cargo.git / log