We already only partially check it and it has been a source of false
positives.
While there is trust in the job, contributors and maintainers go into
the job assuming there is a problem and it takes time to break that
assumption.
If we lose trust in the job, we then won't trust it when it fails for
other reasons.
This also increases the risk of us not seeing other problems
`bump-checks` is meant to find if the steps in the job get re-arranged
to make this one of the early ones.
fix(cargo-lints): Don't always inherit workspace lints
When working on changes for #13805, I noticed that we always passed the contents of `[workspace.lints.cargo]` into the currently implemented lints, even if `[lints]` was not specified or did not contain `workspace = true`. This PR makes it so we only pass in the workspace cargo lints if `[lints]` contains `workspace = true`.
You can verify this change by looking at the first commit, where I added a test showing the current behavior, and looking at the second commit and seeing the test output no longer shows a warning about specifying `im-a-teapot`.
Update SleepTraker returns_in_order unit test
This updates the `returns_in_order` SleepTracker unit test so that it is not so sensitive to how fast the system is running. Previously it assumed that the function calls would take less than a millisecond to finish, but that is not a valid assumption for a slow-running system.
I have changed it to simplify the test, with the assumption that it takes less than 30 seconds for it to run, which should have a safety margin of a few orders of magnitude.
fix(toml): Remove underscore field support in 2024
### What does this PR try to resolve?
This is part of the 2024 Edition and is part of rust-lang/rust#123754 and #13629
### How should we test and review this PR?
### Additional information
docs(ref): Index differences between virtual / real manifests
### What does this PR try to resolve?
For a user to read the reference and to understand when each type of workspace might be right for them, they have to know to also read the section on Package Selection.
This reframes the section on needing to set `resolver = "2"` to being about differences when there isn't a root package and extends it to summarize a part of Package Selection, linking out to it. The hope is that this will make it all of the differences more discoverable without retreading too much of the same ground within Reference-style documentation.
Part of #13580
### How should we test and review this PR?
### Additional information
r? `@weihanglo`
For a user to read the reference and to understand when each type of
workspace might be right for them, they have to know to also read the
section on Package Selection.
This reframes the section on needing to set `resolver = "2"` to being
about differences when there isn't a root package and extends it to
summarize a part of Package Selection, linking out to it.
The hope is that this will make it all of the differences more
discoverable without retreading too much of the same ground within
Reference-style documentation.
Part of #13580
The old statement that its a subset of `members` is incorrect because
some members can be inferred and not show up in `members`.
I tried to reword this to better convey the goal of what was being said
Add where lint was set
`rustc` and `clippy` both show why the lint was emitted and where the level was set the first time it was emitted for a package. We already showed why the list was being emitted but did not show where the lint level was set. This PR adds where the lint was set at.
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
