Improve `Session`/`CodegenBackend` construction by nnethercote · Pull Request #161432 · rust-lang/rust

nnethercote · 2026-08-20T23:29:47Z

The creation and initialization of sessions and codegen backends is intertwined, which is confusing and error prone. This commit detangles things, and also simplifies the types used for the state within the backends. Details in individual commits.

r? @bjorn3

rustbot · 2026-08-20T23:29:51Z

miri is developed in its own repository. If the Miri part of this change can be broken out, consider making this change to rust-lang/miri instead. However, if Miri needs adjusting for rustc changes, just ignore this message.

cc @rust-lang/miri

rustc_codegen_cranelift is developed in its own repository. If possible, consider making this change to rust-lang/rustc_codegen_cranelift instead.

cc @bjorn3

rustc_codegen_gcc is developed in its own repository. If possible, consider making this change to rust-lang/rustc_codegen_gcc instead.

cc @antoyo, @GuillaumeGomez

nnethercote · 2026-08-20T23:30:36Z

This is an opinionated change, see what you all think.

LLM disclosure: some of the ideas came from an analysis done by an LLM. I wrote all the code and text myself.

antoyo · 2026-08-20T23:38:54Z

-    fn fmt(&self, formatter: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
-        self.info.lock().expect("lock").fmt(formatter)
-    }
+#[derive(Clone)]


Do the cg_gcc changes need to be done in this PR?
I would be more confortable landing this directly in the cg_gcc repo so that the whole test suite can run (some cg_gcc tests do not run here in the Rust repo).

View changes since the review

I think they do, because both commits change the signature of CodegenBackend::init. Doing a local test run in cg_gcc is probably the way forward, if/when there's agreement that this PR is worth merging.

RalfJung

Broadly makes sense to me but I did not check all the details.

View changes since this review

RalfJung · 2026-08-21T07:25:13Z

FWIW there is some more codegen-backend-related session initialization happening inside add_configuration. And especially the handing of target features is a complete mess (not as bad as it used to be, but still bad). We're calling llvm_util::global_llvm_features like half a dozen times because we need it in various places and we don't have a tcx yet so it can't be a query...

Anyway, not really something for this PR. I just wondered what this PR does with the messy part of codegen backend initialization that I regularly run into, and the answer is "nothing". Which is fine, the cleanup here seems reasonable on its own. Maybe inspiration for a future cleanup PR. :)

Interesting. I looked into add_configuration and found a bug; #161718 fixes it and takes a step towards cleaning things up more. Once that PR merges I will do more in this PR to fix the remaining ordering problems.

I also looked at global_llvm_features. There is a query for it, global_backend_features, but it's not actually necessary. It should be possible to get the features once and store them in the session, which should make things simpler. Not sure yet if I will do that in this PR or a follow-up.

I have successfully removed the global_backend_features query. #161903 needs to merge first.

Currently, `parse_cfg` calls `build_configuration`, which calls `default_configuration`, which calls `sess.target.singlethread(&sess.internal_target_features)`. But `sess.internal_target_features` hasn't been set at this point and is empty! This commit moves the setting of `sess.internal_target_features` before the `parse_cfg` call to fix this ordering bug. This results in the `cfg(target_has_threads)` being correctly set on `wasm32-unknown-unknown` when `-Ctarget-feature=+atomics` is specified. Note: I have plans to make this kind of ordering bug difficult/impossible in a follow-up (e.g. rust-lang#161432).

`llvm::target_config` creates `target_machine` by calling `create_informational_target_machine`, which calls `target_machine_factory`, which uses `internal_target_features`. But this is just before `internal_target_features` is initialized! So we should move `internal_target_features` initialization before `target_machine`, right? But `internal_target_features` initialization involves a closure that inspects `target_machine`. There is a cyclic dependency. There is enough function nesting here that it's hard to spot. In practice this cycle doesn't cause problems because the closure doesn't inspect the parts of `target_machine` that depend on `internal_target_features`. But it demonstrates how startup initialization is all tangled up, and it's blocking some cleanups I am doing in rust-lang#161432 relating to the dangerous uses of `Session` before it's fully initialized. Therefore, this commit changes the first part: instead of creating an `OwnedTargetMachine` we create an `OwnedMCSubtargetInfo`. This is a smaller type that has the feature information we need but doesn't depend on `internal_target_features`. Under the covers we are now using LLVM's `Target::createMCSubtargetInfo` instead of `TargetMachine::getMCSubtargetInfo` so that we avoid having to create a `TargetMachine` at this early stage. This eliminates the cycle. (`TargetMachine` can still be created later on, once we're past this fraught initialization.) There are some slight differences between these two approaches, and the preceding commits fixed up some issues there. Some details about this commit: - The new `OwnedMCSubtargetInfo` is similar to the existing `OwnedTargetMachine`. - `create_informational_target_machine` no longer needs a `for_cfg` parameter, because the one site where `for_cfg` was true has been removed. - `LLVMRustCreateMCSubtargetInfo` mostly replicates part of `LLVMRustCreateTargetMachine` - `LLVMRustMCSubtargetInfoHasFeature` partly replicates `LLVMRustHasFeature`. - `LLVMRustHasFeature` is no longer needed. - The error message for `custom-target-invalid-llvm-target.rs` changed.

