parallel compiler: async fns not reproducible #162202
Copy link
Copy link
Labels
A-async-awaitArea: Async & AwaitArea: Async & AwaitA-parallel-compilerArea: parallel compilerArea: parallel compilerA-reproducibilityArea: Reproducible / deterministic buildsArea: Reproducible / deterministic buildsC-bugCategory: This is a bug.Category: This is a bug.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Description
I tried this code:
async fn test1(_: &'_ u8) {}
async fn test2<'s>(_: &'s u8,) {}
fn main() {}rustc --edition=2024 -Zremap-cwd-prefix=reproducible_dir -Ccodegen-units=1 -Zthreads=30 --crate-type=lib --crate-name=test -o out ; md5sum out
I expected to see this happen:
constant md5sum
Instead, this happened:
the md5sum is flipflopping between d1afc31db4a80828c5c3937fae627a66 and 56d12483eea2eaaca0cd435f83439b59
Meta
rustc --version --verbose:
rustc 1.100.0-nightly (5db7f4be8 2026-09-01)
binary: rustc
commit-hash: 5db7f4be8a36c1b8ae19299469e2be2b0f052c21
commit-date: 2026-09-01
host: x86_64-unknown-linux-gnu
release: 1.100.0-nightly
LLVM version: 23.1.0
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
A-async-awaitArea: Async & AwaitArea: Async & AwaitA-parallel-compilerArea: parallel compilerArea: parallel compilerA-reproducibilityArea: Reproducible / deterministic buildsArea: Reproducible / deterministic buildsC-bugCategory: This is a bug.Category: This is a bug.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Activity
matthiaskrgr commentedon Sep 2, 2026
hmm the problem may be that RPIT already is not reproducible 🤔
[-]async fns not reproducible[/-][+]parallel compiler: async fns not reproducible[/+]susitsm commentedon Sep 8, 2026
I tracked down an issue with RPIT, not sure about the solution yet
The DefIndex of these anon associated types is nondeterministic
The DefIndex of RPITIT types is created lazily in
associated_type_for_impl_trait_in_implcalled from theassociated_types_for_impl_traits_in_trait_or_implquery which is called fromassociated_item_def_ids. Some of these are likely called in parallel during type checking, racing which assoc item gets DefIndex 18.susitsm commentedon Sep 8, 2026
There are more cases where
DefId-s are synthesized in queries:coroutine_by_move_body_def_idandintern_as_new_staticboth callcreate_def.coroutine_by_move_body_def_idand the RPITIT ones seem solvable by calling these queries in deterministic order.inter_as_new_staticis different. The function is part of const eval and takes anAllocIdas an input which is not deterministic AFAIK. There is a good chance this is related to #162203Rollup merge of rust-lang#162580 - susitsm:parallel-frontend-by-move-…
Rollup merge of rust-lang#162580 - susitsm:parallel-frontend-by-move-…
Unrolled build for #162580 in rollup 162640