Promoting Parallel Front End

[nikomatsakis]

Metadata
Point of contact	@SparrowLii
Team(s)	compiler
Goal document	2025h1/parallel-front-end

Summary

Continue to parallelize front-end stabilization and performance improvements, continuing from the 2024h2 goal.

Tasks and status

• Implementation (@SparrowLii)
• Author tests (@SparrowLii)
• Discussion and moral support (compiler )

[nikomatsakis]

This issue is intended for status updates only.

For general questions or comments, please contact the owner(s) directly.

[SparrowLii]

• Key developments: *
  Use ui test to locate and solve the ICE problem of parallelfront end
  Discussed strategies for customizing and enhancing the compiler testing suit to address hard-to-reproduce bugs
• Blockers: 
  Many deadlock issues are difficult to reproduce and resolve
• Help wanted:
  Help test the deadlock code in the issue list and try to reproduce the issue

[SparrowLii]

• Key developments: *
  Add the cases in the issue list to the UI test to reproduce the bug or verify the non-reproducibility
• Blockers: 
  null
• Help wanted:
  Help test the deadlock code in the issue list and try to reproduce the issue

[SparrowLii]

• Key developments: *
  Still in the process of determining the cause of the deadlock through local testing and compiler code analysis.
• Blockers: 
  null
• Help wanted:
  Help test the deadlock code in the issue list and try to reproduce the issue

[nikomatsakis]

@SparrowLii opened a “proposed 2025H1 project goal](https://rust-lang.github.io/rust-project-goals/2025h1/parallel-front-end.html) to continue this work. The plans for the next 6 months are

• Solve reproducible deadlock issues via tests.
• Enable parallel frontends in bootstrap.
• Continue to improve parallel compilation performance, with the average speed increase from 20% to 25% under 8 cores and 8 threads.
• Communicate with Cargo team on the solution and plan to support parallel front end.

[SparrowLii]

• Key developments: *
  We discussed solutions to avoid potential deadlocks in mechanism, and so far disabling work-stealing in rayon's subloops is an effective solution. We will try to incorporate related modification PR: Only work-steal in the main loop rustc-rayon#12
• Blockers: 
  null
• Help wanted:
  Help test the deadlock code in the issue list and try to reproduce the issue

[nikomatsakis]

This is a continuing project goal, and the updates below this comment will be for the new period 2025h1