`llvm::target_config` creates `target_machine` by calling `create_informational_target_machine`, which calls `target_machine_factory`, which uses `internal_target_features`. But this is just before `internal_target_features` is initialized! So we should move `internal_target_features` initialization before `target_machine`, right? But `internal_target_features` initialization involves a closure that inspects `target_machine`. There is a cyclic dependency. There is enough function nesting here that it's hard to spot. In practice this cycle doesn't cause problems because the closure doesn't inspect the parts of `target_machine` that depend on `internal_target_features`. But it demonstrates how startup initialization is all tangled up, and it's blocking some cleanups I am doing in rust-lang#161432 relating to the dangerous uses of `Session` before it's fully initialized. Therefore, this commit changes the first part: instead of creating and `OwnedTargetMachine` we create an `OwnedMCSubtargetInfo`. This is a smaller type that has the feature information we need but doesn't depend on `internal_target_features`. Under the covers we are now using LLVM's `Target::createMCSubtargetInfo` instead of `TargetMachine::getMCSubtargetInfo` so that we avoid having to create a `TargetMachine` at this early stage. This eliminates the cycle. (`TargetMachine` can still be created later on, once we're past this fraught initialization.) There are some slight differences between these two approaches, and the preceding commits fixed up some issues there. Some details about this commit: - The new `OwnedMCSubtargetInfo` is similar to the existing `OwnedTargetMachine`. - `create_informational_target_machine` no longer needs a `for_cfg` parameter, because the one site where `for_cfg` was true has been removed. - `LLVMRustCreateMCSubtargetInfo` mostly replicates part of `LLVMRustCreateTargetMachine` - `LLVMRustMCSubtargetInfoHasFeature` partly replicates `LLVMRustHasFeature`. - `LLVMRustHasFeature` is no longer needed. - The error message for `custom-target-invalid-llvm-target.rs` changed.

rustbot · 2026-08-31T04:57:10Z

clippy is developed in its own repository. If possible, consider making this change to rust-lang/rust-clippy instead.

cc @rust-lang/clippy

These commits modify compiler targets.
(See the Target Tier Policy.)

`llvm::target_config` creates `target_machine` by calling `create_informational_target_machine`, which calls `target_machine_factory`, which uses `internal_target_features`. But this is just before `internal_target_features` is initialized! So we should move `internal_target_features` initialization before `target_machine`, right? But `internal_target_features` initialization involves a closure that inspects `target_machine`. There is a cyclic dependency. There is enough function nesting here that it's hard to spot. In practice this cycle doesn't cause problems because the closure doesn't inspect the parts of `target_machine` that depend on `internal_target_features`. But it demonstrates how startup initialization is all tangled up, and it's blocking some cleanups I am doing in rust-lang#161432 relating to the dangerous uses of `Session` before it's fully initialized. Therefore, this commit changes the first part: instead of creating and `OwnedTargetMachine` we create an `OwnedMCSubtargetInfo`. This is a smaller type that has the feature information we need but doesn't depend on `internal_target_features`. Under the covers we are now using LLVM's `Target::createMCSubtargetInfo` instead of `TargetMachine::getMCSubtargetInfo` so that we avoid having to create a `TargetMachine` at this early stage. This eliminates the cycle. (`TargetMachine` can still be created later on, once we're past this fraught initialization.) There are some slight differences between these two approaches, and the preceding commits fixed up some issues there. Some details about this commit: - The new `OwnedMCSubtargetInfo` is similar to the existing `OwnedTargetMachine`. - `create_informational_target_machine` no longer needs a `for_cfg` parameter, because the one site where `for_cfg` was true has been removed. - `LLVMRustCreateMCSubtargetInfo` mostly replicates part of `LLVMRustCreateTargetMachine` - `LLVMRustMCSubtargetInfoHasFeature` partly replicates `LLVMRustHasFeature`. - `LLVMRustHasFeature` is no longer needed. - The error message for `custom-target-invalid-llvm-target.rs` changed.

