Skip to content

Conversation

@weihanglo
Copy link
Member

@weihanglo weihanglo commented Jan 6, 2026

27 commits in 94c368ad2b9db0f0da5bdd8421cea13786ce4412..8c133afcd5e0d69932fe11f5907683723f8d361d
2025-12-26 19:39:15 +0000 to 2026-01-09 03:50:15 +0000

@rustbot
Copy link
Collaborator

rustbot commented Jan 6, 2026

Some changes occurred in src/tools/cargo

cc @ehuss

@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 6, 2026
@rustbot
Copy link
Collaborator

rustbot commented Jan 6, 2026

⚠️ Warning ⚠️

@rust-log-analyzer

This comment has been minimized.

@rustbot
Copy link
Collaborator

rustbot commented Jan 7, 2026

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

@rust-log-analyzer

This comment has been minimized.

@weihanglo
Copy link
Member Author

@bors r+ rollup=never p=1

@bors
Copy link
Collaborator

bors commented Jan 7, 2026

📌 Commit 69f8120 has been approved by weihanglo

It is now in the queue for this repository.

@bors
Copy link
Collaborator

bors commented Jan 7, 2026

🌲 The tree is currently closed for pull requests below priority 1000. This pull request will be tested once the tree is reopened.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 7, 2026
@rust-bors

This comment has been minimized.

rust-bors bot added a commit that referenced this pull request Jan 7, 2026
Update cargo submodule

