### 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.
### What does this PR try to resolve?
This helps debug <https://github.com/rust-lang/cargo/issues/14955>.
### How should we test and review this PR?
While `check_repo_state` is the culprit, let's add some traces for
future.
### Additional information
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
```
### What does this PR try to resolve?
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)
Fixes#14346
### How should we test and review this PR?
Let's do an FCP.
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
```
### What does this PR try to resolve?
Blocked on <https://github.com/rust-lang/cargo/pull/14943> (or can just
merge this one).
Fixes#14935#14935 failed because since 125e873dffc4b68b263c5decd88750ec10fd441e
[`std_resolve`][1] only includes `sysroot` as primary package.
When any custom Cargo feature is provided via `-Zbuild-std-feature`,
the default feature set `panic-unwind` would be gone, so no
`panic_unwind` crate presents in `std_resolve`.
When then calling [`std_resolve.query`][2] with the default set of
crates from [`std_crates`][3], which automatically includes
`panic_unwind` when `std` presents, it'll result in spec not found
because `panic_unwind` was not in `std_resolve` anyway.
[1]:
addcc8ca71/src/cargo/core/compiler/standard_lib.rs (L96)
[2]:
addcc8ca71/src/cargo/core/compiler/standard_lib.rs (L158)
[3]:
addcc8ca71/src/cargo/core/compiler/standard_lib.rs (L156)
### How should we test and review this PR?
This patch is kinda a revert of 125e873dffc4b68b263c5decd88750ec10fd441e
in terms of the behavior.
With this, now `std_resolve` is always resolved to 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.
Note that when multiple `--target`s provided, if std is specified or
there
is one might support std, Cargo will always resolve std dep graph.
To test it manually, run
```
RUSTFLAGS="-C panic=abort" cargo +nightly-2024-12-15 b -Zbuild-std=std,panic_abort -Zbuild-std-features=panic_immediate_abort
```
change to this PR's cargo with the same nightly rustc, it would succeed.
I am a bit reluctant to add an new end-2end build-std test, but I still
did it.
A bit scared when mock-std gets out-of-sync of features in std in
rust-lang/rust.
### What does this PR try to resolve?
47c2095b1dd580a91e42cb6197b58a318526b8c4 didn't really fix the
flakiness.
Spun off from <https://github.com/rust-lang/cargo/pull/14938>
2a54190c9c789756d2281eefc856704e98c9941e
build-std tests use the users `CARGO_HOME` for downloading registry
dependencies of the standard library.
This reduces disk needs of the tests, speeds up the tests, and reduces
the number of network requests that could fail.
However, this means all of the tests access the same locks for the
package cache. In one test, we assert on the output and a `[BLOCKING]`
message can show up, depending on test execution time from concurrent
test runs.
We are going to hack around this by having the one test that asserts on
test output to use the standard `cargo-test-support` `CARGO_HOME`,
rather than the users `CARGO_HOME`. There will then only be one process
accessing the lock and no `[BLOCKING]` messages.
### How should we test and review this PR?
No more assertion errors like this:
```
---- test_proc_macro stdout ----
running `/home/runner/work/cargo/cargo/target/debug/cargo fetch -Zbuild-std -Zpublic-dependency`
running `/home/runner/work/cargo/cargo/target/debug/cargo test --lib -Zbuild-std -Zpublic-dependency`
thread 'test_proc_macro' panicked at tests/build-std/main.rs:394:10:
---- expected: tests/build-std/main.rs:388:27
++++ actual: stderr
1 + [BLOCKING] waiting for file lock on package cache
error: test failed, to rerun pass `-p cargo --test build-std`
2 + [BLOCKING] waiting for file lock on package cache
1 3 | [COMPILING] foo v0.0.0 ([ROOT]/foo)
2 4 | [FINISHED] `test` profile [unoptimized + debuginfo] target(s) in [ELAPSED]s
3 5 | [RUNNING] unittests src/lib.rs (target/debug/deps/foo-[HASH])
```
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.
This failed because since 125e873dffc4b68b263c5decd88750ec10fd441e
[`std_resolve`][1] only includes `sysroot` as primary package.
When any custom Cargo feature is provided via `-Zbuild-std-feature`,
the default feature set `panic-unwind` would be gone, so no
`panic_unwind` crate presents in `std_resolve`.
When then calling [`std_resolve.query`][2] with the default set of
crates from [`std_crates`][3], which automatically includes
`panic_unwind` when `std` presents, it'll result in spec not found
because `panic_unwind` was not in `std_resolve` anyway.
[1]: addcc8ca71/src/cargo/core/compiler/standard_lib.rs (L96)
[2]: addcc8ca71/src/cargo/core/compiler/standard_lib.rs (L158)
[3]: addcc8ca71/src/cargo/core/compiler/standard_lib.rs (L156)
See rust-lang/cargo#14935
47c2095b1dd580a91e42cb6197b58a318526b8c4 didn't really fix the flakiness.
build-std tests use the users `CARGO_HOME` for downloading registry
dependencies of the standard library. This reduces disk needs of the
tests, speeds up the tests, and reduces the number of network requests
that could fail.
However, this means all of the tests access the same locks for the
package cache. In one test, we assert on the output and a `[BLOCKING]`
message can show up, depending on test execution time from concurrent
test runs.
We are going to hack around this by having the one test that asserts
on test output to use the standard `cargo-test-support` `CARGO_HOME`,
rather than the users `CARGO_HOME`. There will then only be one process
accessing the lock and no `[BLOCKING]` messages.
<!--
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 changes the release trigger to only run when a tag matching the
pattern `0.*` is created. The intent is to allow us to create tags for
other crates that we may release out-of-band of the normal releases (and
maybe consider creating tags for all crates to make them easier to
find). For example, I would like to create `home-0.5.11` tags (and
earlier versions that were missed due to this trigger).
cc #14538
### What does this PR try to resolve?
This bug has been there since #14360
Found this when looking to change the normalization code for cargo
script. As a result, I also changed `cargo-util-schemas` in the hope
that grouping the fields would make the intent clearer. Since I was
already changing field order, I also re-ordered for my personal taste
(user facing features first)
### How should we test and review this PR?
### Additional information
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
