Skip to content

Fix parse_rustc_z_ls for deps without -HASH suffix - #2847

Closed
justdoGIT wants to merge 2 commits into
mozilla:mainfrom
justdoGIT:fix/rustc-z-ls-no-hash-dep
Closed

justdoGIT wants to merge 2 commits into
mozilla:mainfrom
justdoGIT:fix/rustc-z-ls-no-hash-dep

Conversation

@justdoGIT

Copy link
Copy Markdown

Summary

Fixes #2846

parse_rustc_z_ls misparses dependency lines from rustc -Z ls=root when a crate appears without a -${HASH} suffix. The malformed dependency name never matches during crate_link_paths scanning, so the dep's rmeta is not packaged for the distributed worker, and the worker fails with:

error[E0463]: can't find crate for `crc_fast` which `xai_file_utils` depends on

Root cause

Modern rustc emits extended metadata per dependency line:

=External Dependencies=
1 std-453218b5e9634890 hash c76be37... host_hash None kind Unconditional public
2 crc_fast hash 05bce60290e56777e3ae6d3ddcc01e6c host_hash None kind Unconditional public
3 crc-8c7d86e779319534 hash 49e85fac... host_hash None kind Unconditional public

Line 2 (crc_fast) has no -${HASH} suffix; line 3 (crc-8c7d...) does.

parse_rustc_z_ls does line.splitn(2, ' ') which splits on the first space, so libstring becomes the entire trailing metadata ("crc_fast hash 05bce6... host_hash None kind Unconditional public"). The subsequent rsplitn(2, '-') finds no - and libname becomes the whole string.

When RustInputsPackager scans -L paths, it parses each rmeta filename (e.g. libcrc_fast-c6657c97868f5464.rmeta) and extracts "crc_fast", but dep_crate_names contains the broken "crc_fast hash 05bce6..." — no match. The rmeta is silently skipped, not sent to the worker, and rustc on the worker fails with E0463.

The fix

Take only the first whitespace-delimited token of libstring before the existing rsplitn('-') logic runs, so crates with and without a -${HASH} suffix both resolve to the bare crate name:

let libstring = line_splits
    .next()
    .context("No lib string on line from rustc -Z ls")?;
// The libstring may contain additional metadata after the crate name
// (e.g., "crc_fast hash 05bce6... host_hash None kind Unconditional public"
// when the crate has no -HASH suffix). Take only the first
// whitespace-delimited token so rsplitn('-') below operates on just
// the crate name, not the entire trailing metadata.
let libstring = libstring
    .split_whitespace()
    .next()
    .context("No lib string on line from rustc -Z ls")?;

This preserves the existing behavior for deps with a -${HASH} suffix (rsplitn('-') still splits std-453218b5e9634890 → std).

Test

Added test_parse_rustc_z_ls_modern_no_hash_suffix which feeds the parser a modern -Z ls output containing both a no-suffix dep (crc_fast) and a suffix dep (crc-8c7d...), and asserts each resolves to the bare crate name. This test fails on the unfixed parser (the crc_fast entry becomes the entire metadata string) and passes with the fix.

Checklist

  • Added a regression test covering the no-hash-suffix case
  • Existing test_parse_rustc_z_ls_pre_1_55 and test_parse_rustc_z_ls_post_1_55 still pass (old format deps also take the first token correctly)

Modern rustc (1.75+) emits extended metadata per dependency line in
`rustc -Z ls=root` output:

  N libname[-hash] hash HASH host_hash ... kind ... public

Crates built without a content hash suffix (e.g. crc_fast, a
build-script artifact) appear as:

  N crc_fast hash 05bce6... host_hash None kind Unconditional public

parse_rustc_z_ls used splitn(2, ' ') which yields libstring as the
entire trailing metadata ("crc_fast hash 05bce6... host_hash ...").
The subsequent rsplitn(2, '-') finds no '-' and libname becomes the
whole string, so it never matches the bare "crc_fast" parsed from
rmeta filenames during crate_link_paths scanning.

The unmatched dep is silently skipped, its rmeta is not packaged for
the dist worker, and the worker fails with E0463: can't find crate
for `crc_fast`.

Fix: take only the first whitespace-delimited token of libstring
before the existing rsplitn('-') logic runs, so crates with and
without a -HASH suffix both resolve to the bare crate name.

Signed-off-by: KK <pandeykamal13526@gmail.com>
Copilot AI lite review requested due to automatic review settings September 11, 2026 09:50

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟢 Approval recommended

The fix and regression coverage address the reported dependency-packaging failure with no unresolved review issues.

Pull request overview

This pull request fixes parsing of Rust dependencies without -HASH suffixes, ensuring required metadata is packaged for distributed builds.

Changes:

  • Parses only the first crate-name token.
  • Adds regression coverage for hashed and unhashed dependencies.
File summaries
File Description
src/compiler/rust.rs Fixes dependency parsing and adds focused tests.
Review details
  • Files reviewed: 1/1 changed files
  • Comments generated: 0
  • Review effort level: Lite

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

@codecov-commenter

codecov-commenter commented Sep 11, 2026 •

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 67.69%. Comparing base (4ffa89b) to head (f7d27e5).

❗ There is a different number of reports uploaded between BASE (4ffa89b) and HEAD (f7d27e5). Click for more details.

HEAD has 8 uploads less than BASE
Flag BASE (4ffa89b) HEAD (f7d27e5)
14 6
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2847      +/-   ##
==========================================
- Coverage   76.14%   67.69%   -8.46%     
==========================================
  Files          72       72              
  Lines       39807    38627    -1180     
==========================================
- Hits        30313    26147    -4166     
- Misses       9494    12480    +2986     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

The RustInputsPackager scans crate_link_paths for dependency rmeta
and rlib files, extracting the crate name from each filename via
rsplitn(2, '-'). This assumes every file has a -<metadata-hash>
suffix. When a file has no hash (e.g. libcrc_fast.rmeta produced by
a crate with crate-type = ["lib", "cdylib", "staticlib"]),
rsplitn yields a single element and the code hits continue, skipping
the file entirely.

The file is never packaged and sent to the dist worker, which then
fails with E0463: can't find crate for crc_fast.

Extract the crate-name-and-extension logic into a testable helper,
crate_name_and_ext_from_lib_path, that uses file_stem() to strip the
extension before rsplitn, then falls back to the whole stem as the
libname when no - separator is found.

Signed-off-by: KK <pandeykamal13526@gmail.com>
@justdoGIT

Copy link
Copy Markdown
Author

Superseded by #2850 which consolidates all fixes onto a single branch.

@justdoGIT justdoGIT closed this Sep 11, 2026
@justdoGIT
justdoGIT deleted the fix/rustc-z-ls-no-hash-dep branch September 11, 2026 10:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

parse_rustc_z_ls misparses deps without -HASH suffix → E0463 on dist workers

3 participants