rust/compiler/rustc, branch perf-tmp

Make llvm_enzyme a regular cargo feature

2025-09-15T15:31:56+00:00

This makes it clearer that it is set by the build system rather than by the rustc that compiles the current rustc. It also avoids bootstrap needing to pass --check-cfg llvm_enzyme to rustc.

compiler: Add Windows resources to rustc-main and rustc_driver

2025-09-05T18:06:31+00:00

Adds Windows resources with the rust version information to rustc-main.exe and rustc_driver.dll Sets the product description to "Rust Compiler" or "Rust Compiler (channel)" for non-stable channels

rename `stable_mir` to `rustc_public`, and `rustc_smir` to `rustc_public_bridge`

2025-07-14T09:25:54+00:00

Avoid building C++ for rustc_llvm with --compile-time-deps

2025-07-11T13:32:03+00:00

This saves about 30s.

Revert "Use workspace lints for crates in `compiler/` #138084"

2025-03-10T10:12:47+00:00

Revert to buy time to consider options that avoids breaking downstream usages of cargo on distributed `rustc-src` artifacts, where such cargo invocations fail due to inability to inherit `lints` from workspace root manifest's `workspace.lints` (this is only valid for the source rust-lang/rust workspace, but not really the distributed `rustc-src` artifacts). This breakage was reported in . This reverts commit 48caf81484b50dca5a5cebb614899a3df81ca898, reversing changes made to c6662879b27f5161e95f39395e3c9513a7b97028.

Specify rust lints for `compiler/` crates via Cargo.

2025-03-07T21:41:09+00:00

By naming them in `[workspace.lints.rust]` in the top-level `Cargo.toml`, and then making all `compiler/` crates inherit them with `[lints] workspace = true`. (I omitted `rustc_codegen_{cranelift,gcc}`, because they're a bit different.) The advantages of this over the current approach: - It uses a standard Cargo feature, rather than special handling in bootstrap. So, easier to understand, and less likely to get accidentally broken in the future. - It works for proc macro crates. It's a shame it doesn't work for rustc-specific lints, as the comments explain.

Fix overcapturing, unsafe extern blocks, and new unsafe ops

2025-02-22T00:01:48+00:00

Upgrade the compiler to edition 2024

2025-02-22T00:01:48+00:00

switch jemalloc-sys back to tikv-jemalloc-sys, and update to 0.6.0

2024-12-03T08:56:33+00:00

Auto merge of #132282 - Noratrieb:it-is-the-end-of-serial, r=cjgillot

2024-11-12T15:14:56+00:00

Delete the `cfg(not(parallel))` serial compiler Since it's inception a long time ago, the parallel compiler and its cfgs have been a maintenance burden. This was a necessary evil the allow iteration while not degrading performance because of synchronization overhead. But this time is over. Thanks to the amazing work by the parallel working group (and the dyn sync crimes), the parallel compiler has now been fast enough to be shipped by default in nightly for quite a while now. Stable and beta have still been on the serial compiler, because they can't use `-Zthreads` anyways. But this is quite suboptimal: - the maintenance burden still sucks - we're not testing the serial compiler in nightly Because of these reasons, it's time to end it. The serial compiler has served us well in the years since it was split from the parallel one, but it's over now. Let the knight slay one head of the two-headed dragon! #113349 Note that the default is still 1 thread, as more than 1 thread is still fairly broken. cc `@onur-ozkan` to see if i did the bootstrap field removal correctly, `@SparrowLii` on the sync parts