### What does this PR try to resolve?
This fills a whole in our coverage of dependency resolution by
specifying how a `Cargo.lock` impacts it.
### How to test and review this PR?
I put it after version numbers and version requirements as it builds on
those two topics.
Unsure whether this fully resolves the concern from #15587 of users
coming from other ecosystems that have been burned by library lockfiles
affecting them to know that they won't be subject to that.
### What does this PR try to resolve?
I occasionally open PRs in my fork to test CI for work in progress
changes. (Trying to avoid spamming notifications to the t-cargo members)
The `check-version-bump` job [makes
assumptions](https://github.com/rust-lang/cargo/blob/master/crates/xtask-bump-check/src/xtask.rs#L326)
that the fork has an up to date list of release tags.
My fork (and I am guessing most others) does not contain the release
tags so this CI job fails, which is a minor papercut.
My solution is to only run `check-version-bump` in PRs to
`rust-lang/cargo` and skip in forks.
### How to test and review this PR?
* Verify that the CI job runs in this PR.
* I checked that job was skipped in my fork in
https://github.com/ranger-ross/cargo/actions/runs/17678491699/job/50246604369?pr=8
Inspired by https://github.com/rust-lang/cargo/pull/15138 , this
eliminates the last three instances.
Also rephrase a comment that implied the use of "did you mean"
suggestions. Fix an adjacent typo in that comment as well.
I put it after version numbers and version requirements as it builds on
those two topics.
Unsure whether this fully resolves the concern from #15587 of users
coming from other ecosystems that have been burned by library lockfiles
affecting them to know that they won't be subject to that.
The current wording (from #14839) makes it sound like new Cargo doesn't care about the
`features` entries when in reality Cargo does care still, the field is
just defaulted.
Closes#15408
Our options are:
- Not offer these completions
- Hide them
- De-prioritize them
Since someone could be using `--package`, I felt de-prioritizing would
give the best experience.
### What does this PR try to resolve?
Passing a package to `--package` is for workspace members; we need to
pass it to `--invert`.
### How to test and review this PR?
This is part of #14993
While I think we should instead improve the `cargo tree` command to help
users with `--all-features`, we can at least take the other improvement
from #14991.
### What does this PR try to resolve?
Use ellipses when truncating progress instead of three periods. While
this allows an extra two characters to fit on screen, the main
motivation it to reduce the visual quirkiness or the resulting output.
### How to test and review this PR?
This applies the review feedback left in #15330Closes#15330
Use ellipses when truncating progress instead of three periods. While
this allows an extra two characters to fit on screen, the main
motivation it to reduce the visual quirkiness or the resulting output.
Closes#15330
### What does this PR try to resolve?
This attempts to complete the autocompleter for `cargo build --features
<TAB>`, `cargo run --features <TAB>`
It loads all the features that are there in the profile section of
Cargo.toml
Related to #14520
### How should we test and review this PR?
by running `cargo build --features <TAB>`, `cargo run --features <TAB>`
### What does this PR try to resolve?
Switches a multi-line note to use annotate_snippet directly in prep for
#15917 where these extra lines will be aligned with the first line.
### How to test and review this PR?
### Notes
Unsure if this should be two groups or one group with a message.
If its one group, then we'll have a decorative line and then the `help:`
will be further indented.
I went with what is closer to how we do things today. We can always
re-evaluate at a later point.
### What does this PR try to resolve?
Pull
<71eb84f21a/src/doc/README.md>
into our contributor guide for visibility.
Also a writing guideline is added to the chapter, as well as some minor
polish.
This is created after seeing the contributing frictions in
<https://github.com/rust-lang/cargo/pull/15838#issuecomment-3194614286>.
### How to test and review this PR?
```
mdbook serve src/doc/contrib
```
Unsure if this should be two groups or one group with a message.
If its one group, then we'll have a decorative line and then the `help:`
will be further indented.
I went with what is closer to how we do things today. We can always
re-evaluate at a later point.
### What does this PR try to resolve?
Ooch our way towards rustc's quality of error reporting to make up for
the fact that users won't see most frontmatter rustc error messages.
### How to test and review this PR?
Several parts of this are not ideal yet
- Frontmatter close should show the open and show the EOF, instead of
pointing at the open
- Trailing content on close will usually have a newline
- Multiple frontmatters should show the original frontmatter
- Some content, like supported infostrings, should go in a help
- Ideally we try to recover on no closing and instead point out a
mismatched open/close
But this is still an improvement over nothing!
### What does this PR try to resolve?
#15928 removed the fix from #13488 which breaks rust-lang/rust. This
fixes that and makes the test less brittle for the future.
### How to test and review this PR?
### What does this PR try to resolve?
I got confused by this when refreshing myself on the changelog in prep
for the 1.90 release.
### How to test and review this PR?
### What does this PR try to resolve?
This is a follow-up of <https://github.com/rust-lang/cargo/pull/15935>.
Before this Cargo invokes syscalls and check whether it gets ENOTSUP to
determine flock is unsupported. However, now the "unsupported platforms"
are pre-defined by libstd. Cargo should perhaps return unsupported if a
platform is marked unsupported by libstd.
Without this, some people on Termux may be affected I guess?
See
e9b6085088/library/std/src/sys/fs/unix.rs (L1395-L1410)
Before this Cargo invokes syscalls and check whether it gets ENOTSUP to
determine flock is unsupported. However, now the "unsupported platforms"
are pre-defined by libstd [1]. Cargo should perhaps return unsupported
if a platform is marked unsupported by libstd.
Without this, some people on Termux may be affected I guess?
[1]: e9b6085088/library/std/src/sys/fs/unix.rs (L1395-L1410)
### What does this PR try to resolve?
As this is an unordered test, sometimes snapshot updating can mess up
the line order.
### How to test and review this PR?
Several parts of this are not ideal yet
- Frontmatter close should show the open and show the EOF, instead of
pointing at the open
- Trailing content on close will usually have a newline
- Multiple frontmatters should show the original frontmatter
- Some content, like supported infostrings, should go in a help
- Ideally we try to recover on no closing and instead point out a
mismatched open/close
But this is still an improvement over nothing!
