Build scripts need to know whether debug assertions are enabled to
properly configure dependencies with matching assertion behavior.
Previously, `CARGO_CFG_DEBUG_ASSERTIONS` was filtered out because the
cfg query to rustc doesn't include profile settings.
This PR manually sets `CARGO_CFG_DEBUG_ASSERTIONS` based on the
profile's `debug-assertions` setting, allowing build scripts to
configure dependencies appropriately.
FCP:
https://github.com/rust-lang/cargo/pull/16160#issuecomment-3458280652Closes#15760
### What does this PR try to resolve?
Having sections in the build performance chapter link out to their
issues is helpful for:
- giving hope that things will improve
- providing a place for people to subscribe to for updates
- raise visibility for ensuring we get appropriaet feedback (e.g. on
degrading the debugger experience)
Noticed this was missing while writing up about this new chapter on the
blog post.
### How to test and review this PR?
### What does this PR try to resolve?
The goal of this refactor is to separate data collection and
presentation,
so that we can replay an HTML report from log generated by
`-Zbuild-analysis`.
### How to test and review this PR?
Should have no user-facing change,
though I would encourage review to run `cargo build --timings`
and check if there is anything broken.
Add a test for https://github.com/rust-lang/rust/pull/146133. `cargo
+nightly-2025-08-29 test --test build-std -- lto` can reproduce the
regression.
This is not a bug from Cargo, but it requires `-Zbuild-std` in most use
cases.
The test case is from https://github.com/rust-lang/rust/issues/146109.
The point is that when rustc is invoked with -Clto=fat or -Clto=thin, it
should perform LTO with ALL bitcodes. However,
https://github.com/rust-lang/rust/pull/145368 emits bitcodes for
compiler_builtins but excludes it from LTO participation.
As a result, the compiler_builtins bitcodes library is passed to the
linker, but the linkers, such as the GNU ld or older versions of LLD,
are unable to process bitcodes.
_Thanks for the pull request 🎉!_
_Please read the contribution guide: <https://doc.crates.io/contrib/>._
### What does this PR try to resolve?
This PR fixes a bug for the nightly feature `bindeps`. Basically, if
- a package `foo` has an artifact dependency `artifact` with a specified
target TARGET_ARTIFACT different from host TARGET_HOST,
- `artifact` depends on proc macro `macro`,
- `macro` conditionally depends on `arch` on TARGET_HOST,
cargo build would panic on TARGET_HOST with the following error message:
```
did not find features for (PackageId { name: "arch", version: "0.0.1", source: "/Users/lencerf/Developer/cargo/target/tmp/cit/t0/foo/arch" }, ArtifactDep(CompileTarget { name: "x86_64-apple-darwin" })) within activated_features:
[
(
PackageId {
name: "foo",
version: "0.0.1",
source: "/Users/lencerf/Developer/cargo/target/tmp/cit/t0/foo",
},
NormalOrDev,
),
(
PackageId {
name: "macro",
version: "0.0.1",
source: "/Users/lencerf/Developer/cargo/target/tmp/cit/t0/foo/macro",
},
ArtifactDep(
CompileTarget {
name: "x86_64-apple-darwin",
},
),
),
(
PackageId {
name: "artifact",
version: "0.0.1",
source: "/Users/lencerf/Developer/cargo/target/tmp/cit/t0/foo/artifact",
},
ArtifactDep(
CompileTarget {
name: "x86_64-apple-darwin",
},
),
),
]
```
Similar panic happens when
- a package `foo` has an artifact dependency `artifact` with a specified
target TARGET_ARTIFACT different from host TARGET_HOST,
- `artifact` has a build dependency `builder`,
- `builder` conditionally depends on `arch` on TARGET_HOST.
From the above message, it is clear that proc macro `macro` was wrongly
associated with `FeaturesFor::ArtifactDep` instead of
`FeaturesFor::HostDep`. Package `arch` was later ignored because cargo
thought `macro` should be built for TARGET_ARTIFACT
(x86_64-apple-darwin), while `arch` was conditionally needed on
TARGET_HOST (aarch64-apple-darwin).
Similar analyses apply to the other test case.
This commit fixes 2 paths:
- when resolving features, if we encounter build dependencies or proc
macros, always associate them with `FeaturesFor::HostDep`.
- when deriving UnitFor for dependencies, stop propagating
artifact_target_for_features if the the dependency is a build dependency
or a proc macro.
### How to test and review this PR?
This PR contains 2 commits
- the first commit adds 2 test cases to reproduce the issue above. Since
they cannot pass now, they are marked with `#[should_panic]`
- the second commit fixes the bug and removes the `#[should_panic]` from
the 2 test cases.
`cargo test` can pass on each commit.
As reproduced in the 2 fixed test cases of this commit, cargo panicked
when
- a package `foo` has an artifact dependency `artifact` with a specified
target TARGET_ARTIFACT different from host TARGET_HOST,
- `artifact` depends on proc macro `macro`,
- `macro` conditionally depends on `arch` on TARGET_HOST,
with the following message
```
did not find features for (PackageId { name: "arch", version: "0.0.1", source: "/Users/lencerf/Developer/cargo/target/tmp/cit/t0/foo/arch" }, ArtifactDep(CompileTarget { name: "x86_64-apple-darwin" })) within activated_features:
[
(
PackageId {
name: "foo",
version: "0.0.1",
source: "/Users/lencerf/Developer/cargo/target/tmp/cit/t0/foo",
},
NormalOrDev,
),
(
PackageId {
name: "macro",
version: "0.0.1",
source: "/Users/lencerf/Developer/cargo/target/tmp/cit/t0/foo/macro",
},
ArtifactDep(
CompileTarget {
name: "x86_64-apple-darwin",
},
),
),
(
PackageId {
name: "artifact",
version: "0.0.1",
source: "/Users/lencerf/Developer/cargo/target/tmp/cit/t0/foo/artifact",
},
ArtifactDep(
CompileTarget {
name: "x86_64-apple-darwin",
},
),
),
]
```
From the above message, it is clear that proc macro `macro` was wrongly
associated with `FeaturesFor::ArtifactDep` instead of
`FeaturesFor::HostDep`. Package `arch` was later ignored because cargo
thought `macro` should be built for TARGET_ARTIFACT
(x86_64-apple-darwin), while `arch` was conditionally needed on
TARGET_HOST (aarch64-apple-darwin).
Similar analyses apply to the other test case.
This commit fixes 2 paths:
- when resolving features, if we encounter build dependencies or proc
macros, always associate them with `FeaturesFor::HostDep`.
- when deriving UnitFor for dependencies, stop propagating
artifact_target_for_features if the the dependency is a build
dependency or a proc macro.
Signed-off-by: Changyuan Lyu <changyuan.lv@gmail.com>
Add 2 test cases to reproduce a bug of `-Zbindeps`.
Basically, if
- a package `foo` has an artifact dependency `artifact` with a specified
target TARGET_ARTIFACT different from host TARGET_HOST,
- `artifact` depends on proc macro `macro`,
- `macro` conditionally depends on `arch` on TARGET_HOST,
cargo build would panic on TARGET_HOST with the following error message:
```
did not find features for (PackageId { name: "arch", version: "0.0.1", source: "/Users/lencerf/Developer/cargo/target/tmp/cit/t0/foo/arch" }, ArtifactDep(CompileTarget { name: "x86_64-apple-darwin" })) within activated_features:
[
(
PackageId {
name: "foo",
version: "0.0.1",
source: "/Users/lencerf/Developer/cargo/target/tmp/cit/t0/foo",
},
NormalOrDev,
),
(
PackageId {
name: "macro",
version: "0.0.1",
source: "/Users/lencerf/Developer/cargo/target/tmp/cit/t0/foo/macro",
},
ArtifactDep(
CompileTarget {
name: "x86_64-apple-darwin",
},
),
),
(
PackageId {
name: "artifact",
version: "0.0.1",
source: "/Users/lencerf/Developer/cargo/target/tmp/cit/t0/foo/artifact",
},
ArtifactDep(
CompileTarget {
name: "x86_64-apple-darwin",
},
),
),
]
```
Similar panic happens when
- a package `foo` has an artifact dependency `artifact` with a specified
target TARGET_ARTIFACT different from host TARGET_HOST,
- `artifact` has a build dependency `builder`,
- `builder` conditionally depends on `arch` on TARGET_HOST.
Signed-off-by: Changyuan Lyu <changyuan.lv@gmail.com>
Having sections in the build performance chapter link out to their
issues is helpful for:
- giving hope that things will improve
- providing a place for people to subscribe to for updates
- raise visibility for ensuring we get appropriaet feedback (e.g. on
degrading the debugger experience)
Noticed this was missing while writing up about this new chapter on the
blog post.
Partially adresses #16231.
### What does this PR try to resolve?
`cargo publish` will fail, if `--registry` is passed and that index
isn't included in `package.publish` in Cargo.toml. However, as described
in linked issue, `--index` bypasses that check and may cause unexpected
publication of packages.
This PR implements warning that is shown when `--index` and
`package.publish` is set at the same time.
Clarifies that yanking only affects Cargo's dependency resolution, not
crate availability.
Yanked crates remain fully downloadable, so yanking cannot prevent the
spread of leaked credentials.
Closes#16266
### What does this PR try to resolve?
Implementation for #5221, #15491
Tracking issues: #16270, #16271
Use cases:
- Improved reproduction steps using cargo scripts without including a
lockfile
- Debugging issues in the past
- Manual stop gap for #15973
This seemed like the shortest path to testing the proposed `pubtime`
index entries (#15491) so we can unblock other work on it like #15973.
While this has some big caveats, the design is straightforward.
In contrast, #15973 has a lot more design questions (is this a
resolver-wide setting or a per-registry setting, what formats are
accepted, etc) that could slow down development and testing `pubtime`.
### How to test and review this PR?
Unresolved questions (deferred to the tracking issues):
- How do we compensate for the caveats, with one option being to leave
this perma-unstable?
- How should we deal with Summary `pubtime` parse errors?
- How strict should we be on the Summary `pubtime` format?
- Should we offer a convenient way of getting a compatible timestamp?
Future possibilities:
- Ability to lock to a timestamp with `cargo update` updating the
timestamp (could be useful for cargo scripts)
Implementation for #5221
Use cases:
- Improved reproduction steps using cargo scripts without including a
lockfile
- Debugging issues in the past
- Manual stop gap for #15973
Unresolved questions:
- How do we compensate for the caveats, with one option being to leave
this perma-unstable?
- How should we deal with Summary `pubtime` parse errors?
- How strict should we be on the Summary `pubtime` format?
- Should we offer a convenient way of getting a compatible timestamp?
Future possibilities:
- Ability to lock to a timestamp with `cargo update` updating the
timestamp (could be useful for cargo scripts)
This seemed like the shortest path to testing the proposed `pubtime`
index entries so we can unblock other work on it like #15973.
While this has some big caveats, the design is straightforward.
In contrast, #15973 has a lot more design questions (is this a
resolver-wide setting or a per-registry setting, what formats are
accepted, etc) that could slow down development and testing `pubtime`.
### What does this PR try to resolve?
This PR modifies the locking logic to avoid locking `artifact-dir` for
check builds.
Part of #4282
Note: This change is **not** behind `-Zbuild-dir-new-layout` or
`-Zfine-grain-locking` unstable flags.
### How to test and review this PR?
See the tests included in the PR.
You can run `cargo check` to verify.
r? @epage
### What does this PR try to resolve?
This mtime shift for .rmeta is a workaround as rustc incremental build
since rust-lang/rust#114669 (1.90.0) skips unnecessary rmeta generation.
The situation is like this:
1. When build script execution's external dependendies
(rerun-if-changed, rerun-if-env-changed) got updated,
the execution unit reran and got a newer mtime.
2. rustc type-checked the associated crate, though with incremental
compilation, no rmeta regeneration. Its `.rmeta` stays old.
3. Run `cargo check` again. Cargo found build script execution had
a new mtime than existing crate rmeta, so re-checking the crate.
However the check is a no-op (input has no change), so stuck.
Fixes#16104
### How to test and review this PR?
Tests pass.
There is a reproduction in
<https://github.com/rust-lang/cargo/issues/16104#issuecomment-3530739039>,but
actually a minimal one is touching a file of build script dependency,
than `cargo check`. It'll easily get stuck.
This is an ugly workaround. And `-Zchecksum-freshness` doesn't help
because build script is involved.
This mtime shift for .rmeta is a workaround as rustc incremental build
since rust-lang/rust 114669 (1.90.0) skips unnecessary rmeta generation.
The situation is like this:
1. When build script execution's external dependendies
(rerun-if-changed, rerun-if-env-changed) got updated,
the execution unit reran and got a newer mtime.
2. rustc type-checked the associated crate, though with incremental
compilation, no rmeta regeneration. Its `.rmeta` stays old.
3. Run `cargo check` again. Cargo found build script execution had
a new mtime than existing crate rmeta, so re-checking the crate.
However the check is a no-op (input has no change), so stuck.
