Stabilize patch-in-config (and prefer config over manifest)
Tracking issue: https://github.com/rust-lang/cargo/issues/9269
---
This stabilizes the `patch-in-config` feature ([unstable entry](https://doc.rust-lang.org/cargo/reference/unstable.html#patch-in-config)) following the discussion in https://github.com/rust-lang/cargo/issues/9269#issuecomment-904913263.
As requested, this PR _also_ changes the precedence behavior such that a `[patch]` for the same dependency in both `.cargo/config.toml` and `Cargo.toml` prefers the patch from the configuration file over the one from the manifest, which matches the behavior of other overlapping configuration options. The corresponding test has also been updated to reflect this change in behavior.
Change `cargo fix --edition` to only fix edition lints.
This changes it so that `cargo fix --edition` will only fix edition lints. The reason for this is that sometimes non-edition lints get in the way, and make suggestions that can cause failures. An example is a user that only ever runs `cargo test` or `cargo check --profile=test` locally, and doesn't realize there are problems with running without `cfg(test)` such as unused warnings.
This works by using `--cap-lints=allow` along with `--force-warn` which takes precedence over `cap-lints`.
This only works on nightly since `--force-warn` is still unstable. I will update this as part of #9800.
Closes#5738
Show desc of well known subcommands (fmt, clippy) in cargo --list
Fixes#8680
An approach to #8680 that shows these in `cargo --list` without showing them directly in the `cargo --help`.
```
➜ cargo git:(desc) target/debug/cargo --list | grep clippy
clippy Checks a package to catch common mistakes and improve your Rust code.
```
Here's what mine looks like visually now:
Fix test not to rely on `cargo` in PATH.
This fixes a test that was trying to execute `cargo` from PATH. This test doesn't work on rust-lang/rust where the rustup installation is removed, and thus there is no `cargo` in PATH.
Improve resolver message to include dependency requirements
Resolves#6199.
Thanks for previous efforts: #5452, #6374, #6665, which are great but somehow outdated, so I tweak them and create this PR. This will also be obsolete if we ship pubgrub-rs with cargo in the future 😃 But before that happens, IMO these changes are still helpful.
---
This PR changes the resolver error message from
216f915c46/tests/testsuite/build.rs (L1104-L1106)
to
0afd40b4de/tests/testsuite/build.rs (L1104-L1106)
Also provide different message for different source kinds, such like:
0afd40b4de/tests/testsuite/build.rs (L2810-L2812)
## TODO?
From https://github.com/rust-lang/cargo/pull/5452#issuecomment-402832200, there shall be at least one task left behind:
> 3. Special case pind by a lock file and not a `"=1.1.2"` in a dependency. Also add a "note: try cargo update" to the end.
In this PR, `validate_links` also faces this issue that a dependency requirement is locked into a precise version `=0.1.0`.
a5f8bc94f5/tests/testsuite/build_script.rs (L1002-L1004)
I am uncertain about how to resolve this. Besides the function`validate_links`, is this problem really a thing that may happen? If not, since `validate_links` only handles old validation logic, it may be ok to drop the commit a5f8bc94f5 and leave it as is.
Fix panic with build-std of a proc-macro.
If you try to run `cargo build -Zbuild-std` in a proc-macro project, cargo would panic in [`check_collisions`](835d5576e1/src/cargo/core/compiler/context/mod.rs (L427)). This is because it iterates over every Unit in the build graph checking the `outputs` for filenames. However, [`outputs`](835d5576e1/src/cargo/core/compiler/context/compilation_files.rs (L109-L110)) was missing the outputs for standard library units. That is because `outputs` is computed by walking the graph starting from the roots.
The bug here is that `attach_std_deps` was adding the standard library units to graph, even though they aren't reachable from the roots, thus creating orphans.
The solution is to avoid adding the standard library units if they are not needed (as is the case when building just a proc-macro).
Fixes#9828
Move `tmp` test directory.
The `tmp` directory added in #9375 was placed within the profile directory (such as `target/debug/tmp` or `target/release/tmp`). This causes problems for any cargo target (binary, test, etc.) with the name `tmp` as there is a name collision. This PR attempts to address that by moving the `tmp` directory to the root of the target directory (`target/tmp`), and reserving the profile name "tmp".
Fixes#9783
Determine packages to install prior to installing
Old logic (pseudocode)
```
for krate in to_install {
pkg = determine_pkg(krate);
install_pkg(pkg);
}
```
New logic
```
let pkgs = to_install.into_iter(|krate| determine_pkg(krate));
pkgs.into_iter(|pkg| install_pkg(pkg));
```
This has the short term benefit of dumping most error messages out earlier in the process (eg a typo in the second package name).
Longer term, it might help with #9741 - as only the second loop would be parallelized. First loop shouldn't be parallelized because it would lead to redundant registry/git updates.
Show feature resolver differences for dev-dependencies.
During the crater run for 2021, there was a package that failed to update in a confusing way. The issue is that a feature was removed in the new resolver, but only for a dev-dependency. The report displayed with `cargo fix --edition` did not say anything about that, so it took me a bit to figure it out. This changes it so that the report also includes changes to features of dev-dependencies. I honestly don't remember my thought process behind the original code.
For example, the offending package now says:
```
When building the following dependencies, the given features will no longer be used:
log v0.4.8 removed features: std
syn v0.15.44 (as host dependency) removed features: extra-traits, visit
The following differences only apply when building with dev-dependencies:
phf_shared v0.7.24 (as host dependency) removed features: unicase
```
And the error that happens after updating to 2021 is:
```
error[E0277]: the trait bound `UniCase<&str>: phf_shared::PhfHash` is not satisfied
--> /Users/eric/.cargo/registry/src/github.com-1ecc6299db9ec823/mime_guess-1.8.7/build.rs:37:21
|
37 | forward_map.entry(UniCase(key), &format!("{:?}", val));
| ^^^^^ the trait `phf_shared::PhfHash` is not implemented for `UniCase<&str>`
```
Hopefully developers will be able to see the note about the feature `unicase` being removed from `phf_shared`, and the error message about `UniCase` not implementing `PhfHash`, and connect the two together. Previously, the upgrade report didn't mention anything about `phf_shared`, and thus no clues on what went wrong.
Teach cargo to failfast on recursive/corecursive aliases
Eg.
[alias]
test-1 = test-2
test-2 = test-3
test-3 = test-1
Previously it would stack overflow
Pulled out non controversial bits from from #9768
Fix value-after-table error with profiles.
If the `strip`, `dir-name`, or `inherits` fields were included along with a profile override, then `cargo publish` would fail with a `ValueAfterTable` error because the fields were listed in the wrong order in the struct definition.
Fixes#9787
Add a profile option to select the codegen backend
This makes it possible to compile only specific crates with a certain codegen backend.
I have tested this by compiling Bevy with cg_llvm, but one of the examples using cg_clif.
By the way I noticed that many unstable profile options are not checked when using profile overrides.
There are already similar preexisting test helpers which
also work on windows. Port over the executable-creation
helper into the file() helper and things appear to pass.
Fix version string.
The version string for `cargo version` was inadvertently changed in #9657 so that it does not include the leading `cargo` as in `cargo 1.53.0 (4369396ce 2021-04-27)`.
Allow publishing from workspace root.
Adds -p, --workspace, and --exclude to package and publish commands.
Uses ephemeral workspaces to avoid changing the existing functions too much.
There might be more `Finished dev [unoptimized + debuginfo] target` messages when packaging than there should be, I couldn't figure out what was generating them.
The tests aren't super extensive, as all the specs from arguments code should already be tested elsewhere.
Closes#7345
Stabilize the rustc-link-arg option
This change removes the unstable option (tracked by #9426) and unconditionally accepts additional linker arguments (as implemented in #7811 and #8441). Documentation is moved from unstable to what appeared to be the correct location.
I am not aware of any significant concerns with the option and it appears consistent with some other existing stable linker options.
Please let me know if this is not the appropriate process or if there is anything that I am missing from the PR.
Update should_use_metadata function
* Correct the reason for not renaming dylibs
* Add todo for -install-name/-soname usage
* Limit wasm32 executable metadata omission to emscripten. Wasm file don't contain any filename themself.
* Don't omit metadata for executables on macOS. backtrace-rs is now able to load debuginfo for renamed .dSYM files: ed3689c2f2/src/symbolize/gimli/macho.rs (L51-L65)
* Mention another reason to include the metadata hash for libstd.
Named profile updates
A few updates for named profiles to push them closer to stabilization:
- Disable the `dir-name` profile setting. `dir-name` primarily exists for translating the built-in profiles or sharing artifacts between profiles. In order to simplify the UI, we would like to not expose it to the user for the initial stabilization. The code to support it is kept in case we want to add it in the future.
- Reserve some profile names. Just to give a little flexibility in the future in case we want to use these, or that they could cause confusion. Also updated the error text a little.
- Add support for custom profiles to legacy commands. Their old behavior is still retained for backwards compatibility. That is:
* `cargo check`
* `--profile=test`: This forces the test mode. For example, `cargo check --lib --profile=test` will check the library as a unit test (with `--test`).
* `cargo fix`
* `--profile=test`: Forces test mode, same as above.
* `cargo rustc`
* `--profile=test`: Forces test mode, same as above.
* `--profile=bench`: Forces bench mode.
* `--profile=check`: Forces check mode.
- These commands also allow mixing the above options with `--release`, which is normally not allowed.
- Fix `cargo bench` to support the `--profile` option. I think it was just forgotten.
Deduplicate compiler diagnostics.
This adds some logic to deduplicate diagnostics emitted across rustc invocations. There are some situations where different targets can emit the same message, and that has caused confusion particularly for new users. A prominent example is running `cargo test` which will build the library twice concurrently (once as a normal library, and once as a test).
As part of this, the "N warnings emitted" message sent by rustc is intercepted, and instead cargo generates its own summary. This is to prevent potentially confusing situations where that message is either deduplicated, or wrong. It also provides a little more context to explain exactly *what* issued the warnings. Example:
```warning: `foo` (lib) generated 1 warning```
This only impacts human-readable output, it does not change JSON behavior.
Closes#9104
`cargo fix --edition`: extend warning when on latest edition
This extends the warning issued when `cargo fix --edition` is run when the user is already on the latest edition. Before #9184, there were instructions on what to do, but those probably should not have been completely removed. It seems likely that some users may get the steps out of order, so this hopefully tries to explain them clearly.
Add format option to `cargo tree` to print the lib_name
Adds a way to have `cargo tree` display the name of the library inside a package dependency, which can differ from the name of the package. Updates the `tree::format` test to test for its proper behavior.
Closes#9659
Prefer patched versions of dependencies
When selecting among several versions of a paackage, prefer versions
from `[patch]` sections over other versions, similar to how locked
versions are preferred.
Patches come in the form of a Dependency and not a PackageId, so this
preference is expressed with `prefer_patch_deps`, distinct from
`try_to_use`.
Fixes#9535
Spot the crate typo easily
ego tweak to make it easy to spot typos:
Before:
```
error: no matching package named `sc-consensus-primitivies` found
location searched: /Users/bit/p/substrate1/client/primitives/consensus/common
perhaps you meant: sc-consensus-primitives
required by package `sc-network v0.9.0 (/Users/bit/p/substrate1/client/network)`
```
After:
```
error: no matching package named `sc-consensus-primitivies` found
perhaps you meant: sc-consensus-primitives
location searched: /Users/bit/p/substrate1/client/primitives/consensus/common
required by package `sc-network v0.9.0 (/Users/bit/p/substrate1/client/network)`
```
This makes the following changes:
- Allows `cargo check`, `cargo fix`, and `cargo rustc` to support custom
named profiles. This retains the legacy behavior of those commands.
- Fixes `cargo bench` so that it supports custom named profiles.
Just to give a little flexibility in the future in case we want to use
these, or that they could cause confusion. Also updated the error text a
little.
dir-name primarily exists for translating the built-in profiles. In
order to simplify the UI, we would like to not expose it to the user for
the initial stabilization. The code to support it is kept in case we
want to add it in the future.
Serialize `cargo fix`
This changes `cargo fix` so that it only fixes one crate at a time. Previously, it would allow concurrent fixing across packages. This caused a problem if a workspace uses things like `#[path]` or `include!()` of a shared file between packages. A real-world example of this is serde, which has [this](9c39115f82/serde_derive_internals/lib.rs (L43-L45)) which reuses the some source files between the `serde` and `serde_derive` packages. Modifying those files concurrently causes corruption and the fix will fail.
Closes#6528
Update nightly failure notification.
This makes several changes to try to clarify errors with nightly requirements.
- Don't tell the user to edit `Cargo.toml` if it is not a local package. Things like registry packages are not under their control.
- Include the version number in the error message.
- Try to make better suggestions on what to do.
- Remove the redirects for stabilized features in unstable.md, and instead include a small stub that tells the user when it was stabilized and where to find more information. This should help with people using older releases which provide links to this page, to help them know which version they will need.
Closes#9610
Update Windows env uppercase key check.
This is the followup for #9646. Rust now correctly spawns processes with preserved casing on nightly on Windows, so the exceptions here are no longer needed.
When selecting among several versions of a paackage, prefer versions
from `[patch]` sections over other versions, similar to how locked
versions are preferred.
Patches come in the form of a Dependency and not a PackageId, so this
preference is expressed with `prefer_patch_deps`, distinct from
`try_to_use`.
This works by introspecting rustc's error output, using the JSON format
to determine whether it's a warning or error, then skipping it
altogether if it's a summary of the diagnostics printed.
Before:
```
src/main.rs:1:10: warning: trait objects without an explicit `dyn` are deprecated
src/main.rs:1:1: error[E0601]: `main` function not found in crate `wrong`
src/main.rs:1:9: error[E0038]: the trait `Clone` cannot be made into an object
error: aborting due to 2 previous errors; 1 warning emitted
error: could not compile `wrong`
```
After:
```
$ cargo check --message-format short
src/main.rs:1:10: warning: trait objects without an explicit `dyn` are deprecated
src/main.rs:1:1: error[E0601]: `main` function not found in crate `wrong`
src/main.rs:1:9: error[E0038]: the trait `Clone` cannot be made into an object
error: could not compile `wrong` due to 2 previous errors; 1 warning emitted
```
Include the linker in the fingerprint.
This adds the linker from the `[target]` config table to the fingerprint. Previously, changing the value would not trigger a rebuild.
Temporarily disable windows env test.
This temporarily disables the `target_in_environment_contains_lower_case` test on Windows until https://github.com/rust-lang/rust/pull/85270 gets into nightly. That PR changes it so that env vars are case-preserved on Windows. My intent is that after that is in nightly, we can remove the windows-specific code in `Config`, and this test should work the same on all platforms.
Closes#9630
Handle git deleted files with dirty worktree.
When listing git files for things like `cargo package`, it was including unstaged deleted files. This is because the file is still in the index, so it was included in the list. `cargo package --allow-dirty` would then fail with a confusing "file not found" error.
This fixes it by keeping a set of deleted files, and skipping those. This allows `cargo package --allow-dirty` to work.
Closes#9580
Fix `BorrowMutError` when calling `cargo doc --open`
~~I'm not sure why the existing test suite didn't catch this, it definitely calls `cargo doc --open`.~~
I had
```toml
[doc.extern-map]
std = "local"
```
in my `.cargo/config.toml`. Will write a test case that sets that and then tries to run `cargo doc --open`.
Closes#9530
Error when packaging with git dependencies without version
If `cargo package` is run on a package that specifies a git dependency
without a version, cargo will error. This should help with clarifying
that git dependencies will be stripped when packaging, and that the
dependency has to be fetched from a registry.
Closes#9442
If `cargo package` is run on a package that specifies a git dependency
without a version, cargo will error. This should help with clarifying
that git dependencies will be stripped when packaging, and that the
dependency has to be fetched from a registry.
Unify weak and namespaced features.
This unifies weak and namespaced features in order to simplify the syntax and semantics. Previously there were four different ways to specify the feature of a dependency:
* `package-name/feature-name` — Enables feature `package-name` on self and enables `feature-name` on the dependency. (Today's behavior.)
* `package-name?/feature-name` — Only enables `feature-name` on the given package if it that package is enabled and will also activates a feature named `package-name` (which must be defined implicitly or explicitly).
* `dep:package-name/feature-name` — Enables dependency `package-name`, and enables `feature-name` on that dependency. This does NOT enable a feature named "package-name".
* `dep:package-name?/feature-name` — Only enables `feature-name` on the given package if it that package is enabled. This does NOT enable a feature named "package-name".
This changes it so there are only two:
* `package-name/feature-name` — Today's behavior.
* `package-name?/feature-name` — Only enables `feature-name` on the given package if it that package is enabled. This does NOT enable a feature named "package-name" (the same behavior as `dep:package-name?/feature-name` above).
This is a fairly subtle change, and in most cases probably won't be noticed. However, it simplifies things which helps with writing documentation and explaining how it works.
Change `rustc-cdylib-link-arg` error to a warning.
In #9523, an error was added if `cargo:rustc-cdylib-link-arg` was issued in a build script without actually having a cdylib target. This uncovered that there was an unintentional change in #8441 to cause those link args to be applied to transitive dependencies.
This changes it so that the error is now a warning, with a note that this may become an error in the future. It also changes it so that the unstable `rustc-link-arg*` instructions only apply to the package that emitted them.
Don't allow config env to modify vars set by cargo
This changes how the `[env]` variables are applied. They will no longer replace any variables that are being set by cargo itself, whether or not the `force` flag is set. The `force` flag still determines whether existing variables from the environment can be overridden or not.
Addresses unresolved issue in #9539