`llvm::target_config` creates `target_machine` by calling `create_informational_target_machine`, which calls `target_machine_factory`, which uses `internal_target_features`. But this is just before `internal_target_features` is initialized! So we should move `internal_target_features` initialization before `target_machine`, right? But `internal_target_features` initialization involves a closure that inspects `target_machine`. There is a cyclic dependency. There is enough function nesting here that it's hard to spot. In practice this cycle doesn't cause problems because the closure doesn't inspect the parts of `target_machine` that depend on `internal_target_features`. But it demonstrates how startup initialization is all tangled up, and it's blocking some cleanups I am doing in rust-lang#161432 relating to the dangerous uses of `Session` before it's fully initialized. Therefore, this commit changes the first part: instead of creating an `OwnedTargetMachine` we create an `OwnedMCSubtargetInfo`. This is a smaller type that has the feature information we need but doesn't depend on `internal_target_features`. Under the covers we are now using LLVM's `Target::createMCSubtargetInfo` instead of `TargetMachine::getMCSubtargetInfo` so that we avoid having to create a `TargetMachine` at this early stage. This eliminates the cycle. (`TargetMachine` can still be created later on, once we're past this fraught initialization.) There are some slight differences between these two approaches, and the preceding commits fixed up some issues there. Some details about this commit: - The new `OwnedMCSubtargetInfo` is similar to the existing `OwnedTargetMachine`. - `create_informational_target_machine` no longer needs a `for_cfg` parameter, because the one site where `for_cfg` was true has been removed. - `LLVMRustCreateMCSubtargetInfo` mostly replicates part of `LLVMRustCreateTargetMachine` - `LLVMRustMCSubtargetInfoHasFeature` partly replicates `LLVMRustHasFeature`. - `LLVMRustHasFeature` is no longer needed. - The error message for `custom-target-invalid-llvm-target.rs` changed.

nnethercote · 2026-08-31T05:10:43Z

Blocked on #161903.

RalfJung

Nice :) Yeah that makes a lot more sense.

View changes since this review

The `require-explicit-cpu.json` case currently prints a "default target CPU" line; test for this. (It will change in the next commit.)

…rinted Specifically, don't print it when `need_explicit_cpu` is set, because it doesn't really make sense in that context. Right now among builtin targets this only affects the `amdgcn-amd-amdhsa` target, but it will also be relevant for the `avr2` target in the next commit. It also affects the `require-explicit-cpu.json` case in `tests/run-make/target-specs/rmake.rs`.

Currently rustc uses LLVM's `TargetMachine::getMCSubtargetInfo` method to access an `MCSubtargetInfo` to do feature testing. The next commit will change the feature testing to instead use an alternative pathway, LLVM's `Target::createMCSubtargetInfo` method. The two pathways have some slight differences. One difference relates to the `avr-none` target. Currently its `cpu` field isn't set so it gets the default "generic" value, which is not a valid AVR CPU name. This was hidden by the fact that the current LLVM pathway goes through the `getCPU` function in `AVRTargetMachine.cpp`, which rewrites "generic" as "avr2". But the alternative LLVM pathway doesn't rewrite "generic". Without an adjustment, we would get some behavioural differences with the alternative pathway, such as "unrecognized processor" errors and empty base feature sets. Therefore, this commit sets `cpu` to "avr2", a more obviously correct choice, and what the current LLVM pathway is effectively doing behind the scenes. You might think this would change the code generated by default, but `avr-none` has `need_explicit_cpu` set to true, so that's not the case, because a missing `-Ctarget-cpu` will trigger a fatal error before codegen. But `cpu` can still reach non-codegen paths (e.g. feature/cfg computation in session setup, and `--print`) so we need a valid backend name. A consequence of this is that `--print target-spec-json` will emit `cpu: "avr2"`. Another consequence is that the `requires_consistent_cpu` check will compare a crate built without `-Ctarget-cpu` (non-codegen only) against "avr2" instead of "generic". The commit also modifies two tests. In both cases, the test passes in this commit with or without the explicit `cpu` field. But in the next commit (using the alternative pathway) both tests would fail without the explicit `cpu` field: - `tests/ui/abi/avr-sram.rs` would fail with ``` 'generic' is not a recognized processor for this target (ignoring processor) 'generic' is not a recognized processor for this target (ignoring processor) warning: target feature `sram` must be enabled to ensure that the ABI of the current target can be implemented correctly ``` - `tests/run-make/print-cfg/rmake.rs` would fail because all features would be missing. Finally, the field docs for `TargetOptions` are tweaked to clarify the interplay between `cpu` and `need_explicit_cpu`.

`llvm::target_config` creates `target_machine` by calling `create_informational_target_machine`, which calls `target_machine_factory`, which uses `internal_target_features`. But this is just before `internal_target_features` is initialized! So we should move `internal_target_features` initialization before `target_machine`, right? But `internal_target_features` initialization involves a closure that inspects `target_machine`. There is a cyclic dependency. There is enough function nesting here that it's hard to spot. In practice this cycle doesn't cause problems because the closure doesn't inspect the parts of `target_machine` that depend on `internal_target_features`. But it demonstrates how startup initialization is all tangled up, and it's blocking some cleanups I am doing in rust-lang#161432 relating to the dangerous uses of `Session` before it's fully initialized. Therefore, this commit changes the first part: instead of creating and `OwnedTargetMachine` we create an `OwnedMCSubtargetInfo`. This is a smaller type that has the feature information we need but doesn't depend on `internal_target_features`. Under the covers we are now using LLVM's `Target::createMCSubtargetInfo` instead of `TargetMachine::getMCSubtargetInfo` so that we avoid having to create a `TargetMachine` at this early stage. This eliminates the cycle. (`TargetMachine` can still be created later on, once we're past this fraught initialization.) There are some slight differences between these two approaches, and the preceding commits fixed up some issues there. Some details about this commit: - The new `OwnedMCSubtargetInfo` is similar to the existing `OwnedTargetMachine`. - `create_informational_target_machine` no longer needs a `for_cfg` parameter, because the one site where `for_cfg` was true has been removed. - `LLVMRustCreateMCSubtargetInfo` mostly replicates part of `LLVMRustCreateTargetMachine` - `LLVMRustMCSubtargetInfoHasFeature` partly replicates `LLVMRustHasFeature`. - `LLVMRustHasFeature` is no longer needed. - The error message for `custom-target-invalid-llvm-target.rs` changed.

Session creation is currently awkward: we build a mostly-initialized session, then use it to initialize a codegen backend, and then use the codegen backend to finish initializing the session. And it's not just awkward: within the Cranelift backend's `init` method `sess.lto()` is called, which consults `sess.thin_lto_supported`, *before* that field has been properly set! In practice it had no effect but it's worth fixing up. This commit cleans up this mess. It introduces `EarlySession`, which contains just four `Session` fields, the ones that are needed for codegen backend initialization. It is now a field within `Session`, and `Session` derefs to `EarlySession` to avoid changing a zillion `sess.target`/`sess.opts`/etc. occurrences. `EarlySession` is passed to `init`, which returns a `CodegenBackendInit` that contains the backend-specific information needed to build a `Session`. (It replaces the `replaced_intrinsics`, `fallback_intrinsics`, and `thin_lto_supported` methods.) The `Session` can then be built in a single step. No more `Session`/`CodegenBackend` initialization intermingling. A few functions that previously took a `Session` now take something else, e.g. a `Target`. Some `Session` methods are now `EarlySession` methods. And a new `early_lto` method is used for Cranelift's LTO check.

It currently takes `&self`, which is a bit strange for an `init` method. As a result, the Cranelift and GCC backends have to use types with interior mutability. This commit changes it to `&mut self`. Benefits: - The Cranelift backend can use `Option` instead of `OnceCell` to indicate uninit vs. init. - The GCC backend can avoid `Mutex`, and use `bool` instead of `AtomicBool`, which makes things much simpler. The commit also restructures `GccCodegenBackend` to mirror `CraneliftCodegenBackend`: just contain an `Option<BackendConfig>`, which makes the uninit vs. init distinction foolproof. (E.g. no need to set `lto_supported` to false and then later overwrite it with the real value.) As part of this the `LockedTargetInfo` type is renamed `SharedTargetInfo` because that better matches its new internals. (All this compiles both with and without the "master" feature set.)

