fix(toml): Don't double-warn when underscore is used in workspace dep
### What does this PR try to resolve?
This is prep for removing them in the 2024 Edition and is part of rust-lang/rust#123754 and #13629
Particularly, I wanted to make sure I didn't make things worse and in doing so found there was room for improvement.
### How should we test and review this PR?
### Additional information
fix(toml): Be more forceful with underscore/dash redundancy
### What does this PR try to resolve?
This is prep for removing them in the 2024 Edition and is part of rust-lang/rust#123754 and #13629
During #13783, I had considered making the 2024 edition behavior a "unused key" warning. However, the work and code mess to pipe the data through correctly handle the two fields in all cases didn't seem worth it (and a hard error might be better to help users transition).
### How should we test and review this PR?
### Additional information
Fix warning suppression for config.toml vs config compat symlinks
### What does this PR try to resolve?
Background: the cargo config file is being renamed from `.cargo/config` to `.cargo/config.toml`. There's code in new cargo to look for both files (for compatibility), to issue a warning when onliy the old filename is found, and also to issue a warning if both files are found. The warning suggests making a symlink if compatibility with old cargo is wanted.
An attempt was made to detect when both the old and new files exists, but one is a symlink to the other, but as reported in #13667, this code is not effective. (It would work only if the symlink had the precise absolute pathname that cargo has decided to use for the lookup, which would be an unnatural way to make the link.)
Logically, the warning should appear when both files exist *but are different*. That is the anomalous situation that will generate confusing behaviour. By "different" we ought to mean "aren't the very same file".
That's what this MR implements, where possible. On Unix, we use the information from stat(2). That's not available on other platforms; on those, we arrange to also tolerate a symlink referring to precisely `config.toml` as a relative pathname, which is also fine, since by definition the target is then in the same directrory as `config`.
Fixes#13667.
### How should we test and review this PR?
I have interleaved the new tests with the commits that support them. In each case, a functional commit is followed by a test which fails just beforehand.
(This can be observed by experimentally reordering the branch.)
I have also done ad-hoc testing.
### Additional information
I'm making the assumption that a symlink containing a relative path does something sane on Windows. This assumption may be unwarranted. If so, "Handle `config` -> `config.toml` (without full path)" needs to be dropped, and the test case needs to be `#[cfg(unix)]`.
But also, in this case, we should probably put some warnings in the stdlib docs!
Cleanup linting system
There are a number of problems with the current linting system, most notably that lints could run without `-Zcargo-lints` being set. This PR fixes that issue and a few others that are low-hanging fruit.
This is 100% reliable on Unix, and better on Windows.
(In this commit I avoid reindenting things to make review easier; the
formatting will be fixed in the next commit.)
Fixes#13667
"symlink A to B" is confusing; it is ambiguous (at leaset to me)
whether it means A -> B or B -> A.
And I'm about to introduce a function that does the reverse,
and also one that makes a relative rather than full path link.
So rename this function.
fix(install): Don't respect MSRV for non-local installs
### What does this PR try to resolve?
This is part of #9930
### How should we test and review this PR?
### Additional information
The design for this stems from
- It being unclear what the initialization order would be
- Prematurely writing this for `Cargo.lock` version to leverage it and
maybe to switch other MSRV-aware logic to
gate some libc usages under cfg(unix), drop os_info features
Places few `libc` usages under `cfg(unix)`. That didn't remove it from tree, but still looks cleaner.
Drop features from os_info crate, as serde support currently unused.
feat(resolver): Add default Edition2024 to resolver v3
### What does this PR try to resolve?
With #13776 done, we can now make MSRV-aware resolver the default for the new edition as part of #9930
### How should we test and review this PR?
### Additional information
Fix 2 tests for offline execution
In `alt_registry::warn_for_unused_fields`, the second part of the test
runs on `--registry crates-io`, so it needs a local replacement url.
In `install::install_global_cargo_config`, it was adding to the "config"
file, but the `pkg` before it configured the dummy registry replacement
in "config.toml". So that replacement wasn't actually used, and if you
ran tests online it was trying to install `bar v0.1.1` from the real
registry! The filename is now fixed, and the test double-checks that
we're only trying to install the local `bar v0.0.1`.
In `alt_registry::warn_for_unused_fields`, the second part of the test
runs on `--registry crates-io`, so it needs a local replacement url.
In `install::install_global_cargo_config`, it was adding to the "config"
file, but the `pkg` before it configured the dummy registry replacement
in "config.toml". So that replacement wasn't actually used, and if you
ran tests online it was trying to install `bar v0.1.1` from the real
registry! The filename is now fixed, and the test double-checks that
we're only trying to install the local `bar v0.0.1`.
We allowed `[badges]` to inherit from `[workspace.package.badges]`
This was a bug:
- This was not specified in the RFC
- We did not document this
- Even if someone were to try to guess to use this, it is inconsistent
with how inheritance works because this should inherit from
`workspace.badges` instead of `workspace.package.badges`
While keeping in mind that `[badges]` is effectively deprecated.
In that context, I think its safe to break support for this without a
transition period.
Fixes#13643
During #13783, I had considered making the 2024 edition behavior a
"unused key" warning. However, I'm being too lazy in piping the data
through correctly (and a hard error might be better to help users
transition).
fix(toml): Report `_` fied variants (e.g. `dev_dependencies`) as deprecated
### What does this PR try to resolve?
This is prep for removing them in the 2024 Edition and is part of rust-lang/rust#123754 and #13629
This doesn't include 2024 Edition work because there is a risk of conflict with other work going on these areas.
This changes us from
- When using `-` and `_` variants: deprecated, will error some time
- Otherwise, nothing
To
- When using `-` and `_` variants: unused field warning
- When using only `_`: deprecation, will be removed in 2024
I decided to model this as an unused field warning because that is what this is and that is how any other use of `_` works. We might hard error during a transition period but I'd eventually want these to just make the code act like anything else in the end.
### How should we test and review this PR?
### Additional information
We still have `edition2024` guarding this.
Dealing with two feature flags to control behavior is messy. We just
need to make sure both get stabilized :).
feat(resolver): Add v3 resolver for MSRV-aware resolving
### What does this PR try to resolve?
This is a part of #9930 and is important for changing the default with the new edition.
### How should we test and review this PR?
### Additional information
Unused dependencies cleanup
The implementation of #12826 was used as a demonstration for #12235, in #13621. The demonstration implementation was far from ideal and was lacking a few features. This PR makes the implementation "feature complete", and fixes known bugs with the initial implementation.
fix 13773 - 'cargo build' fails when list_files() with gix is triggered
Fixes#13773.
### Tasks
* [x] reproduce issue with new test-case
* [x] update [fixed `gix-dir`](https://github.com/rust-lang/cargo/pull/13777) in Cargo.lock to turn test green
Scott Schafer
bors
Ed Page
Ian Jackson
Josh Stone
klensy
Sebastian Thiel