rust/compiler/rustc_interface, branch 1.89.0

Rollup merge of #142384 - celinval:chores-rayon-mv, r=oli-obk

2025-06-21T03:25:54+00:00

Bringing `rustc_rayon_core` in tree as `rustc_thread_pool` This PR moves [`rustc_rayon_core`](https://github.com/rust-lang/rustc-rayon/tree/5fadf44/rayon-core) from commit `5fadf44` as suggested in [this zulip thread](https://rust-lang.zulipchat.com/#narrow/channel/187679-t-compiler.2Fparallel-rustc/topic/Bringing.20.60rustc_rayon_core.60.20in.20tree). I tried to split the work into separate commits so it is easy to review. The first commit is a simple copy and paste from the fork, and subsequent changes were made to use the new crate and to ensure the new crate complies with different format and lint expectations. **Call-out:** I was also wondering if I need to make any further changes to accommodate licensing requirements. r? oli-obk

Auto merge of #142794 - tgross35:rollup-iae7okj, r=tgross35

2025-06-20T23:09:48+00:00

Rollup of 9 pull requests Successful merges: - rust-lang/rust#142331 (Add `trim_prefix` and `trim_suffix` methods for both `slice` and `str` types.) - rust-lang/rust#142491 (Rework #[cold] attribute parser) - rust-lang/rust#142494 (Fix missing docs in `rustc_attr_parsing`) - rust-lang/rust#142495 (Better template for `#[repr]` attributes) - rust-lang/rust#142497 (Fix random failure when JS code is executed when the whole file was not read yet) - rust-lang/rust#142575 (Ensure copy* intrinsics also perform the static self-init checks) - rust-lang/rust#142650 (Refactor Translator) - rust-lang/rust#142713 (mbe: Refactor transcription) - rust-lang/rust#142755 (rustdoc: Remove `FormatRenderer::cache`) r? `@ghost` `@rustbot` modify labels: rollup

Rollup merge of #142767 - nnethercote:symbol-cleanups, r=petrochenkov

2025-06-20T18:03:24+00:00

Some symbol and PathRoot cleanups I'm looking into unifying how we join and print paths. Here are some preliminary cleanups. r? ``@petrochenkov``

Rollup merge of #142650 - camsteffen:refactor-translator, r=petrochenkov

2025-06-20T17:36:01+00:00

Refactor Translator My main motivation was to simplify the usage of `SilentEmitter` for users like rustfmt. A few refactoring opportunities arose along the way. * Replace `Translate` trait with `Translator` struct * Replace `Emitter: Translate` with `Emitter::translator` * Split `SilentEmitter` into `FatalOnlyEmitter` and `SilentEmitter`

Rollup merge of #142687 - cjgillot:less-hir_crate, r=oli-obk

2025-06-20T06:50:40+00:00

Reduce uses of `hir_crate`. I tried rebasing my old incremental-HIR branch. This is a by-product, which is required if we want to get rid of `hir_crate` entirely. The second commit is a drive-by cleanup. It can be pulled into its own PR. r? ````@oli-obk````

Use a symbol for `ExpansionConfig::crate_name`.

2025-06-20T03:17:39+00:00

This avoids some symbol interning and `to_string` conversions.

Extract SilentEmitter

2025-06-19T18:05:01+00:00

Rename SilentEmitter -> FatalOnlyEmitter

2025-06-19T18:03:17+00:00

Update compiler/rustc_interface/src/passes.rs

2025-06-19T11:18:33+00:00

Co-authored-by: bjorn3 <17426603+bjorn3@users.noreply.github.com>

Rollup merge of #142123 - Kobzol:timings, r=nnethercote

2025-06-18T17:40:32+00:00

Implement initial support for timing sections (`--json=timings`) This PR implements initial support for emitting high-level compilation section timings. The idea is to provide a very lightweight way of emitting durations of various compilation sections (frontend, backend, linker, or on a more granular level macro expansion, typeck, borrowck, etc.). The ultimate goal is to stabilize this output (in some form), make Cargo pass `--json=timings` and then display this information in the HTML output of `cargo build --timings`, to make it easier to quickly profile "what takes so long" during the compilation of a Cargo project. I would personally also like if Cargo printed some of this information in the interactive `cargo build` output, but the `build --timings` use-case is the main one. Now, this information is already available with several other sources, but I don't think that we can just use them as they are, which is why I proposed a new way of outputting this data (`--json=timings`): - This data is available under `-Zself-profile`, but that is very expensive and forever unstable. It's just a too big of a hammer to tell us the duration it took to run the linker. - It could also be extracted with `-Ztime-passes`. That is pretty much "for free" in terms of performance, and it can be emitted in a structured form to JSON via `-Ztime-passes-format=json`. I guess that one alternative might be to stabilize this flag in some form, but that form might just be `--json=timings`? I guess what we could do in theory is take the already emitted time passes and reuse them for `--json=timings`. Happy to hear suggestions! I'm sending this PR mostly for a vibeck, to see if the way I implemented it is passable. There are some things to figure out: - How do we represent the sections? Originally I wanted to output `{ section, duration }`, but then I realized that it might be more useful to actually emit `start` and `end` events. Both because it enables to see the output incrementally (in case compilation takes a long time and you read the outputs directly, or Cargo decides to show this data in `cargo build` some day in the future), and because it makes it simpler to represent hierarchy (see below). The timestamps currently emit microseconds elapsed from a predetermined point in time (~start of rustc), but otherwise they are fully opaque, and should be only ever used to calculate the duration using `end - start`. We could also precompute the duration for the user in the `end` event, but that would require doing more work in rustc, which I would ideally like to avoid :P - Do we want to have some form of hierarchy? I think that it would be nice to show some more granular sections rather than just frontend/backend/linker (e.g. macro expansion, typeck and borrowck as a part of the frontend). But for that we would need some way of representing hierarchy. A simple way would be something like `{ parent: "frontend" }`, but I realized that with start/end timestamps we get the hierarchy "for free", only the client will need to reconstruct it from the order of start/end events (e.g. `start A`, `start B` means that `B` is a child of `A`). - What exactly do we want to stabilize? This is probably a question for later. I think that we should definitely stabilize the format of the emitted JSON objects, and *maybe* some specific section names (but we should also make it clear that they can be missing, e.g. you don't link everytime you invoke `rustc`). The PR be tested e.g. with `rustc +stage1 src/main.rs --json=timings --error-format=json -Zunstable-options` on a crate without dependencies (it is not easy to use `--json` with stock Cargo, because it also passes this flag to `rustc`, so this will later need Cargo integration to be usable with it). Zulip discussions: [#t-compiler > Outputting time spent in various compiler sections](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Outputting.20time.20spent.20in.20various.20compiler.20sections/with/518850162) MCP: https://github.com/rust-lang/compiler-team/issues/873 r? ``@nnethercote``