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

@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

This comment has been minimized.

@rust-bors rust-bors bot added the merged-by-bors This PR was explicitly merged by bors. label Jan 9, 2026
@rust-bors
Copy link
Contributor

rust-bors bot commented Jan 9, 2026

☀️ Test successful - CI
Approved by: weihanglo
Pushing a3f2d5a to main...

@rust-bors rust-bors bot merged commit a3f2d5a into rust-lang:main Jan 9, 2026
12 checks passed
@rustbot rustbot added this to the 1.94.0 milestone Jan 9, 2026
@github-actions
Copy link
Contributor

github-actions bot commented Jan 9, 2026

What is this? This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing 1b39278 (parent) -> a3f2d5a (this PR)

Test differences

Show 22 test diffs

Stage 2

  • build_script::links_passes_env_vars_with_any_build_script_unstable_feature: [missing] -> pass (J0)
  • build_script::metadata_from_dep_kinds: [missing] -> pass (J0)
  • build_script::non_links_can_pass_env_vars: [missing] -> pass (J0)
  • build_script::non_links_can_pass_env_vars_direct_deps_only: [missing] -> pass (J0)
  • build_script::non_links_can_pass_env_vars_with_dep_renamed: [missing] -> pass (J0)
  • cargo_report_rebuilds::all_fresh: [missing] -> pass (J0)
  • cargo_report_rebuilds::basic_rebuild: [missing] -> pass (J0)
  • cargo_report_rebuilds::gated_stable_channel: [missing] -> pass (J0)
  • cargo_report_rebuilds::gated_unstable_options: [missing] -> pass (J0)
  • cargo_report_rebuilds::multiple_root_causes: [missing] -> pass (J0)
  • cargo_report_rebuilds::no_log: [missing] -> pass (J0)
  • cargo_report_rebuilds::no_log_for_the_current_workspace: [missing] -> pass (J0)
  • cargo_report_rebuilds::no_rebuild_data: [missing] -> pass (J0)
  • cargo_report_rebuilds::outside_workspace: [missing] -> pass (J0)
  • cargo_report_rebuilds::shared_dep_cascading: [missing] -> pass (J0)
  • cargo_report_rebuilds::with_dependencies: [missing] -> pass (J0)
  • cargo_report_rebuilds::with_manifest_path: [missing] -> pass (J0)
  • package::dirty_untracked_file_when_packaged_from_workspace_member: [missing] -> pass (J0)
  • rustc::rustc_with_print_cfg_config_toml_env: pass -> ignore (custom targets are unstable in rustc) (J0)
  • check_test_dir: [missing] -> pass (J1)

Additionally, 2 doctest diffs were found. These are ignored, as they are noisy.

Job group index

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard a3f2d5abe45a9acfaccbf09266b33e1fd7ab193e --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

  1. dist-aarch64-llvm-mingw: 5390.2s -> 6829.9s (+26.7%)
  2. dist-apple-various: 3232.8s -> 3906.6s (+20.8%)
  3. i686-gnu-2: 6141.5s -> 4914.4s (-20.0%)
  4. pr-check-1: 2027.6s -> 1685.3s (-16.9%)
  5. x86_64-gnu-stable: 9124.5s -> 7809.2s (-14.4%)
  6. test-various: 7805.7s -> 6732.9s (-13.7%)
  7. x86_64-gnu-gcc: 3853.1s -> 3358.4s (-12.8%)
  8. x86_64-gnu-tools: 3766.8s -> 3311.9s (-12.1%)
  9. dist-aarch64-apple: 6625.8s -> 7404.4s (+11.7%)
  10. x86_64-rust-for-linux: 3028.9s -> 2673.9s (-11.7%)
How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (a3f2d5a): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results (primary -1.7%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-1.7% [-2.0%, -1.4%] 2
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) -1.7% [-2.0%, -1.4%] 2

Cycles

Results (primary -2.2%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-2.2% [-2.2%, -2.2%] 1
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) -2.2% [-2.2%, -2.2%] 1

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 473.995s -> 473.694s (-0.06%)
Artifact size: 390.87 MiB -> 391.30 MiB (0.11%)

@weihanglo weihanglo deleted the update-cargo branch January 9, 2026 19:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

merged-by-bors This PR was explicitly merged by bors. 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.

7 participants