allow `-Ldependency` search paths for panic runtimes by Bryanskiy · Pull Request #160007 · rust-lang/rust

Bryanskiy · 2026-07-27T11:23:20Z

This PR supports -Ldependency= search paths for panic runtimes.

To do so, both panic runtimes (or one if the other hasn't been built) are injected as conditional dependencies of std during crate resolution. Therefore, the panic runtimes will be present in the std metadata and loaded like regular transitive dependencies, rather than being injected as a direct dependency. The activation of one particular runtime happens later in dependency_format.rs, based on the desired strategy.

This will allow Cargo to treat panic runtimes as regular transitive dependencies, rather than special-casing them.

cc @adamgemmell

rustbot · 2026-07-27T11:23:26Z

r? @TaKO8Ki

rustbot has assigned @TaKO8Ki.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: compiler
compiler expanded to 74 candidates
Random selection from 18 candidates

Bryanskiy · 2026-07-27T11:23:41Z

@rustbot blocked on #159717

bjorn3 · 2026-07-27T11:31:05Z

This would risk accidentally getting a crates.io crate replacing compiler-builtins or a panic runtime from the sysroot even when it isn't a direct dependency, right? Currently -Ldependency is only used for crates that are indirect dependencies and thus we already know the crate hash for to prevent such accidental inclusion.

petrochenkov · 2026-07-27T13:29:43Z

One possible alternative is using something like force (ExternEntry::force) + no-link (CrateDepKind::MacrosOnly) for dependencies like panic runtime. Then the panic runtime will be present in the dependency tree, its crate hash will be recorded, and it will be naturally found in the dependency directories.

inject_panic_runtime and friends will just need to promote such dependencies from "no-link" to "link".

bjorn3 · 2026-07-27T13:38:19Z

Wouldn't --extern panic_abort=... --extern panic_unwind=... already be enough? I would expect the panic runtime injection code to already look at --extern.

petrochenkov · 2026-07-27T13:52:26Z

--extern panic_abort=... --extern panic_unwind=... exist when building std, but they are not not actually used by std so the crates are not loaded and the options are lost. (#160007 (comment) would make them loaded and not lost, just not linked).

When cargo builds some final binary depending on libstd, panic runtime crates are already indirect dependencies.
So cargo doesn't pass them with --extern, and as Kirill explained to me, cargo doesn't want to pass them with --extern at this stage, because it would contradict the cargo's internal logic and design.
Cargo wants library\std\Cargo.toml to be the only place where these dependencies are specified.

bjorn3 · 2026-07-27T13:55:57Z

--extern panic_abort=... --extern panic_unwind=... exist when building std

I mean when building user crates.

but they are not not actually used by std so the crates are not loaded and the options are lost.

At panic_unwind is already listed as conditional dependency of std, see rustc +nightly -Zls=root $(rustc +nightly --print target-libdir)/libstd-*.rmeta:

[...]
18 panic_unwind-aff6afe86ac8b0f1 hash 362c7180b46c57babeedc50f4e9b00d0 host_hash None kind Conditional private linkage Some(RequireStatic)

panic_abort isn't though.

Bryanskiy · 2026-07-27T13:59:36Z

I mean when building user crates.

From my understanding, we want to avoid special cases for compiler_builtins/panic runtimes in Cargo as much as possible. But @adamgemmell might know the motivation better.

adamgemmell · 2026-07-27T14:34:49Z

That's indeed the reason, we'd like Cargo to only have to be aware of stable crates (plus test)

This would risk accidentally getting a crates.io crate replacing compiler-builtins or a panic runtime from the sysroot even when it isn't a direct dependency, right?

rustc does report an error when it finds more than one candidate, including if one of these candidates is in the sysroot. So for this to happen, rustc would need to want to inject a crate that cargo hasn't built as part of build-std (and doesn't exist in the sysroot), which I don't think is possible right now.

If it is possible I think you'd have to pass a panic strategy via RUSTFLAGS rather than the profile, and we do have this line in the RFC to fall back on:

In line with Cargo’s stance on not parsing the RUSTFLAGS environment variable, it will not be checked for compilation flags that would require additional crates to be built for compilation to succeed.

bjorn3 · 2026-07-27T14:46:06Z

rustc does report an error when it finds more than one candidate, including if one of these candidates is in the sysroot.

Sysroot crates should have lower priority than user crates. Otherwise it wouldn't be possible to use libc from crates.io.

Would it work if we make rustc add a conditional dependency on both panic_unwind and panic_abort when compiling libstd rather than only on panic_unwind?

adamgemmell · 2026-07-27T15:07:13Z

Sorry, I'm just referring to injected dependencies, for which Kirill found that rustc threw an error when he added -Ldependency args to their search paths. That's why this patch now depends on the one for -Zimplicit-sysroot-deps.

Always building both is an option, but the Cargo team expressed a preference for not building panic_unwind if it can be avoided. Hence we don't pass the panic-unwind feature if the profile panic is set to abort. We have a future possibility to get the target's default panic strategy to avoid building it when the panic strategy is set to "unwind" (aka target default in the profile).

Sorry, I'm clearly not awake yet!

Bryanskiy · 2026-07-27T15:35:36Z

Sysroot crates should have lower priority than user crates. Otherwise it wouldn't be possible to use libc from crates.io.

There is no such thing as priority from the crate locator perspective:

rust/compiler/rustc_metadata/src/locator.rs

Lines 502 to 505 in dfbea5b

    
           match libraries.len() { 
        
               0 => Ok(None), 
        
               1 => Ok(Some(libraries.into_iter().next().unwrap().1)), 
        
               _ => {

The right version of libc is chosen based on svh, I think.

Would it work if we make rustc add a conditional dependency on both panic_unwind and panic_abort when compiling libstd rather than only on panic_unwind?

When compiling libstd as rlib, we don't inject the panic runtime at all. So the panic runtime is not present in std metadata as a dependency and therefore is not loaded like regular transitive dependencies.

Bryanskiy · 2026-07-27T15:41:03Z

Always building both is an option

It's not about building a panic runtime. It's about rustc representation of dependencies in the crate graph. Here is what conditional dependency mean:

rust/compiler/rustc_session/src/cstore.rs

Lines 42 to 44 in ad0c9dc

    
               /// A dependency that is injected into the crate graph but which only 
        
               /// sometimes needs to actually be linked in, e.g., the injected panic runtime. 
        
               Conditional,

bjorn3 · 2026-07-27T15:58:31Z

The right version of libc is chosen based on svh, I think.

For indirect dependencies yes. For direct dependencies the --extern libc=/path/to/rlib passed by cargo has a higher priority than the version in the sysroot. If they had identical priority, any attempt to use libc from crates.io would result in rustc emitting an error that it doesn't know if it should pick the one passed by cargo or the one in the sysroot.

When compiling libstd as rlib, we don't inject the panic runtime at all. So the panic runtime is not present in std metadata as a dependency and therefore is not loaded like regular transitive dependencies.

panic_unwind is absolutely present as conditional dependency in the libstd crate metadata:

rustc +nightly -Zls=root $(rustc +nightly --print target-libdir)/libstd-*.rmeta | rg "Dependencies|panic_unwind"
=External Dependencies=
18 panic_unwind-aff6afe86ac8b0f1 hash 362c7180b46c57babeedc50f4e9b00d0 host_hash None kind Conditional private linkage Some(RequireStatic)

The problem is that the panic runtime injection code attempts to include it as direct dependency. My suggestion is to include both panic runtimes (or one if the other hasn't been built) as conditional dependency of libstd replacing the code at

rust/compiler/rustc_metadata/src/creader.rs

Lines 956 to 1025 in ad0c9dc

    
           fn inject_panic_runtime(&mut self, tcx: TyCtxt<'_>, krate: &ast::Crate) { 
        
               // If we're only compiling an rlib, then there's no need to select a 
        
               // panic runtime, so we just skip this section entirely. 
        
               let only_rlib = tcx.crate_types().iter().all(|ct| *ct == CrateType::Rlib); 
        
               if only_rlib { 
        
                   info!("panic runtime injection skipped, only generating rlib"); 
        
                   return; 
        
               } 
        
               // If we need a panic runtime, we try to find an existing one here. At 
        
               // the same time we perform some general validation of the DAG we've got 
        
               // going such as ensuring everything has a compatible panic strategy. 
        
               let mut needs_panic_runtime = attr::contains_name(&krate.attrs, sym::needs_panic_runtime); 
        
               for (_cnum, data) in self.iter_crate_data() { 
        
                   needs_panic_runtime |= data.needs_panic_runtime(); 
        
               } 
        
               // If we just don't need a panic runtime at all, then we're done here 
        
               // and there's nothing else to do. 
        
               if !needs_panic_runtime { 
        
                   return; 
        
               } 
        
               // By this point we know that we need a panic runtime. Here we just load 
        
               // an appropriate default runtime for our panic strategy. 
        
               // 
        
               // We may resolve to an already loaded crate (as the crate may not have 
        
               // been explicitly linked prior to this), but this is fine. 
        
               // 
        
               // Also note that we have yet to perform validation of the crate graph 
        
               // in terms of everyone has a compatible panic runtime format, that's 
        
               // performed later as part of the `dependency_format` module. 
        
               let desired_strategy = tcx.sess.panic_strategy(); 
        
               let name = match desired_strategy { 
        
                   PanicStrategy::Unwind => sym::panic_unwind, 
        
                   PanicStrategy::Abort => sym::panic_abort, 
        
                   PanicStrategy::ImmediateAbort => { 
        
                       // Immediate-aborting panics don't use a runtime. 
        
                       return; 
        
                   } 
        
               }; 
        
               info!("panic runtime not found -- loading {}", name); 
        
               // This has to be conditional as both panic_unwind and panic_abort may be present in the 
        
               // crate graph at the same time. One of them will later be activated in dependency_formats. 
        
               let Some(cnum) = self.resolve_crate( 
        
                   tcx, 
        
                   name, 
        
                   DUMMY_SP, 
        
                   CrateDepKind::Conditional, 
        
                   CrateOrigin::Injected, 
        
               ) else { 
        
                   return; 
        
               }; 
        
               let cdata = self.get_crate_data(cnum); 
        
               // Sanity check the loaded crate to ensure it is indeed a panic runtime 
        
               // and the panic strategy is indeed what we thought it was. 
        
               if !cdata.is_panic_runtime() { 
        
                   tcx.dcx().emit_err(diagnostics::CrateNotPanicRuntime { crate_name: name }); 
        
               } 
        
               if cdata.required_panic_strategy() != Some(desired_strategy) { 
        
                   tcx.dcx().emit_err(diagnostics::NoPanicStrategy { 
        
                       crate_name: name, 
        
                       strategy: desired_strategy, 
        
                   }); 
        
               } 
        
               self.injected_panic_runtime = Some(cnum); 
        
           }

This way we don't have to inject it as dependency for any user of libstd. We already have code to activate exactly one panic runtime later on in the dependency format code:

rust/compiler/rustc_metadata/src/dependency_format.rs

Lines 253 to 260 in ad0c9dc

    
           // We've gotten this far because we're emitting some form of a final 
        
           // artifact which means that we may need to inject dependencies of some 
        
           // form. 
        
           // 
        
           // Things like panic runtimes may not have been activated quite yet, so do so here. 
        
           activate_injected_dep(CStore::from_tcx(tcx).injected_panic_runtime(), &mut ret, &|cnum| { 
        
               tcx.is_panic_runtime(cnum) 
        
           });

petrochenkov · 2026-07-28T10:03:07Z

We already have code to activate exactly one panic runtime later on in the dependency format code

Then it seems like CrateDepKind::Conditional already mostly implements what I suggested in #160007 (comment).

Bryanskiy · 2026-07-28T11:10:39Z

I'm curious what should we do with compiler_builtins.

On the one hand, as Adam already said, we want to use only stable names in Cargo and therefore remove compiler_builtins from the build-std implementation:

https://github.com/rust-lang/cargo/blob/0158e40d8638a7de292b7242b1533caaf48cbe5f/src/compiler/standard_lib.rs#L31
+
https://github.com/rust-lang/cargo/blob/0158e40d8638a7de292b7242b1533caaf48cbe5f/src/compiler/standard_lib.rs#L41

On the other hand compiler_builtins is not an explicit dependency of core(and should not be) in Cargo.toml. This means that after removal, Cargo will not be able to figure out whether it needs to build compiler_builtins for -Zbuild-std=core.

adamgemmell · 2026-07-28T11:21:14Z

I was planning on making it a dependency of sysroot and using that crate as the sort of "global entry point" when needed (such as for -Zbuild-std-features), but not generate an actual unit to build it in Cargo

Bryanskiy · 2026-07-29T19:18:04Z

For panic runtimes I implemented #160007 (comment).
For compiler_builtins crate -Ldependency= paths are not supported in the case of -Zbuild-std=core, but it's blocked on the mechanism mentioned in #160007 (comment).

rust-bors · 2026-07-31T13:50:53Z

This pull request was unapproved.

This PR was contained in a rollup (#160278), which was unapproved.

View changes since this unapproval

Bryanskiy · 2026-07-31T15:48:43Z

LINK : error LNK2001: unresolved external symbol __DllMainCRTStartup@12

My test with #![no_std]/#![no_core] is just to check crate resolution. Maybe we could pass --emit=llvm-ir to avoid running the linker?

Bryanskiy · 2026-07-31T16:10:48Z

implemented #160007 (comment)

Bryanskiy · 2026-08-03T08:47:01Z

@rustbot ready

bjorn3 · 2026-08-03T13:15:47Z

@bors r+

rust-bors · 2026-08-03T13:15:50Z

📌 Commit 3396d86 has been approved by bjorn3

It is now in the queue for this repository.

@adamgemmell

allow `-Ldependency` search paths for panic runtimes Part of [build-std=always RFC](https://rust-lang.github.io/rfcs/3874-build-std-always.html). This PR supports `-Ldependency=` search paths for panic runtimes. To do so, both panic runtimes (or one if the other hasn't been built) are injected as conditional dependencies of `std` during crate resolution. Therefore, the panic runtimes will be present in the `std` metadata and loaded like regular transitive dependencies, rather than being injected as a direct dependency. The activation of one particular runtime happens later in `dependency_format.rs`, based on the desired strategy. This will allow Cargo to treat panic runtimes as regular transitive dependencies, rather than special-casing them. cc @adamgemmell

…uwer Rollup of 21 pull requests Successful merges: - #159844 (Subtree cg_gcc sync (2026-07-24)) - #159326 (Deny multiple EII impls on a single item) - #159535 (Optimize slice::contains for bytewise types) - #159595 (Promote loongarch32-unknown-none* to Tier 2) - #160007 (allow `-Ldependency` search paths for panic runtimes) - #160320 (point at trait definition when it is used as a derive macro) - #160369 (When suggesting method names, prefer *exact* doc aliases over similar names) - #160406 (`DepKind` cleanups) - #160424 (Use `thread::available_parallelism` as the default limit for backend parallelism) - #159014 ([rustdoc] Do not take `doc(cfg())` into account when filtering doctests) - #159303 (Fix ICE for direct inline const generic defaults) - #159977 (Add regression test for bool indexing codegen) - #160165 (reject `...` without pattern post-expansion) - #160295 (Fix rustdoc ICE when checking if a generic arg can be elided) - #160305 (Linkify C-SKY targets in `platform-support.md`) - #160314 (fix borrowck ICE for consts with fn pointer type) - #160322 (ElaborateBoxDeref: remove unnecessary projection) - #160338 (Add regression test for supertrait associated type normalization through dyn) - #160340 (Add regression test for unused_parens on contract clauses) - #160371 (Add doc aliases for transpositions `read_exact_buf` and `read_exact_buf_at`) - #160384 (Add PR body notes for Cargo lock file maintenance)

@adamgemmell

allow `-Ldependency` search paths for panic runtimes Part of [build-std=always RFC](https://rust-lang.github.io/rfcs/3874-build-std-always.html). This PR supports `-Ldependency=` search paths for panic runtimes. To do so, both panic runtimes (or one if the other hasn't been built) are injected as conditional dependencies of `std` during crate resolution. Therefore, the panic runtimes will be present in the `std` metadata and loaded like regular transitive dependencies, rather than being injected as a direct dependency. The activation of one particular runtime happens later in `dependency_format.rs`, based on the desired strategy. This will allow Cargo to treat panic runtimes as regular transitive dependencies, rather than special-casing them. cc @adamgemmell

…uwer Rollup of 23 pull requests Successful merges: - #153749 (Account for ownership mismatch on argument that doesn't meet bound) - #159326 (Deny multiple EII impls on a single item) - #159535 (Optimize slice::contains for bytewise types) - #159595 (Promote loongarch32-unknown-none* to Tier 2) - #160007 (allow `-Ldependency` search paths for panic runtimes) - #160184 (Add -Zinstrument-mcount={fentry-nop-record,fentry-record}) - #160320 (point at trait definition when it is used as a derive macro) - #160369 (When suggesting method names, prefer *exact* doc aliases over similar names) - #160406 (`DepKind` cleanups) - #160424 (Use `thread::available_parallelism` as the default limit for backend parallelism) - #159303 (Fix ICE for direct inline const generic defaults) - #159977 (Add regression test for bool indexing codegen) - #160011 (remove InterpError::map_err_info) - #160165 (reject `...` without pattern post-expansion) - #160295 (Fix rustdoc ICE when checking if a generic arg can be elided) - #160305 (Linkify C-SKY targets in `platform-support.md`) - #160314 (fix borrowck ICE for consts with fn pointer type) - #160322 (ElaborateBoxDeref: remove unnecessary projection) - #160338 (Add regression test for supertrait associated type normalization through dyn) - #160340 (Add regression test for unused_parens on contract clauses) - #160371 (Add doc aliases for transpositions `read_exact_buf` and `read_exact_buf_at`) - #160384 (Add PR body notes for Cargo lock file maintenance) - #160435 (bump tracing-tree)

JonathanBrouwer · 2026-08-03T20:30:57Z

💔 I suspect this PR failed tests as part of a rollup
@bors r-

After fixing the problem, consider running a try job for the failed job before re-approving.

Link to failure: #160455 (comment)

Probably this PR?
@bors try jobs=aarch64-apple

rust-bors · 2026-08-03T20:31:03Z

This pull request was unapproved.

This PR was contained in a rollup (#160455), which was unapproved.

View changes since this unapproval

allow `-Ldependency` search paths for panic runtimes try-job: aarch64-apple

rust-bors · 2026-08-03T23:27:11Z

💔 Test for 5dfe67d failed: CI. Failed job:

try - aarch64-apple (web logs, enhanced plaintext logs)

rust-log-analyzer · 2026-08-03T23:27:15Z

The job aarch64-apple failed! Check out the build log: (web) (plain enhanced) (plain)

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

---- [run-make] tests/run-make-cargo/apple-slow-tls stdout ----

error: rmake recipe failed to complete
status: exit status: 1
command: cd "/Users/runner/work/rust/rust/build/aarch64-apple-darwin/test/run-make-cargo/apple-slow-tls/rmake_out" && env -u RUSTFLAGS -u __STD_REMAP_DEBUGINFO_ENABLED AR="ar" BUILD_ROOT="/Users/runner/work/rust/rust/build/aarch64-apple-darwin" CARGO="/Users/runner/work/rust/rust/build/aarch64-apple-darwin/stage2-tools-bin/cargo" CC="cc" CC_DEFAULT_FLAGS="-ffunction-sections -fdata-sections -fPIC --target=arm64-apple-macosx -mmacosx-version-min=11 -w" CXX="c++" CXX_DEFAULT_FLAGS="-ffunction-sections -fdata-sections -fPIC --target=arm64-apple-macosx -mmacosx-version-min=11 -w -stdlib=libc++" DYLD_LIBRARY_PATH="/Users/runner/work/rust/rust/build/aarch64-apple-darwin/bootstrap-tools/aarch64-apple-darwin/release/build/run_make_support/c00adef9f0e6a71b/out:/Users/runner/work/rust/rust/build/aarch64-apple-darwin/stage0/lib/rustlib/aarch64-apple-darwin/lib" HOST_RUSTC_DYLIB_PATH="/Users/runner/work/rust/rust/build/aarch64-apple-darwin/stage2/lib" LD_LIB_PATH_ENVVAR="DYLD_LIBRARY_PATH" LLVM_BIN_DIR="/Users/runner/work/rust/rust/build/aarch64-apple-darwin/llvm/bin" LLVM_COMPONENTS="aarch64 aarch64asmparser aarch64codegen aarch64desc aarch64disassembler aarch64info aarch64utils abi aggressiveinstcombine all all-targets amdgpu amdgpuasmparser amdgpucodegen amdgpudesc amdgpudisassembler amdgpuinfo amdgputargetmca amdgpuutils analysis arm armasmparser armcodegen armdesc armdisassembler arminfo armutils asmparser asmprinter avr avrasmparser avrcodegen avrdesc avrdisassembler avrinfo binaryformat bitreader bitstreamreader bitwriter bpf bpfasmparser bpfcodegen bpfdesc bpfdisassembler bpfinfo cas cfguard cgdata codegen codegentypes core coroutines coverage csky cskyasmparser cskycodegen cskydesc cskydisassembler cskyinfo debuginfobtf debuginfocodeview debuginfodwarf debuginfodwarflowlevel debuginfogsym debuginfologicalview debuginfomsf debuginfopdb demangle dlltooldriver dtlto dwarfcfichecker dwarflinker dwarflinkerclassic dwarflinkerparallel dwp engine executionengine extensions filecheck frontendatomic frontenddirective frontenddriver frontendhlsl frontendoffloading frontendopenacc frontendopenmp fuzzercli fuzzmutate globalisel hexagon hexagonasmparser hexagoncodegen hexagondesc hexagondisassembler hexagoninfo hipstdpar instcombine instrumentation interfacestub interpreter ipo irprinter irreader jitlink libdriver lineeditor linker loongarch loongarchasmparser loongarchcodegen loongarchdesc loongarchdisassembler loongarchinfo lto m68k m68kasmparser m68kcodegen m68kdesc m68kdisassembler m68kinfo mc mca mcdisassembler mcjit mcparser mips mipsasmparser mipscodegen mipsdesc mipsdisassembler mipsinfo mirparser msp430 msp430asmparser msp430codegen msp430desc msp430disassembler msp430info native nativecodegen nvptx nvptxcodegen nvptxdesc nvptxinfo objcarcopts objcopy object objectyaml option orcdebugging orcjit orcshared orctargetprocess passes plugins powerpc powerpcasmparser powerpccodegen powerpcdesc powerpcdisassembler powerpcinfo profiledata remarks riscv riscvasmparser riscvcodegen riscvdesc riscvdisassembler riscvinfo riscvtargetmca runtimedyld sandboxir scalaropts selectiondag sparc sparcasmparser sparccodegen sparcdesc sparcdisassembler sparcinfo support supportlsp symbolize systemz systemzasmparser systemzcodegen systemzdesc systemzdisassembler systemzinfo tablegen target targetparser telemetry textapi textapibinaryreader transformutils vectorize webassembly webassemblyasmparser webassemblycodegen webassemblydesc webassemblydisassembler webassemblyinfo webassemblyutils windowsdriver windowsmanifest x86 x86asmparser x86codegen x86desc x86disassembler x86info x86targetmca xray xtensa xtensaasmparser xtensacodegen xtensadesc xtensadisassembler xtensainfo" LLVM_FILECHECK="/Users/runner/work/rust/rust/build/aarch64-apple-darwin/llvm/build/bin/FileCheck" NODE="/opt/homebrew/bin/node" PYTHON="/opt/homebrew/opt/python@3.14/bin/python3.14" RUSTC="/Users/runner/work/rust/rust/build/aarch64-apple-darwin/stage2/bin/rustc" RUSTDOC="/Users/runner/work/rust/rust/build/aarch64-apple-darwin/stage2/bin/rustdoc" SOURCE_ROOT="/Users/runner/work/rust/rust" TARGET="aarch64-apple-darwin" TARGET_EXE_DYLIB_PATH="/Users/runner/work/rust/rust/build/aarch64-apple-darwin/stage2/lib/rustlib/aarch64-apple-darwin/lib" __BOOTSTRAP_JOBS="3" __RMAKE_VERBOSE_SUBPROCESS_OUTPUT="1" __RUSTC_DEBUG_ASSERTIONS_ENABLED="1" __STD_DEBUG_ASSERTIONS_ENABLED="1" "/Users/runner/work/rust/rust/build/aarch64-apple-darwin/test/run-make-cargo/apple-slow-tls/rmake"
stdout: none
--- stderr -------------------------------
DYLD_LIBRARY_PATH="/Users/runner/work/rust/rust/build/aarch64-apple-darwin/test/run-make-cargo/apple-slow-tls/rmake_out:/Users/runner/work/rust/rust/build/aarch64-apple-darwin/stage2/lib:/Users/runner/work/rust/rust/build/aarch64-apple-darwin/bootstrap-tools/aarch64-apple-darwin/release/build/run_make_support/c00adef9f0e6a71b/out:/Users/runner/work/rust/rust/build/aarch64-apple-darwin/stage0/lib/rustlib/aarch64-apple-darwin/lib" "/Users/runner/work/rust/rust/build/aarch64-apple-darwin/stage2/bin/rustc" "-L" "/Users/runner/work/rust/rust/build/aarch64-apple-darwin/test/run-make-cargo/apple-slow-tls/rmake_out" "--print" "target-spec-json" "-Z" "unstable-options" "--target=aarch64-apple-darwin"
output status: `exit status: 0`
=== STDOUT ===
{
  "abi-return-struct-as-int": true,
  "arch": "aarch64",
  "archive-format": "darwin",
  "binary-format": "mach-o",
  "cpu": "apple-m1",
  "crt-objects-fallback": "false",
  "data-layout": "e-m:o-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-n32:64-S128-Fn32",
  "debuginfo-kind": "dwarf-dsym",
  "dll-suffix": ".dylib",
  "dynamic-linking": true,
  "eh-frame-header": false,
  "emit-debug-gdb-scripts": false,
  "frame-pointer": "non-leaf",
  "function-sections": false,
  "has-rpath": true,
  "has-thread-local": true,
  "is-like-darwin": true,
  "link-env": [
    "ZERO_AR_DATE=1"
  ],
  "link-env-remove": [
    "IPHONEOS_DEPLOYMENT_TARGET",
    "TVOS_DEPLOYMENT_TARGET",
    "XROS_DEPLOYMENT_TARGET"
  ],
  "linker-flavor": "darwin-cc",
  "linker-is-gnu": false,
  "lld-flavor": "darwin",
  "llvm-target": "arm64-apple-macosx",
  "max-atomic-width": 128,
  "metadata": {
    "description": "ARM64 Apple macOS (11.0+, Big Sur+)",
    "host_tools": true,
    "std": true,
    "tier": 1
  },
  "os": "macos",
  "split-debuginfo": "packed",
  "stack-probes": {
    "kind": "inline"
---
  "supports-xray": true,
  "target-family": [
    "unix"
  ],
  "target-mcount": "\u0001mcount",
  "target-pointer-width": 64,
  "vendor": "apple"
}



=== STDERR ===



command failed at line 31
DYLD_LIBRARY_PATH="/Users/runner/work/rust/rust/build/aarch64-apple-darwin/test/run-make-cargo/apple-slow-tls/rmake_out:/Users/runner/work/rust/rust/build/aarch64-apple-darwin/stage2/lib:/Users/runner/work/rust/rust/build/aarch64-apple-darwin/bootstrap-tools/aarch64-apple-darwin/release/build/run_make_support/c00adef9f0e6a71b/out:/Users/runner/work/rust/rust/build/aarch64-apple-darwin/stage0/lib/rustlib/aarch64-apple-darwin/lib" "/Users/runner/work/rust/rust/build/aarch64-apple-darwin/stage2-tools-bin/cargo" "b" "--manifest-path" "tls_test/Cargo.toml" "--target" "t.json" "-Zbuild-std=std,core,panic_abort" "-Zjson-target-spec"
output status: `exit status: 101`
=== STDOUT ===



=== STDERR ===
    Blocking waiting for file lock on package cache

Bryanskiy · 2026-08-04T09:41:29Z

Hmm, In the current implementation of build-std it is allowed to pass panic runtime to the list of arguments: -Zbuild-std=std,core,panic_abort. Therefore, panic_abort might be compiled first with the unwind panic strategy (i.e., panic != abort in the Cargo profile) and then during injection trigger a NoPanicStrategy error(we now always inject panic_abort). What do you think we should do about this?
~~1) Temporarily remove the error from rustc until input validation is implemented in Cargo.~~
~~2) Just remove panic_abort from the test, as this behavior seems to be correct.~~

bjorn3 · 2026-08-04T10:02:23Z

rust/library/Cargo.toml

Lines 75 to 81 in c9ff496

    
           [profile.dist.package.panic_abort] 
        
           rustflags = [ 
        
               "-Cpanic=abort", 
        
               "-Cembed-bitcode=yes", 
        
               "-Zunstable-options", 
        
               "-Cforce-frame-pointers=non-leaf", 
        
           ]

is supposed to ensure that panic_abort gets compiled with -Cpanic=abort, but I guess -Zbuild-std currently ignores that. Would it be possible to temporarily hard code -Cpanic=abort for panic_abort in cargo?

Bryanskiy · 2026-08-04T10:12:40Z

is supposed to ensure that panic_abort gets compiled with -Cpanic=abort

~~Yes, but not when panic_abort is passed as an argument. By the way, this override is also ignored by cargo-features = ["panic-immediate-abort"].~~

Would it be possible to temporarily hard code -Cpanic=abort for panic_abort in cargo?

The whole point of this change is to remove the use of panic runtimes from Cargo. Otherwise, we could just pass them with --extern

bjorn3 · 2026-08-04T10:16:38Z

Would it be possible to temporarily hard code -Cpanic=abort for panic_abort in cargo?

The whole point of this change is to remove the use of panic runtimes from Cargo. Otherwise, we could just pass them with --extern

I mean temporarily until cargo respects rustflags in the standard library workspace Cargo.toml. panic_abort has to be compiled with -Cpanic=abort one way or another.

adamgemmell · 2026-08-04T10:49:55Z

Removed my last comment, I think I misunderstood the premise. If the issue only happens when panic_abort is passed via --extern, yes hardcoding panic abort in Cargo temporarily seems fine. You could also just remove panic_abort from the list of crates if you're sure they're no longer need to be specified.

add tests for loading injected crates

9e11f3c

rustbot assigned TaKO8Ki Jul 27, 2026

rustbot added A-run-make Area: port run-make Makefiles to rmake.rs S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jul 27, 2026

rustbot added S-blocked Status: Blocked on something else such as an RFC or other implementation work. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 27, 2026

petrochenkov self-assigned this Jul 27, 2026

Bryanskiy force-pushed the load-injected branch 3 times, most recently from 2b1ab0a to 6f99176 Compare July 29, 2026 18:44

Bryanskiy changed the title ~~allow -Ldependency search paths for injected crates~~ allow -Ldependency search paths for panic runtimes Jul 29, 2026

tests: emit llvm-ir to avoid running the linker

3396d86

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

rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 3, 2026

JonathanBrouwer mentioned this pull request Aug 3, 2026

Rollup of 21 pull requests #160437

Closed

JonathanBrouwer mentioned this pull request Aug 3, 2026

Rollup of 23 pull requests #160455

Closed

rust-bors Bot 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-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Aug 3, 2026

This comment has been minimized.

Sign in to view

rust-bors Bot pushed a commit that referenced this pull request Aug 3, 2026

Auto merge of #160007 - Bryanskiy:load-injected, r=<try>

5dfe67d

allow `-Ldependency` search paths for panic runtimes try-job: aarch64-apple

Uh oh!

Uh oh!

Conversation

Bryanskiy commented Jul 27, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Jul 27, 2026

Uh oh!

Bryanskiy commented Jul 27, 2026

Uh oh!

bjorn3 commented Jul 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

petrochenkov commented Jul 27, 2026

Uh oh!

bjorn3 commented Jul 27, 2026

Uh oh!

petrochenkov commented Jul 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bjorn3 commented Jul 27, 2026

Uh oh!

Bryanskiy commented Jul 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

adamgemmell commented Jul 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bjorn3 commented Jul 27, 2026

Uh oh!

adamgemmell commented Jul 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Bryanskiy commented Jul 27, 2026

Uh oh!

Bryanskiy commented Jul 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bjorn3 commented Jul 27, 2026

Uh oh!

petrochenkov commented Jul 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Bryanskiy commented Jul 28, 2026

Uh oh!

adamgemmell commented Jul 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Bryanskiy commented Jul 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rust-bors Bot commented Jul 31, 2026

Uh oh!

Bryanskiy commented Jul 31, 2026

Uh oh!

Bryanskiy commented Jul 31, 2026

Uh oh!

Bryanskiy commented Aug 3, 2026

Uh oh!

bjorn3 commented Aug 3, 2026

Uh oh!

rust-bors Bot commented Aug 3, 2026

Uh oh!

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

Uh oh!

Uh oh!

rust-bors Bot commented Aug 3, 2026

Uh oh!

This comment has been minimized.

rust-bors Bot commented Aug 3, 2026

Uh oh!

rust-log-analyzer commented Aug 3, 2026

Uh oh!

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

Uh oh!

Uh oh!

bjorn3 commented Aug 4, 2026

Uh oh!

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

Uh oh!

Bryanskiy commented Jul 27, 2026 •

edited by rustbot

Loading

bjorn3 commented Jul 27, 2026 •

edited

Loading

petrochenkov commented Jul 27, 2026 •

edited

Loading

Bryanskiy commented Jul 27, 2026 •

edited

Loading

adamgemmell commented Jul 27, 2026 •

edited

Loading

adamgemmell commented Jul 27, 2026 •

edited

Loading

Bryanskiy commented Jul 27, 2026 •

edited

Loading

petrochenkov commented Jul 28, 2026 •

edited

Loading

adamgemmell commented Jul 28, 2026 •

edited

Loading

Bryanskiy commented Jul 29, 2026 •

edited

Loading

JonathanBrouwer commented Aug 3, 2026 •

edited

Loading

Bryanskiy commented Aug 4, 2026 •

edited

Loading

Bryanskiy commented Aug 4, 2026 •

edited

Loading