19 commits in 94c368ad2b9db0f0da5bdd8421cea13786ce4412..623444427f04292f3a3c7eac560cfa65ba0bb88e
2025-12-26 19:39:15 +0000 to 2026-01-06 21:05:05 +0000
- docs(unstable): expand docs for `-Zbuild-analysis` (rust-lang/cargo#16476)
- test: add `-Zunstable-options` with custom targets (rust-lang/cargo#16467)
- feat(report): add cargo report rebuilds  (rust-lang/cargo#16456)
- feat(test-support): Use test name for dir when running tests (rust-lang/cargo#16121)
- refactor: Migrate some cases to expect/reason (rust-lang/cargo#16461)
- docs(build-script): clarify OUT_DIR is not cleaned between builds (rust-lang/cargo#16437)
- chore: Update dependencies (rust-lang/cargo#16460)
- Update handlebars to 6.4.0 (rust-lang/cargo#16457)
- chore(deps): update alpine docker tag to v3.23 (rust-lang/cargo#16454)
- Any build scripts can now use cargo::metadata=KEY=VALUE (rust-lang/cargo#16436)
- fix(log): add `dependencies` field to `UnitRegistered` (rust-lang/cargo#16448)
- Implement fine grain locking for `build-dir` (rust-lang/cargo#16155)
- feat(resolver): List features when no close match (rust-lang/cargo#16445)
- feat(report): new command `cargo report sessions` (rust-lang/cargo#16428)
- feat (patch): Display where the patch was defined in patch-related error messages (rust-lang/cargo#16407)
- test(build-rs): Reduce from 'build' to 'check' where possible (rust-lang/cargo#16444)
- feat(toml): TOML 1.1 parse support (rust-lang/cargo#16415)
- feat(report): support --manifest-path in `cargo report timings` (rust-lang/cargo#16441)
- fix(vendor): recursively filter git files in subdirectories (rust-lang/cargo#16439)

r? ghost
@rust-log-analyzer

This comment has been minimized.

@rust-bors rust-bors bot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jan 7, 2026
@rust-bors
Copy link
Contributor

rust-bors bot commented Jan 7, 2026

💔 Test for 709282b failed: CI. Failed jobs:

@ehuss
Copy link
Contributor

ehuss commented Jan 7, 2026

@ranger-ross It looks like rust-lang/cargo#16436 is causing some test failures. Can you take a look?

@ranger-ross
Copy link
Member

Sorry for the trouble here.

I was able to reproduced with following on master (1436cf98c)

cargo new foo
cd foo
cargo add cortex-m-semihosting
cargo build

Looking the the issue it seems to be an issue with the version comparison added here

d.version_req().matches(unit.pkg.version())

Printing the versions:

unit.pkg.version() = 0.5.0
d.version_req() = Req(VersionReq { comparators: [Comparator { op: GreaterEq, major: 0, minor: Some(5), patch: Some(8), pre: Prerelease("") }, Comparator { op: Less, major: 0, minor: Some(8), patch: None, pre: Prerelease("") }] })

So the resolved version is less than 0.5.8 required by the version_req.match(). This breaks my assumption as I thought the dependencies would always have at least 1 match...

To unblock this I can open a PR to revert this change for now? (Unless the y'all see an obvious fix that I am missing)

@weihanglo
Copy link
Member Author

@ranger-ross this might be the fix you were looking for:

diff --git a/src/cargo/core/compiler/custom_build.rs b/src/cargo/core/compiler/custom_build.rs
index 851b51018..16a2f4888 100644
--- a/src/cargo/core/compiler/custom_build.rs
+++ b/src/cargo/core/compiler/custom_build.rs
@@ -467,7 +467,7 @@ fn build_work(build_runner: &mut BuildRunner<'_, '_>, unit: &Unit) -> CargoResul
                 let Some(dependency) = unit.pkg.dependencies().iter().find(|d| {
                     d.package_name() == dep.unit.pkg.name()
                         && d.source_id() == dep.unit.pkg.package_id().source_id()
-                        && d.version_req().matches(unit.pkg.version())
+                        && d.version_req().matches(dep.unit.pkg.version())
                 }) else {
                     panic!(
                         "Dependency `{}` not found in `{}`s dependencies",

@ranger-ross
Copy link
Member

yikes... yeah this likely the problem. Good catch!
I that fixes the compilation issue in the reproduction case above.

I'll open a PR with this change.

@ranger-ross
Copy link
Member

raised rust-lang/cargo#16486

github-merge-queue bot pushed a commit to rust-lang/cargo that referenced this pull request Jan 8, 2026
…lection (#16486)

### What does this PR try to resolve?

Fixes a bug in the logic during (unit) dependency selection for build
scripts introduced in #16436

This was discovered while updating the submodule in rust-lang/rust
rust-lang/rust#150739

### How to test and review this PR?

```sh
cargo new foo
cd foo
cargo add cortex-m-semihosting
cargo build
```

I plan to add test case for this in a follow up PR, but raising the fix
PR to unblock the submodule update for now.

r? @weihanglo
@rust-bors rust-bors bot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 8, 2026
@weihanglo
Copy link
Member Author

@bors r+ rollup=never p=1

@rust-bors rust-bors bot removed the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Jan 8, 2026
@rust-bors
Copy link
Contributor

rust-bors bot commented Jan 8, 2026

💔 Test for 21c0a5c failed: CI. Failed jobs:

@weihanglo
Copy link
Member Author

Interesting…

  warning: no edition set: defaulting to the 2015 edition while the latest is 2024
      Updating crates.io index
       Locking 10 packages to latest compatible versions
        Adding aligned v0.2.0 (available: v0.4.3)
        Adding bare-metal v0.2.5 (available: v1.0.0)
   Downloading crates ...
    Downloaded bare-metal v0.2.5
    Downloaded vcell v0.1.3
    Downloaded aligned v0.2.0
    Downloaded find-msvc-tools v0.1.6
    Downloaded semver v0.9.0
    Downloaded volatile-register v0.2.2
    Downloaded semver-parser v0.7.0
    Downloaded rustc_version v0.2.3
    Downloaded cc v1.2.51
  
  thread 'main' (100165) panicked at src/tools/cargo/src/cargo/core/compiler/custom_build.rs:472:21:
  Dependency `compiler_builtins` not found in `bare-metal`s dependencies

@weihanglo
Copy link
Member Author

The test failed because it is a -Zbuild-std build, and Cargo attaches std root units as dependencies for each unit.

The dependency tree look like (constructed from --unit-graph, AI-assisted):

[9] cortex_m (0.5.0) - ROOT
├── [0] aligned (0.2.0)
│   ├── [5] compiler_builtins (0.1.160)
│   │   ├── [6] build_script_build
│   │   │   └── [7] build_script_build
│   │   │       └── (no dependencies)
│   │   └── [8] core (0.0.0)
│   └── [8] core (0.0.0)
├── [1] bare_metal (0.2.5)
│   ├── [2] build_script_build
│   │   ├── [3] build_script_build
│   │   │   └── [13] rustc_version (0.2.3)
│   │   │       └── [14] semver (0.9.0)
│   │   │           └── [15] semver_parser (0.7.0)
│   │   └── [6] build_script_build (shared)
│   ├── [5] compiler_builtins (0.1.160) (shared)
│   └── [8] core (0.0.0) (shared)
├── [5] compiler_builtins (0.1.160) (shared)
├── [8] core (0.0.0) (shared)
├── [10] build_script_build
│   ├── [6] build_script_build (shared)
│   └── [11] build_script_build
│       └── [4] cc (1.2.51)
│           ├── [12] find_msvc_tools (0.1.6)
│           └── [16] shlex (1.3.0)
└── [18] volatile_register (0.2.2)
    ├── [5] compiler_builtins (0.1.160) (shared)
    ├── [8] core (0.0.0) (shared)
    └── [17] vcell (0.1.3)
        ├── [5] compiler_builtins (0.1.160) (shared)
        └── [8] core (0.0.0) (shared)

@ranger-ross

I guess a simple fix would be putting .filter(|dep| !dep.unit.is_std) before the filter_map. It doesn't make sense that dependent have access to std's custom build metadata. Let me know if you don't time opening a PR.

@weihanglo
Copy link
Member Author

weihanglo commented Jan 9, 2026

It doesn't make sense that dependent have access to std's custom build metadata.

Actually, we might want to make sure that whether we has been exposing link metadata for std crates previously.

@ranger-ross
Copy link
Member

@weihanglo I am available to make that change.

Actually, we might want to make sure that whether we has been exposing link metadata for std crates previously.

Hmm good point, do std crates even use links? Given build std is unstable, maybe we add the .filter() so tests pass and document this in the build std tracking issue?

@weihanglo
Copy link
Member Author

weihanglo commented Jan 9, 2026

@weihanglo I am available to make that change.

Actually, we might want to make sure that whether we has been exposing link metadata for std crates previously.

Hmm good point, do std crates even use links? Given build std is unstable, maybe we add the .filter() so tests pass and document this in the build std tracking issue?

compiler-builtins does

And I don't know if any transitive dependencies also. I guess we shouldn't let metadata propagate across std_resolve / usr_resolve boundary.

@ranger-ross
Copy link
Member

And I don't know if any transitive dependencies also.

cargo::metadata env vars for links (and also non-links with -Zany-build-script-metadata) should only propagate to direct dependencies. (see this test)

@ranger-ross
Copy link
Member

I guess we shouldn't let metadata propagate across std_resolve / usr_resolve boundary.

I tend to think this as well. Having a clear boundary makes sense and we could always loosen it in the future if there is a strong usecase for this.

@weihanglo
Copy link
Member Author

And I don't know if any transitive dependencies also.

cargo::metadata env vars for links (and also non-links with -Zany-build-script-metadata) should only propagate to direct dependencies. (see this test)

Yeah I know. I meant if we skip all unit.is_std=true, dep link metadata may stop working within std graph.

@weihanglo
Copy link
Member Author

https://github.com/search?q=DEP_COMPILER_RT_COMPILER_RT&type=code

BTW rust-lang/rust itself used to use DEP_COMPILER_RT_COMPILER_RT, but can't find any reference right now in this repo.

I am good with having a boundary.

@ranger-ross
Copy link
Member

Actually, I don't think its very difficult to properly handle build-std.
If a package not present in Cargo.toml and its a std dependency, we just use the crate name since we know its not renamed.

let dependency_name = unit
    .pkg
    .dependencies()
    .iter()
    .find(|d| {
        d.package_name() == dep.unit.pkg.name()
            && d.source_id() == dep.unit.pkg.package_id().source_id()
            && d.version_req().matches(dep.unit.pkg.version())
    })
    .map(|d| d.name_in_toml())
    .unwrap_or_else(|| {
        if dep.unit.is_std {
            // If the depenency is a build-std dependency, it might not be in
            // Cargo.toml. If its not present, we simply use the package name as we
            // know its not renamed.
            dep.unit.pkg.name()
        } else {
            panic!(
                "Dependency `{}` not found in `{}`s dependencies",
                dep.unit.pkg.name(),
                unit.pkg.name()
            )
        }
    });

@ranger-ross
Copy link
Member

I went ahead and posted rust-lang/cargo#16489 with the snippet above.

Though if you'd prefer to go with a boundary instead, I'm fine with that as well.

@weihanglo
Copy link
Member Author

// If the depenency is a build-std dependency, it might not be in
// Cargo.toml. If its not present, we simply use the package name as we
// know its not renamed.

I don't know if this is true

core = { path = "../rustc-std-workspace-core", package = "rustc-std-workspace-core" }

wasip2 = { version = '0.14.4', features = [
'rustc-dep-of-std',
], default-features = false, package = 'wasi' }

@ranger-ross
Copy link
Member

ohhhhh, geez sorry 😅

github-merge-queue bot pushed a commit to rust-lang/cargo that referenced this pull request Jan 9, 2026
#16489)

### What does this PR try to resolve?

This PR fixes a regression found in
rust-lang/rust#150739 that was introduced in
#16436.

For `-Zbuild-std` std dependencies, we would panic due to the dependency
not being present in `Cargo.toml`.
~~This PR adds handling fallback to the `unit.pkg.name()` if the unit
both not present in `Cargo.toml` and `is_std`.~~ (see
#16489 (comment))

This PR ensures that metadata propagation is only allowed between
`std->std` crates and `non-std->non-std` crates.

### How to test and review this PR?

```
cargo new foo
cd foo
cargo add cortex-m
cargo -Zbuild-std build
```

Previously we panic with
```
thread 'main' (4072127) panicked at src/cargo/core/compiler/custom_build.rs:472:21:
Dependency `compiler_builtins` not found in `foo`s dependencies
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```

with this change we not compile successfully

r? @weihanglo
@rust-bors rust-bors bot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 9, 2026
@weihanglo
Copy link
Member Author

@bors r+ rollup=never p=1

@rust-bors rust-bors bot added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Jan 9, 2026
@rust-bors
Copy link
Contributor

rust-bors bot commented Jan 9, 2026

📌 Commit a97825c has been approved by weihanglo

It is now in the queue for this repository.

@rust-bors rust-bors bot removed the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Jan 9, 2026
@rust-bors
Copy link
Contributor

rust-bors bot commented Jan 9, 2026

🔒 Merge conflict

This pull request and the base branch diverged in a way that cannot
be automatically merged. Please rebase on top of the latest base
branch, and let the reviewer approve again.

How do I rebase?

Assuming self is your fork and upstream is this repository,
you can resolve the conflict following these steps:

  1. git checkout update-cargo (switch to your branch)
  2. git fetch upstream HEAD (retrieve the latest base branch)
  3. git rebase upstream/HEAD -p (rebase on top of it)
  4. Follow the on-screen instruction to resolve conflicts (check git status if you got lost).
  5. git push self update-cargo --force-with-lease (update this PR)

You may also read
Git Rebasing to Resolve Conflicts by Drew Blessing
for a short tutorial.

Please avoid the "Resolve conflicts" button on GitHub.
It uses git merge instead of git rebase which makes the PR commit history more difficult to read.

Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Cargo.lock conflict is
handled during merge and rebase. This is normal, and you should still perform step 5 to update this PR.

@weihanglo
Copy link
Member Author

#150739 (comment)

There should be no merge conflicts. Not sure what happened. cc @jieyouxu if you know something

@rust-bors
Copy link
Contributor

rust-bors bot commented Jan 9, 2026

⌛ Testing commit a97825c with merge a3f2d5a...

Workflow: https://github.com/rust-lang/rust/actions/runs/20856959263

rust-bors bot added a commit that referenced this pull request Jan 9, 2026
Update cargo submodule

27 commits in 94c368ad2b9db0f0da5bdd8421cea13786ce4412..8c133afcd5e0d69932fe11f5907683723f8d361d
2025-12-26 19:39:15 +0000 to 2026-01-09 03:50:15 +0000
- Isolate build script metadata progation between std and non-std crates (rust-lang/cargo#16489)
- Add Clippy like lint groups (rust-lang/cargo#16464)
- feat: in-memory only `Manifest` (rust-lang/cargo#16409)
- Fixed incorrect version comparision during build script dependency selection (rust-lang/cargo#16486)
- refactor: new type for unit index (rust-lang/cargo#16485)
- feat(test): Make CARGO_BIN_EXE_ available at runtime  (rust-lang/cargo#16421)
- fix(package): detect dirty files when run from workspace member (rust-lang/cargo#16479)
- fix(timing)!: remove `--timings=&lt;FMT&gt;` optional format values (rust-lang/cargo#16420)
- docs(unstable): expand docs for `-Zbuild-analysis` (rust-lang/cargo#16476)
- test: add `-Zunstable-options` with custom targets (rust-lang/cargo#16467)
- feat(report): add cargo report rebuilds  (rust-lang/cargo#16456)
- feat(test-support): Use test name for dir when running tests (rust-lang/cargo#16121)
- refactor: Migrate some cases to expect/reason (rust-lang/cargo#16461)
- docs(build-script): clarify OUT_DIR is not cleaned between builds (rust-lang/cargo#16437)
- chore: Update dependencies (rust-lang/cargo#16460)
- Update handlebars to 6.4.0 (rust-lang/cargo#16457)
- chore(deps): update alpine docker tag to v3.23 (rust-lang/cargo#16454)
- Any build scripts can now use cargo::metadata=KEY=VALUE (rust-lang/cargo#16436)
- fix(log): add `dependencies` field to `UnitRegistered` (rust-lang/cargo#16448)
- Implement fine grain locking for `build-dir` (rust-lang/cargo#16155)
- feat(resolver): List features when no close match (rust-lang/cargo#16445)
- feat(report): new command `cargo report sessions` (rust-lang/cargo#16428)
- feat (patch): Display where the patch was defined in patch-related error messages (rust-lang/cargo#16407)
- test(build-rs): Reduce from 'build' to 'check' where possible (rust-lang/cargo#16444)
- feat(toml): TOML 1.1 parse support (rust-lang/cargo#16415)
- feat(report): support --manifest-path in `cargo report timings` (rust-lang/cargo#16441)
- fix(vendor): recursively filter git files in subdirectories (rust-lang/cargo#16439)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants