refactor(toml): Better abstract inheritance details
There is no reason that the caller for inheriting needs to know the details of the inner types doing inheritance.
Migrate rustfix to the cargo repo
This migrates the `rustfix` crate from https://github.com/rust-lang/rustfix/ to the cargo repo. The cargo team has been responsible for the client-side of `cargo fix`, and it can make it easier to maintain with all our tooling and tracking here. This crate is used by some external parties (like the compiler), so it will need to be maintained like an "ecosystem" package, but hopefully there shouldn't be any outside requirements (I haven't seen any in several years).
After merging, I'll follow up with some things to address in the future, such as:
- Migrating issues from the other repo.
- Opening new issues for some cleanup tasks, such as adding documentation, fixing the `#[ignore]` annotations, fixing testing on windows, maybe migrating the test code to use different dependencies, various code cleanup.
- Archiving the repo.
Handle $message_type in JSON diagnostics
### What does this PR try to resolve?
Unblocks https://github.com/rust-lang/rust/pull/115691.
Without this change, Cargo's testsuite fails in `doc::doc_message_format` and `metabuild::metabuild_failed_build_json`.
### How should we test and review this PR?
Tested with and without https://github.com/rust-lang/rust/pull/115691.
In Cargo repo: `cargo test --test testsuite`
In Rust repo: `x.py test src/tools/cargo` (separately on master and $message_type PR)
refactor(toml): Further clean up inheritance
### What does this PR try to resolve?
This is a follow up to #12971 that was found as I continued working towards #12801.
The first is a more general purpose API cleanup. I was bothered by the idea that a caller could create a `field.workspace = false` when that is disallowed, so I modified the API to prevent that.
The second is part of needing to find a home for everything in `toml/mod.rs`. I figured `IneheritableField::as_value` is reasonable in the API, so I carried that forward. It would be reasonable to add other methods, from an API perspective, but I left that for future exploration.
### How should we test and review this PR?
### Additional information
Fix `--check-cfg` invocations with zero features
When generating the `--check-cfg` arguments for `-Zcheck-cfg` we currently generate `cfg(feature, values())` when there is 0 features. This is wrong since a empty `values()` would mean that it's possible to have `cfg(feature)` without a feature name which is impossible.
We replace this by a simple `cfg()` to still enable well known names and values.
----
Note that currently `rustc` defines `feature` as a well known name with ANY values if it's not overridden by Cargo. I plan on submitting a PR to `rustc` to remove `feature` from being a well known name so that Cargo is the only source of truth.
*This doesn't block this PR from being merged*
chore: bump `cargo-credential-*` crates as e58b84d broke stuff
e58b84d changed the shape of response of cargo credential protocol trait,
so credential plugin crates effectively depend on `cargo-credential@0.4.0`.
However, `cargo@0.74.0` still depends on`cargo-credential@0.3.0`.
They must depend on the same major version of `cargo-credential`
otherwise incompatible.
This PR
* bumps the version to `cargo-credential-wincred@0.4.2`
* bumps the version to `cargo-credential-macos-keychain@0.4.2`
* bumps the version to `cargo-credential-li@0.4.2`
See https://github.com/rust-lang/cargo/pull/13004 for more.
contrib docs: Update now that credential crates are published.
The credential crates are now auto-published, so this updates the documentation to reflect that.
e58b84d changed the shape of response of cargo credential protocol trait,
so credential plugins crates effectively depend on `cargo-credential@0.4.0`.
However, `cargo@0.74.0` still depends on`cargo-credential@0.3.0`.
They must depends on the same major version of `cargo-credential`
otherwise incompatible.
This PR
* bumps the version to `cargo-credential-wincred@0.4.2`
* bumps the version to `cargo-credential-macos-keychain@0.4.2`
* bumps the version to `cargo-credential-li@0.4.2`
See rust-lang#13004 for more.
Respect `rust-lang/rust`'s `omit-git-hash`
The `config.toml` file in `rust-lang/rust` has the `omit-git-hash` option, which prevents git information from being embedded into binaries. This works for most tools, as they rely on the git information provided by bootstrap through environment variables.
Cargo does its own git detection in its build script though, which didn't adhere to to that option. This changes that by skipping git detection whenever bootstrap signals the option is enabled.
Fix clippy-wrapper test race condition.
This fixes an issue where if certain tests ran concurrently, they would stomp on each other writing to a global directory. The problem is that `wrapped_clippy_driver` was writing to a global directory without any locking. The solution is to use the existing locking setup we have for supporting similar global tools.
This doesn't often show up because the offending tests are usually separated enough alphabetically, but if they happen to run near each other, they would stomp on each other and corrupt the directory.
fix(resolver): Don't do git fetches when updating workspace members
### What does this PR try to resolve?
Before, when running `cargo update <member>`, we'd not reuse the
previous resolve result and when the resolver started walking into the
dependencies, it would do a git fetch.
Now, we won't even try to resolve the workspace members and so we won't
look at those dependencies and do git fetch.
This will make `cargo update <workspace-member>`
match `cargo update --workspace`.
Fixes#12599Fixes#8821
### How should we test and review this PR?
I considered whether there were other ways of handling this but I
figured aiming for consistency in approaches was the best way.
We can investigate improving those approaches separately.
There are other discrepancies in the different code paths (handling of
patches, adding sources) but I'm deferring looking over those.
I added a test to demonstrate the `--workspace` behavior to use as a base line to compare with.
### Additional information
Between this and #12602, this should finally resolve#12599.
refactor(toml): Clean up workspace inheritance
### What does this PR try to resolve?
The goal is to simplify the code so we have a better boundary between `toml/mod.rs` and `toml/schema.rs` for when we break `toml/schema.rs` into a separate package for #12801.
This let us
- Remove a trait used in some back and forth for error handling
- Move a lot of the inheritable bookkeeping and logic out of `schema.rs`
A lot of these changes were inspired by [`cargo_toml`](https://docs.rs/cargo_toml/latest/cargo_toml/). This included some renaming that I felt made the code clearer.
I didn't go as far as `cargo_toml`, yet.
- They derive more `Deserializers`, producing worse errors
- Their equivalent of `InheritableField` has an `inherit` function on it. They eagerly inherit things and then error if anything isn't inherited
- I'm still toying with something like this but held off for now
- One idea is `InheritableField` has an `inherit_with` function, like today, that only passes errors up but doesn't generate an error. We then have a `get` function that errors if it isn't inherited. We could encode the field names, for error reporting, into a type parameter for `InheritableField`
- They flatten `InheritableDependency` into `TomlDependency`
- By splitting these up, `workspace.dependencies` and `.cargo/config.toml` code can directly use `TomlDependency` without extra error handling
-If we went this rout, I think I'd merge`InheritableDependency::Inherit` with `DetailedDependency`, having callers handle the errors (much like `TomlManifest` is both a real and virtual)
Some things I'm trying to balance
- Complexity
- Quality of error messages
- Knowing what code needs touching when changes are made
- Some more work is needed here
### How should we test and review this PR?
### Additional information
docs: Recommend a wider selection of libsecret-compatible password managers
### What does this PR try to resolve?
Previously the only password manager recommended was Gnome Keyring, which not everyone will find ideal for a variety of reasons. A few common ones:
- GTK. The user may not want to have to install the entire toolkit.
- Look and feel. The design of Gnome software is pretty opinionated.
- They already use something else.
So I think it makes sense to recommend a few more widely-used alternatives. All three are GPL.
### How should we test and review this PR?
Documentation changes only.
### Additional information
