The main benefit is that it won't facilitate hangs due to attempts
to read from untrackable directory entries, like names pipes or
sockets.
Related to https://github.com/GitoxideLabs/gitoxide/pull/1629
### What does this PR try to resolve?
This PR is resolving an
[issue](https://github.com/rust-lang/cargo/issues/14776#issuecomment-2515017963)
where `cargo doc --open --examples` does not give a clear message when
the examples file is given to it.
I changed the message from `no crates with documentation` in the
[cargo_doc.rs](58b2d609ec/src/cargo/ops/cargo_doc.rs (L62))
and
[doc.rs](58b2d609ec/tests/testsuite/doc.rs (L1504))
to `requested crate documentation is not available to open`. Now it
becomes easy for the user to understand what they're missing.
Fixes#14776
### How should we test and review this PR?
Here is the command through which you can test this change:
`cargo test SNAPSHOTS=overwrite -- doc::open_no_doc_crate`
<!--
Thanks for submitting a pull request 🎉! Here are some tips for you:
* If this is your first contribution, read "Cargo Contribution Guide"
first:
https://doc.crates.io/contrib/
* Run `cargo fmt --all` to format your code changes.
* Small commits and pull requests are always preferable and easy to
review.
* If your idea is large and needs feedback from the community, read how:
https://doc.crates.io/contrib/process/#working-on-large-features
* Cargo takes care of compatibility. Read our design principles:
https://doc.crates.io/contrib/design.html
* When changing help text of cargo commands, follow the steps to
generate docs:
https://github.com/rust-lang/cargo/tree/master/src/doc#building-the-man-pages
* If your PR is not finished, set it as "draft" PR or add "WIP" in its
title.
* It's ok to use the CI resources to test your PR, but please don't
abuse them.
### What does this PR try to resolve?
Explain the motivation behind this change.
A clear overview along with an in-depth explanation are helpful.
You can use `Fixes #<issue number>` to associate this PR to an existing
issue.
### How should we test and review this PR?
Demonstrate how you test this change and guide reviewers through your
PR.
With a smooth review process, a pull request usually gets reviewed
quicker.
If you don't know how to write and run your tests, please read the
guide:
https://doc.crates.io/contrib/tests
### Additional information
Other information you want to mention in this PR, such as prior arts,
future extensions, an unresolved problem, or a TODO list.
-->
### What does this PR try to resolve?
Dirty file paths in the original message were stripped relative to
package root.
User is not able to know the full path to find dirty files.
This PR makes it relative to git workdir.
### How should we test and review this PR?
This was found during #14962
### What does this PR try to resolve?
Flatten code with let-else for easier reasoning of exit of
`check_repo_state` function.
### How should we test and review this PR?
This also adds some more debug logs.
Shouldn't affect any real production behavior.
stdlib crates get a SourceId which has an absolute path pointing into
the sysroot. This makes the metadata hash change depending on where
you've installed Rust. This is causing problems because the different
hashes snowball into the optimizer making different decisions which ends
up changing the binary size.
(Some context: at work we're working with embedded devices with little
flash storage so it often happens that a binary builds locally and then
fails to fit in flash in CI, just because CI has installed rustc to a
different path. Improving binary size is *not* a goal of this PR, after
the fix the size will be whatever, but at least it won't change based on
the rustc path anymore)
Overview of the fix:
- For libstd crates, the metadata hash now contains the path relative to
the sysroot, instead of the absolute path.
- The absolute path is still hashed into the fingerprint (not the
metadata) so moving the rustc installation triggers a rebuild. This
ensures stdlib crates are rebuilt when upgrading nightly versions.
- The rustc version is still hashed into the metadata as usual, so
upgrading Rust releases (not nightly versions) does cause a metadata
change.
Repro of the bug:
```
$ git clone https://github.com/embassy-rs/embassy --branch cargo-nondet-repro
$ cd embassy/
$ cd examples/nrf52840
$ RUSTUP_HOME=~/.rustup1 cargo build --release --bin wifi_esp_hosted
....
Finished `release` profile [optimized + debuginfo] target(s) in 13.33s
$ llvm-size target/thumbv7em-none-eabi/release/wifi_esp_hosted
text data bss dec hex filename
114500 80 48116 162696 27b88 target/thumbv7em-none-eabi/release/wifi_esp_hosted
$ RUSTUP_HOME=~/.rustup2 cargo build --release --bin wifi_esp_hosted
....
Finished `release` profile [optimized + debuginfo] target(s) in 9.64s
$ llvm-size target/humbv7em-none-eabi/release/wifi_esp_hosted
text data bss dec hex filename
114272 80 48116 162468 27aa4 target/thumbv7em-none-eabi/release/wifi_esp_hosted
```
This was always enabled on nightly since 1.83-nightly (2024-09).
We have no feedback since then, so assume it is a low-impact change.
This stabilization is targeted at 1.85 (2025-02-20)
stdlib crates get a SourceId which has an absolute path pointing into the sysroot. This
makes the metadata hash change depending on where you've installed Rust. This is causing
problems because the different hashes snowball into the optimizer making different
decisions which ends up changing the binary size.
(Some context: at work we're working with embedded devices with little flash storage
so it often happens that a binary builds locally and then fails to fit in flash in CI,
just because CI has installed rustc to a different path. Improving binary size is
*not* a goal of this PR, after the fix the size will be whatever, but at least it
won't change based on the rustc path anymore)
Overview of the fix:
- For libstd crates, the metadata hash now contains the path relative to the sysroot, instead of the absolute path.
- The absolute path is still hashed into the fingerprint (not the metadata) so moving the rustc installation triggers a rebuild. This ensures stdlib crates are rebuilt when upgrading nightly versions.
- The rustc version is still hashed into the metadata as usual, so upgrading Rust releases (not nightly versions) does cause a metadata change.
Repro of the bug:
```
$ git clone https://github.com/embassy-rs/embassy --branch cargo-nondet-repro
$ cd embassy/
$ cd examples/nrf52840
$ RUSTUP_HOME=~/.rustup1 cargo build --release --bin wifi_esp_hosted
....
Finished `release` profile [optimized + debuginfo] target(s) in 13.33s
$ llvm-size target/thumbv7em-none-eabi/release/wifi_esp_hosted
text data bss dec hex filename
114500 80 48116 162696 27b88 target/thumbv7em-none-eabi/release/wifi_esp_hosted
$ RUSTUP_HOME=~/.rustup2 cargo build --release --bin wifi_esp_hosted
....
Finished `release` profile [optimized + debuginfo] target(s) in 9.64s
$ llvm-size target/humbv7em-none-eabi/release/wifi_esp_hosted
text data bss dec hex filename
114272 80 48116 162468 27aa4 target/thumbv7em-none-eabi/release/wifi_esp_hosted
```
This is kinda a revert of 125e873dffc4b68b263c5decd88750ec10fd441e
in terms of the behavior.
After this, now `std_resolve` is always resolved by the same set of
packages that Cargo will use to generate the unit graph, (technically
the same set of crates + `sysroot`), by sharing the same set of primary
packages via `std_crates` functions.
I found a bug in the manifest parser and figured this would help make it
more obvious.
Since I was already changing the order, I figure I'm make things a
little more logical (user-facing first, implementtion details later)
### What does this PR try to resolve?
While #14897 reported packages with an unsupported index schema version,
that only worked if the changes in the schema version did not cause
errors in deserializing `IndexPackage` or in generating a `Summary`.
This extends that change by recoverying on error with a more lax,
incomplete parse of `IndexPackage` which should always generate a valid
`Summary`.
To help with a buggy Index, we also will report as many as we can.
This does not provide a way to report to users or log on cache reads if
the index entry is not at least `{"name": "<string>", "vers":
"<semver>"}`.
Fixes#10623Fixes#14894
### How should we test and review this PR?
My biggest paranoia is some bad interaction with the index cache
including more "invalid" index entries.
That should be ok as we will ignore the invalid entry in the cache when
loading it.
Ignoring of invalid entries dates back to #6880 when the index cache was
introduced.
### Additional information
While #14897 reported packages with an unsupported index schema version,
that only worked if the changes in the schema version did not cause
errors in deserializing `IndexPackage` or in generating a `Summary`.
This extends that change by recoverying on error with a more lax,
incomplete parse of `IndexPackage` which should always generate a valid
`Summary`.
To help with a buggy Index, we also will report as many as we can.
This does not provide a way to report to users or log on cache reads if
the index entry is not at least `{"name": "<string>", "vers": "<semver>"}`.
As a side effect, the index cache will include more "invalid" index
entries.
That should be ok as we will ignore the invalid entry in the cache when
loading it.
Ignoring of invalid entries dates back to #6880 when the index cache was
introduced.
Fixes#10623Fixes#14894
### What does this PR try to resolve?
The user likely intended what they said and we should tell them why it
didn't work.
Rejected versions also imply alt versions below them.
Fixes#4260
In changing the errors from alt-versions to rejected-versions, I found
part of the old error message was better and changed the message
introduced in #14897 from matching alt-names to alt-versions.
This includes the test for #14921. The "fix" was done before this
because as it was part of the refactors in prep for this.
### How should we test and review this PR?
### Additional information
Next steps after this are to still produce an
`IndexSummary::Unsupported` even if there are deserialization errors, so
long as we know the name and version which should take care of #10623
and #14894.
I'm writing a compatibility layer between the cargo and meson build
systems.
This change allows me to plumb that through better :)
<!--
Thanks for submitting a pull request 🎉! Here are some tips for you:
* If this is your first contribution, read "Cargo Contribution Guide"
first:
https://doc.crates.io/contrib/
* Run `cargo fmt --all` to format your code changes.
* Small commits and pull requests are always preferable and easy to
review.
* If your idea is large and needs feedback from the community, read how:
https://doc.crates.io/contrib/process/#working-on-large-features
* Cargo takes care of compatibility. Read our design principles:
https://doc.crates.io/contrib/design.html
* When changing help text of cargo commands, follow the steps to
generate docs:
https://github.com/rust-lang/cargo/tree/master/src/doc#building-the-man-pages
* If your PR is not finished, set it as "draft" PR or add "WIP" in its
title.
* It's ok to use the CI resources to test your PR, but please don't
abuse them.
### What does this PR try to resolve?
Explain the motivation behind this change.
A clear overview along with an in-depth explanation are helpful.
You can use `Fixes #<issue number>` to associate this PR to an existing
issue.
### How should we test and review this PR?
Demonstrate how you test this change and guide reviewers through your
PR.
With a smooth review process, a pull request usually gets reviewed
quicker.
If you don't know how to write and run your tests, please read the
guide:
https://doc.crates.io/contrib/tests
### Additional information
Other information you want to mention in this PR, such as prior arts,
future extensions, an unresolved problem, or a TODO list.
-->
This has been around since #12224 and isn't in the RFC, so its being
removed.
This is part of #12207.
<!--
Thanks for submitting a pull request 🎉! Here are some tips for you:
* If this is your first contribution, read "Cargo Contribution Guide"
first:
https://doc.crates.io/contrib/
* Run `cargo fmt --all` to format your code changes.
* Small commits and pull requests are always preferable and easy to
review.
* If your idea is large and needs feedback from the community, read how:
https://doc.crates.io/contrib/process/#working-on-large-features
* Cargo takes care of compatibility. Read our design principles:
https://doc.crates.io/contrib/design.html
* When changing help text of cargo commands, follow the steps to
generate docs:
https://github.com/rust-lang/cargo/tree/master/src/doc#building-the-man-pages
* If your PR is not finished, set it as "draft" PR or add "WIP" in its
title.
* It's ok to use the CI resources to test your PR, but please don't
abuse them.
### What does this PR try to resolve?
Explain the motivation behind this change.
A clear overview along with an in-depth explanation are helpful.
You can use `Fixes #<issue number>` to associate this PR to an existing
issue.
### How should we test and review this PR?
Demonstrate how you test this change and guide reviewers through your
PR.
With a smooth review process, a pull request usually gets reviewed
quicker.
If you don't know how to write and run your tests, please read the
guide:
https://doc.crates.io/contrib/tests
### Additional information
Other information you want to mention in this PR, such as prior arts,
future extensions, an unresolved problem, or a TODO list.
-->
### What does this PR try to resolve?
This helps `-Ztrim-paths` build a stable cross-platform path for the
registry and git sources. Sources files then can be found from the same
path when debugging.
It also helps cache registry index all at once for all platforms,
for example the use case in
https://github.com/rust-lang/cargo/issues/14795
(despite they should use `cargo vendor` instead IMO).
Some caveats:
* Newer cargo will need to re-download files for global caches
(index files, git/registry sources).
The old cache is still kept and used when running with older cargoes.
* Absolute paths on windows iarenot really covered by the
"cross-platform" hash,
because path prefix components like `C:` are always there.
That means hashes of some sources kind,
like local registry and local path,
are not going to be real cross-platform stable.
#### Security concern
There might be hash collisions if you have two registries under the same
domain. This won't happen to crates.io, as the infra would have to
intentionally put another registry on index.crates.io to collide.
We don't consider this is an actual threat model, so we are not going to
use any cryptographically secure hash algorithm like BLAKE3.
At least, the current unstable SipHash isn't in a better situation.
We might switch to a cryptographic secure one when needed.
See also
<https://github.com/rust-lang/cargo/issues/13171#issuecomment-2181465128>
### How should we test and review this PR?
We have an FCP in
<https://github.com/rust-lang/cargo/issues/14795#issuecomment-2498446176>.
This PR implements the proposal,
The path-length concern in
<https://github.com/rust-lang/cargo/issues/14795#issuecomment-2532076078>
is automatically addressed
because we don't need cryptographically secure hash for now.
### Additional information
See more information and benchmark results in
<https://github.com/rust-lang/cargo/pull/14116>.
When I copy/pasted the alternative-names code, I didn't notice that the
wildcard dependency was used.
This does not have a test yet because overly-constrictive dep specs have
higher precedence atm (which I plan to also fix).
