RFC 3052: Stop including authors field in manifests made by cargo new
See https://github.com/rust-lang/rust/issues/83227
~~This is definitely a draft as there are a couple of tests I'm still working on fixing.~~ One question I ran into while digging through these test failures is that there is a Cargo config option for author name, `cargo-new.name`. Should we keep supporting that? I feel like perhaps we should as the user has specified explicit intent that they want their name in the authors of a manifest as generated by `cargo new`, but it seems weird to support *just* that case. There is likewise an environment variable `CARGO_NAME` that signals similar intent.
Should we completely drop the feature of putting in author names, and require people to manually put them in if they wish, or allow these limited cases where the user is specifically instructing *cargo* to do it?
Refactor feature handling, and improve error messages.
This changes the way feature strings are handled with an eye towards fixing some improper handling and to improve error messages. The key change is to stop treating all features as free-form strings and instead try to handle them as typed values. This helps avoid needing to deal with parsing different feature syntax (like `dep:` or `foo/bar`) or forgetting to handle it properly.
Overview of refactoring changes:
* `RequestedFeatures` changed to an enum to differentiate between features coming from the command-line, and those that are from a dependency.
* Moved parsing of CLI features to an earlier stage (now stored in `CompileOptions`), and ensures that they are properly handled as `FeatureValue` instead of strings.
* Pushed some feature validation earlier. For example, `DetailedTomlDependency` now validates things so you can see the location for the errant `Cargo.toml` (previously some validation was deep in the resolver, which provided poor errors).
This is a pretty large PR, but at the core it is just changing `RequestedFeatures` and then dealing with the fallout from that. Hopefully this is an improvement overall.
List of user-visible changes:
* Fix handling in resolver V2 of `--features bar?/feat` and `--features dep:bar`
* Better error handling for `bar/feat` and `dep:bar` in dependency declarations.
* Feature keys in the `[features]` table can no longer contain slashes.
* Fixed a minor issue with `cargo tree -e features --all-features -Z namespaced-features`
* Fixed a panic with `cargo tree` involving `-Z weak-dep-features`
I did a small amount of benchmarking, and I wasn't able to record much of a difference.
Split out cargo-util package for cargo-test-support.
This splits out code from `cargo` that was being used by `cargo-test-support` in order to remove the dev-dependency cycle on the `cargo` crate. The intent here is to improve development build times. On my system, `touch src/cargo/lib.rs ; cargo check --profile=test` goes from 6.4 seconds to 3.5. I suspect more substantial changes (more than just `touch`) should exhibit even more improvements.
This has a substantial downside that it is another package to manage publishing, particularly with making sure the version is updated correctly for crates.io. I'm uncertain if on balance it is worth it, but I lean towards moving forward with it.
cargo-test-support wasn't using any of the caching or other logic from
Rustc, so this just swaps with a very basic implementation in order to
remove the dependency on `cargo`.
Use serde's error message option to avoid implementing `Deserialize`.
This is a cleanup based on https://github.com/serde-rs/serde/issues/1883, which fell out of https://github.com/rust-lang/cargo/pull/8664
It looks like this changes the resulting error messages. I'll leave it up to you to decide if the tradeoff makes sense here. Maybe the correct answer here is to make `serde`'s error messages include more details (e.g. `invalid type: int`).
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
Fix doc duplicate removal of root units.
The doc collision removal code didn't consider the possibility that there was a collision with a root unit. This caused problems in conjunction with #9142 where cargo would panic because a root unit got removed from the graph because of a filename collision. The solution here is to avoid removing root units during the doc collision sweep.
This has a downside that this reintroduces a filename collision.
An alternate solution would be to make the set of root units mutable, and remove from that list, but I figured this is simpler and more conservative.
Fixes#9274
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.