It's now possible to get the backend features (a `Vec<String>`) when the codegen backend is started, pass it back through `CodegenBackendInit`, and just store it in the `Session`. This removes the need for the query. Also: - `WriteBackendMethods::target_machine_factory` no longer needs the `target_features` parameter, because it's now available through the `sess` parameter. - `CodegenContext` no longer needs the `backend_features` field because we can use `sess.global_backend_features` instead. - `CodegenBackend::provide` is now a no-op for all the in-tree backends. I haven't removed it because out-of-tree backends still rely on it.

rustbot · 2026-09-01T00:07:24Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

rustbot · 2026-09-01T00:07:25Z

⚠️ Warning ⚠️

There are issue links (such as #123) in the commit messages of the following commits.
Please move them to the PR description, to avoid spamming the issues with references to the commit, and so this bot can automatically canonicalize them to avoid issues with subtree.
- 96079cd

rust-log-analyzer · 2026-09-01T00:12:36Z

The job aarch64-gnu-llvm-21-1 failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

   Compiling rustc_driver v0.0.0 (/checkout/compiler/rustc_driver)
[RUSTC-TIMING] ctrlc test:false 0.069
   Compiling jiff v0.2.16
[RUSTC-TIMING] build_script_build test:false 0.124
warning: rustc_llvm@0.0.0: llvm-wrapper/PassWrapper.cpp: In function 'LLVMOpaqueMCSubtargetInfo* LLVMRustCreateMCSubtargetInfo(const char*, const char*, const char*)':
warning: rustc_llvm@0.0.0: llvm-wrapper/PassWrapper.cpp:105:48: error: cannot convert 'llvm::Triple' to 'llvm::StringRef'
warning: rustc_llvm@0.0.0:   105 |   return wrap(TheTarget->createMCSubtargetInfo(Trip, CPU, Features));
warning: rustc_llvm@0.0.0:       |                                                ^~~~
warning: rustc_llvm@0.0.0:       |                                                |
warning: rustc_llvm@0.0.0:       |                                                llvm::Triple
warning: rustc_llvm@0.0.0: In file included from llvm-wrapper/PassWrapper.cpp:24:
warning: rustc_llvm@0.0.0: /usr/lib/llvm-21/include/llvm/MC/TargetRegistry.h:452:52: note: initializing argument 1 of 'llvm::MCSubtargetInfo* llvm::Target::createMCSubtargetInfo(llvm::StringRef, llvm::StringRef, llvm::StringRef) const'
warning: rustc_llvm@0.0.0:   452 |   MCSubtargetInfo *createMCSubtargetInfo(StringRef TheTriple, StringRef CPU,
warning: rustc_llvm@0.0.0:       |                                          ~~~~~~~~~~^~~~~~~~~
error: failed to run custom build command for `rustc_llvm v0.0.0 (/checkout/compiler/rustc_llvm)`

Caused by:
  process didn't exit successfully: `/checkout/obj/build/aarch64-unknown-linux-gnu/stage1-rustc/release/build/rustc_llvm/34187a53ffad117f/out/build_script_build` (exit status: 1)
  --- stdout
  cargo:rustc-check-cfg=cfg(llvm_component,values("ipo"))
  cargo:rustc-check-cfg=cfg(llvm_component,values("bitreader"))
  cargo:rustc-check-cfg=cfg(llvm_component,values("bitwriter"))
  cargo:rustc-check-cfg=cfg(llvm_component,values("linker"))
  cargo:rustc-check-cfg=cfg(llvm_component,values("asmparser"))
  cargo:rustc-check-cfg=cfg(llvm_component,values("lto"))
  cargo:rustc-check-cfg=cfg(llvm_component,values("coverage"))
  cargo:rustc-check-cfg=cfg(llvm_component,values("instrumentation"))
  cargo:rustc-check-cfg=cfg(llvm_component,values("x86"))
  cargo:rustc-check-cfg=cfg(llvm_component,values("arm"))
  cargo:rustc-check-cfg=cfg(llvm_component,values("aarch64"))
  cargo:rustc-check-cfg=cfg(llvm_component,values("amdgpu"))
  cargo:rustc-check-cfg=cfg(llvm_component,values("avr"))
  cargo:rustc-check-cfg=cfg(llvm_component,values("loongarch"))
  cargo:rustc-check-cfg=cfg(llvm_component,values("m68k"))
  cargo:rustc-check-cfg=cfg(llvm_component,values("csky"))
  cargo:rustc-check-cfg=cfg(llvm_component,values("mips"))
  cargo:rustc-check-cfg=cfg(llvm_component,values("powerpc"))
  cargo:rustc-check-cfg=cfg(llvm_component,values("systemz"))
  cargo:rustc-check-cfg=cfg(llvm_component,values("webassembly"))
  cargo:rustc-check-cfg=cfg(llvm_component,values("msp430"))
  cargo:rustc-check-cfg=cfg(llvm_component,values("sparc"))
  cargo:rustc-check-cfg=cfg(llvm_component,values("nvptx"))
  cargo:rustc-check-cfg=cfg(llvm_component,values("hexagon"))
  cargo:rustc-check-cfg=cfg(llvm_component,values("riscv"))
  cargo:rustc-check-cfg=cfg(llvm_component,values("xtensa"))
  cargo:rustc-check-cfg=cfg(llvm_component,values("bpf"))
  cargo:rerun-if-env-changed=RUST_CHECK
  cargo:rerun-if-env-changed=REAL_LIBRARY_PATH_VAR
  cargo:rerun-if-env-changed=REAL_LIBRARY_PATH
  cargo:rerun-if-env-changed=LLVM_CONFIG
  cargo:rerun-if-changed=/usr/lib/llvm-21/bin/llvm-config
  cargo:rustc-cfg=llvm_component="aarch64"
  cargo:rustc-cfg=llvm_component="amdgpu"
  cargo:rustc-cfg=llvm_component="arm"
  cargo:rustc-cfg=llvm_component="asmparser"
  cargo:rustc-cfg=llvm_component="avr"
  cargo:rustc-cfg=llvm_component="bitreader"
  cargo:rustc-cfg=llvm_component="bitwriter"
  cargo:rustc-cfg=llvm_component="bpf"
  cargo:rustc-cfg=llvm_component="coverage"
  cargo:rustc-cfg=llvm_component="hexagon"
  cargo:rustc-cfg=llvm_component="instrumentation"
  cargo:rustc-cfg=llvm_component="ipo"
  cargo:rustc-cfg=llvm_component="linker"
  cargo:rustc-cfg=llvm_component="loongarch"
  cargo:rustc-cfg=llvm_component="lto"
  cargo:rustc-cfg=llvm_component="m68k"
  cargo:rustc-cfg=llvm_component="mips"
  cargo:rustc-cfg=llvm_component="msp430"
  cargo:rustc-cfg=llvm_component="nvptx"
  cargo:rustc-cfg=llvm_component="powerpc"
  cargo:rustc-cfg=llvm_component="riscv"
  cargo:rustc-cfg=llvm_component="sparc"
  cargo:rustc-cfg=llvm_component="systemz"
  cargo:rustc-cfg=llvm_component="webassembly"
  cargo:rustc-cfg=llvm_component="x86"
  cargo:rustc-cfg=llvm_component="xtensa"
  cargo:rerun-if-env-changed=LLVM_COMPILER_IS_GNU_LIKE
  cargo:rerun-if-env-changed=RUSTC_DEBUGINFO_MAP
  cargo:rerun-if-env-changed=LLVM_ENZYME
  cargo:rerun-if-env-changed=LLVM_OFFLOAD
  cargo:rerun-if-env-changed=LLVM_RUSTLLVM
  cargo:rerun-if-env-changed=LLVM_ASSERTIONS
  cargo:rerun-if-changed=llvm-wrapper/SuppressLLVMWarnings.h
  cargo:rerun-if-changed=llvm-wrapper/PassWrapper.cpp
  cargo:rerun-if-changed=llvm-wrapper/offload/OffloadWrapper.cpp
  cargo:rerun-if-changed=llvm-wrapper/offload/CMakeLists.txt
  cargo:rerun-if-changed=llvm-wrapper/RustWrapper.cpp
  cargo:rerun-if-changed=llvm-wrapper/.editorconfig
  cargo:rerun-if-changed=llvm-wrapper/LLVMWrapper.h
  cargo:rerun-if-changed=llvm-wrapper/SymbolWrapper.cpp
  cargo:rerun-if-changed=llvm-wrapper/CoverageMappingWrapper.cpp
  cargo:rerun-if-changed=llvm-wrapper/README
  cargo:rerun-if-changed=llvm-wrapper/Linker.cpp
  cargo:rerun-if-env-changed=CC_FORCE_DISABLE
  CC_FORCE_DISABLE = None
  cargo:rerun-if-env-changed=CXX_aarch64-unknown-linux-gnu
  CXX_aarch64-unknown-linux-gnu = None
  cargo:rerun-if-env-changed=CXX_aarch64_unknown_linux_gnu
  CXX_aarch64_unknown_linux_gnu = Some(sccache c++)
  cargo:rerun-if-env-changed=CC_KNOWN_WRAPPER_CUSTOM
  CC_KNOWN_WRAPPER_CUSTOM = None
  cargo:rerun-if-env-changed=CC_ENABLE_DEBUG_OUTPUT
  cargo:rerun-if-env-changed=CRATE_CC_NO_DEFAULTS
  CRATE_CC_NO_DEFAULTS = None
  cargo:rerun-if-env-changed=CXXFLAGS
  CXXFLAGS = None
  cargo:rerun-if-env-changed=HOST_CXXFLAGS
  HOST_CXXFLAGS = None
  cargo:rerun-if-env-changed=CXXFLAGS_aarch64_unknown_linux_gnu
  CXXFLAGS_aarch64_unknown_linux_gnu = Some()
  cargo:rerun-if-env-changed=CC_SHELL_ESCAPED_FLAGS
  CC_SHELL_ESCAPED_FLAGS = None
  cargo:rerun-if-env-changed=CXXFLAGS_aarch64-unknown-linux-gnu
  CXXFLAGS_aarch64-unknown-linux-gnu = None
  cargo:warning=llvm-wrapper/PassWrapper.cpp: In function 'LLVMOpaqueMCSubtargetInfo* LLVMRustCreateMCSubtargetInfo(const char*, const char*, const char*)':
  cargo:warning=llvm-wrapper/PassWrapper.cpp:105:48: error: cannot convert 'llvm::Triple' to 'llvm::StringRef'
  cargo:warning=  105 |   return wrap(TheTarget->createMCSubtargetInfo(Trip, CPU, Features));
  cargo:warning=      |                                                ^~~~
  cargo:warning=      |                                                |
  cargo:warning=      |                                                llvm::Triple
  cargo:warning=In file included from llvm-wrapper/PassWrapper.cpp:24:
  cargo:warning=/usr/lib/llvm-21/include/llvm/MC/TargetRegistry.h:452:52: note: initializing argument 1 of 'llvm::MCSubtargetInfo* llvm::Target::createMCSubtargetInfo(llvm::StringRef, llvm::StringRef, llvm::StringRef) const'
  cargo:warning=  452 |   MCSubtargetInfo *createMCSubtargetInfo(StringRef TheTriple, StringRef CPU,
  cargo:warning=      |                                          ~~~~~~~~~~^~~~~~~~~

  --- stderr


  error occurred in cc-rs: command did not execute successfully (status code exit status: 1): LC_ALL="C" "sccache" "c++" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "-w" "-I/usr/lib/llvm-21/include" "-std=c++17" "-fno-exceptions" "-funwind-tables" "-D_GNU_SOURCE" "-DEXPERIMENTAL_KEY_INSTRUCTIONS" "-D__STDC_CONSTANT_MACROS" "-D__STDC_FORMAT_MACROS" "-D__STDC_LIMIT_MACROS" "-DLLVM_COMPONENT_AARCH64" "-DLLVM_COMPONENT_AMDGPU" "-DLLVM_COMPONENT_ARM" "-DLLVM_COMPONENT_ASMPARSER" "-DLLVM_COMPONENT_AVR" "-DLLVM_COMPONENT_BITREADER" "-DLLVM_COMPONENT_BITWRITER" "-DLLVM_COMPONENT_BPF" "-DLLVM_COMPONENT_COVERAGE" "-DLLVM_COMPONENT_HEXAGON" "-DLLVM_COMPONENT_INSTRUMENTATION" "-DLLVM_COMPONENT_IPO" "-DLLVM_COMPONENT_LINKER" "-DLLVM_COMPONENT_LOONGARCH" "-DLLVM_COMPONENT_LTO" "-DLLVM_COMPONENT_M68K" "-DLLVM_COMPONENT_MIPS" "-DLLVM_COMPONENT_MSP430" "-DLLVM_COMPONENT_NVPTX" "-DLLVM_COMPONENT_POWERPC" "-DLLVM_COMPONENT_RISCV" "-DLLVM_COMPONENT_SPARC" "-DLLVM_COMPONENT_SYSTEMZ" "-DLLVM_COMPONENT_WEBASSEMBLY" "-DLLVM_COMPONENT_X86" "-DLLVM_COMPONENT_XTENSA" "-o" "/checkout/obj/build/aarch64-unknown-linux-gnu/stage1-rustc/aarch64-unknown-linux-gnu/release/build/rustc_llvm/dd6fce3518f783ad/out/ef10e86dc40538c1-PassWrapper.o" "-c" "llvm-wrapper/PassWrapper.cpp"


warning: build failed, waiting for other jobs to finish...
[RUSTC-TIMING] shlex test:false 0.198
[RUSTC-TIMING] jiff test:false 7.272

rust-bors · 2026-09-01T23:55:58Z

☔ The latest upstream changes (presumably #162148) made this pull request unmergeable. Please resolve the merge conflicts by rebasing.

rustbot assigned bjorn3 Aug 20, 2026

antoyo reviewed Aug 20, 2026

View reviewed changes

This comment has been minimized.

Sign in to view

RalfJung reviewed Aug 21, 2026

View reviewed changes

bjorn3 reviewed Aug 21, 2026

View reviewed changes

Comment thread compiler/rustc_session/src/session.rs

bjorn3 reviewed Aug 21, 2026

View reviewed changes

Comment thread compiler/rustc_session/src/session.rs Outdated

bjorn3 reviewed Aug 21, 2026

View reviewed changes

Comment thread compiler/rustc_session/src/session.rs

bjorn3 reviewed Aug 21, 2026

View reviewed changes

Comment thread compiler/rustc_codegen_cranelift/src/lib.rs Outdated

nnethercote mentioned this pull request Aug 25, 2026

Fix the wasm32-unknown-unknown target feature/cfg bug #161718

Merged

bjorn3 added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 27, 2026

nnethercote force-pushed the improve-session-backend-building branch from 1225a52 to dacfcaa Compare August 31, 2026 04:57

rustbot added A-attributes Area: Attributes (`#[…]`, `#![…]`) A-run-make Area: port run-make Makefiles to rmake.rs T-clippy Relevant to the Clippy team. labels Aug 31, 2026

This comment has been minimized.

Sign in to view

nnethercote force-pushed the improve-session-backend-building branch from dacfcaa to c8f2df6 Compare August 31, 2026 05:08

This comment has been minimized.

Sign in to view

nnethercote added the S-blocked Status: Blocked on something else such as an RFC or other implementation work. label Aug 31, 2026

This comment has been minimized.

Sign in to view

RalfJung reviewed Aug 31, 2026

View reviewed changes

Comment thread compiler/rustc_session/src/session.rs Outdated

Comment thread compiler/rustc_session/src/session.rs Outdated

Comment thread compiler/rustc_session/src/session.rs

This comment has been minimized.

Sign in to view

nnethercote added 7 commits September 1, 2026 08:30

[161903] Slightly extend tests/run-make/target-specs/rmake.rs

f1a579a

The `require-explicit-cpu.json` case currently prints a "default target CPU" line; test for this. (It will change in the next commit.)

nnethercote force-pushed the improve-session-backend-building branch from c8f2df6 to 6279910 Compare September 1, 2026 00:07

Uh oh!

Uh oh!

Conversation

nnethercote commented Aug 20, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Aug 20, 2026

Uh oh!

nnethercote commented Aug 20, 2026

Uh oh!

antoyo Aug 20, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nnethercote Aug 21, 2026

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

RalfJung left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RalfJung Aug 21, 2026

Choose a reason for hiding this comment

Uh oh!

nnethercote Aug 25, 2026

Choose a reason for hiding this comment

Uh oh!

nnethercote Aug 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

rustbot commented Aug 31, 2026

Uh oh!

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

nnethercote commented Aug 31, 2026

Uh oh!

This comment has been minimized.

RalfJung left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

This comment has been minimized.

rustbot commented Sep 1, 2026

Uh oh!

rustbot commented Sep 1, 2026

Uh oh!

rust-log-analyzer commented Sep 1, 2026

Uh oh!

rust-bors Bot commented Sep 1, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

nnethercote commented Aug 20, 2026 •

edited by rustbot

Loading

antoyo Aug 20, 2026 •

edited by rustbot

Loading

RalfJung left a comment •

edited by rustbot

Loading

nnethercote Aug 31, 2026 •

edited

Loading

RalfJung left a comment •

edited by rustbot

Loading