Change __rust_no_alloc_shim_is_unstable to be a function #141061

dpaoliello · 2025-05-15T23:39:25Z

This fixes a long sequence of issues:

A customer reported that building for Arm64EC was broken: Linking error when compiled to arm64ec-pc-windows-msvc #138541
This was caused by a bug in my original implementation of Arm64EC support, namely that only functions on Arm64EC need to be decorated with # but Rust was decorating statics as well.
Once I corrected Rust to only decorate functions, I started linking failures where the linker couldn't find statics exported by dylib dependencies. This was caused by the compiler not marking exported statics in the generated DEF file with DATA, thus they were being exported as functions not data.
Once I corrected the way that the DEF files were being emitted, the linker started failing saying that it couldn't find __rust_no_alloc_shim_is_unstable. This is because the MSVC linker requires the declarations of statics imported from other dylibs to be marked with dllimport (whereas it will happily link to functions imported from other dylibs whether they are marked dllimport or not).
I then made a change to ensure that __rust_no_alloc_shim_is_unstable was marked as dllimport, but the MSVC linker started emitting warnings that __rust_no_alloc_shim_is_unstable was marked as dllimport but was declared in an obj file. This is a harmless warning which is a performance hint: anything that's marked dllimport must be indirected via an __imp symbol so I added a linker arg in the target to suppress the warning.
A customer then reported a similar warning when using lld-link (Fix linking statics on Arm64EC #140176 (comment)). I don't think it was an implementation difference between the two linkers but rather that, depending on the obj that the declaration versus uses of __rust_no_alloc_shim_is_unstable landed in we would get different warnings, so I suppressed that warning as well: [win] Ignore MSVC linker warning 4217 #140954.
Another customer reported that they weren't using the Rust compiler to invoke the linker, thus these warnings were breaking their build: Fix linking statics on Arm64EC #140176 (comment). At that point, my original change was reverted (Revert "Fix linking statics on Arm64EC #140176" #141024) leaving Arm64EC broken yet again.

Taking a step back, a lot of these linker issues arise from the fact that __rust_no_alloc_shim_is_unstable is marked as extern "Rust" in the standard library and, therefore, assumed to be a foreign item from a different crate BUT the Rust compiler may choose to generate it either in the current crate, some other crate that will be statically linked in OR some other crate that will by dynamically imported.

Worse yet, it is impossible while building a given crate to know if __rust_no_alloc_shim_is_unstable will statically linked or dynamically imported: it might be that one of its dependent crates is the one with an allocator kind set and thus that crate (which is compiled later) will decide depending if it has any dylib dependencies or not to import __rust_no_alloc_shim_is_unstable or generate it. Thus, there is no way to know if the declaration of __rust_no_alloc_shim_is_unstable should be marked with dllimport or not.

There is a simple fix for all this: there is no reason __rust_no_alloc_shim_is_unstable must be a static. It needs to be some symbol that must be linked in; thus, it could easily be a function instead. As a function, there is no need to mark it as dllimport when dynamically imported which avoids the entire mess above.

There may be a perf hit for changing the volatile load to be a tail call, so I'm happy to change that part back (although I question what the codegen of a volatile load would look like, and if the backend is going to try to use load-acquire semantics).

Build with this change applied BEFORE #140176 was reverted to demonstrate that there are no linking issues with either MSVC or MinGW: https://github.com/rust-lang/rust/actions/runs/15078657205

Incidentally, I fixed tests/run-make/no-alloc-shim to work with MSVC as I needed it to be able to test locally (FYI for #128602)

r? @bjorn3
cc @jieyouxu

bjorn3 · 2025-05-18T16:30:26Z

Do you have a link to the problems you are having?

dpaoliello · 2025-05-19T17:18:44Z

Do you have a link to the problems you are having?

Yes, sorry, I was intending to add a full write-up to the description once I had done the PR builds to validate that this works with both MinGW and MSVC. I've updated the description now.

rustbot · 2025-05-19T17:19:07Z

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

This PR modifies run-make tests.

cc @jieyouxu

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

dpaoliello · 2025-05-19T17:20:12Z

YAML changes were for testing.
@rustbot label -T-infra

bjorn3

How do we handle regular #[no_mangle] statics that doesn't cause those linker warnings/errors?

bjorn3 · 2025-05-19T17:24:14Z

library/alloc/src/alloc.rs

+    #[rustc_nounwind]
+    #[rustc_std_internal_symbol]
+    #[cfg(not(bootstrap))]
+    fn __rust_no_alloc_shim_is_unstable();


At the very least this symbol name will need to be changed to prevent UB when someone uses the old definition.

Good point, I'll rename it.

bjorn3 · 2025-05-19T17:27:09Z

library/alloc/src/alloc.rs

        core::ptr::read_volatile(&__rust_no_alloc_shim_is_unstable);
+        #[cfg(not(bootstrap))]
+        __rust_no_alloc_shim_is_unstable();


Would read_volatile(__rust_no_alloc_shim_is_unstable.addr().cast::<u8>()) (using the unstable FnPtr::addr method) work? Or maybe one of OpenBSD's exploit mitigations would break with that. Do we even care about that?

That would work for most platforms.

I'm not sure about OpenBSD, but it would certainly cause issues in Xbox kernel-mode, as it loads binaries as Execute-Only (i.e., they are not readable).

Again, I suspect that the volatile read is more expensive than a tail call to empty function as it may generate load-acquire semantics.

I'm not sure if we could get away with just getting the address of the function and not reading from it? Backends might optimize that away though...

Maybe black_box(__rust_no_alloc_shim_is_unstable as fn())?

Would read_volatile(__rust_no_alloc_shim_is_unstable.addr().cast::()) (using the unstable FnPtr::addr method) work?

Miri would definitely complain about that.

Maybe black_box(__rust_no_alloc_shim_is_unstable as fn())?

Doesn't work: we get the correct behavior where it is required for linking to work, but then the codegen tests fail as the compiler is not able to optimize away allocations.

compiler/rustc_codegen_gcc/src/allocator.rs

dpaoliello · 2025-05-19T18:49:45Z

How do we handle regular #[no_mangle] statics that doesn't cause those linker warnings/errors?

If the static is exported by one crate and referenced by another, then the compiler knows whether that static will be statically linked or dynamically imported since it can see the dependency chain between the current crate using the static and the declaring crate.

If the static is referenced via an extern block, then it is up to the user to correctly decorate it with a #[link] attribute. If they get that attribute wrong (mark it as dynamically imported when it is statically linked AND the declaration is in an obj being linked in, not an rlib) then they will see the linker warning.

rustbot · 2025-05-19T19:09:27Z

The Miri subtree was changed

cc @rust-lang/miri

bjorn3 · 2025-05-19T19:45:39Z

If the static is exported by one crate and referenced by another, then the compiler knows whether that static will be statically linked or dynamically imported since it can see the dependency chain between the current crate using the static and the declaring crate.

If the static is defined inside an rlib, and we are currently compiling an rlib, rustc can't know if the static will be statically linked or dynamically imported. Only when we are linking the current rlib into something do we know if the other rlib was statically linked or dynamically linked.

dpaoliello · 2025-05-19T19:52:47Z

If the static is exported by one crate and referenced by another, then the compiler knows whether that static will be statically linked or dynamically imported since it can see the dependency chain between the current crate using the static and the declaring crate.

If the static is defined inside an rlib, and we are currently compiling an rlib, rustc can't know if the static will be statically linked or dynamically imported. Only when we are linking the current rlib into something do we know if the other rlib was statically linked or dynamically linked.

The warning is only emitted if something marked with dllimport is declared either in the current obj file or another obj file that is currently being linked: the MSVC linker doesn't complain if it's declared in a static library (.lib or .rlib).

Change __rust_no_alloc_shim_is_unstable to be a function This fixes a long sequence of issues: 1. A customer reported that building for Arm64EC was broken: rust-lang#138541 2. This was caused by a bug in my original implementation of Arm64EC support, namely that only functions on Arm64EC need to be decorated with `#` but Rust was decorating statics as well. 3. Once I corrected Rust to only decorate functions, I started linking failures where the linker couldn't find statics exported by dylib dependencies. This was caused by the compiler not marking exported statics in the generated DEF file with `DATA`, thus they were being exported as functions not data. 4. Once I corrected the way that the DEF files were being emitted, the linker started failing saying that it couldn't find `__rust_no_alloc_shim_is_unstable`. This is because the MSVC linker requires the declarations of statics imported from other dylibs to be marked with `dllimport` (whereas it will happily link to functions imported from other dylibs whether they are marked `dllimport` or not). 5. I then made a change to ensure that `__rust_no_alloc_shim_is_unstable` was marked as `dllimport`, but the MSVC linker started emitting warnings that `__rust_no_alloc_shim_is_unstable` was marked as `dllimport` but was declared in an obj file. This is a harmless warning which is a performance hint: anything that's marked `dllimport` must be indirected via an `__imp` symbol so I added a linker arg in the target to suppress the warning. 6. A customer then reported a similar warning when using `lld-link` (<rust-lang#140176 (comment)>). I don't think it was an implementation difference between the two linkers but rather that, depending on the obj that the declaration versus uses of `__rust_no_alloc_shim_is_unstable` landed in we would get different warnings, so I suppressed that warning as well: rust-lang#140954. 7. Another customer reported that they weren't using the Rust compiler to invoke the linker, thus these warnings were breaking their build: <rust-lang#140176 (comment)>. At that point, my original change was reverted (rust-lang#141024) leaving Arm64EC broken yet again. Taking a step back, a lot of these linker issues arise from the fact that `__rust_no_alloc_shim_is_unstable` is marked as `extern "Rust"` in the standard library and, therefore, assumed to be a foreign item from a different crate BUT the Rust compiler may choose to generate it either in the current crate, some other crate that will be statically linked in OR some other crate that will by dynamically imported. Worse yet, it is impossible while building a given crate to know if `__rust_no_alloc_shim_is_unstable` will statically linked or dynamically imported: it might be that one of its dependent crates is the one with an allocator kind set and thus that crate (which is compiled later) will decide depending if it has any dylib dependencies or not to import `__rust_no_alloc_shim_is_unstable` or generate it. Thus, there is no way to know if the declaration of `__rust_no_alloc_shim_is_unstable` should be marked with `dllimport` or not. There is a simple fix for all this: there is no reason `__rust_no_alloc_shim_is_unstable` must be a static. It needs to be some symbol that must be linked in; thus, it could easily be a function instead. As a function, there is no need to mark it as `dllimport` when dynamically imported which avoids the entire mess above. There may be a perf hit for changing the `volatile load` to be a `tail call`, so I'm happy to change that part back (although I question what the codegen of a `volatile load` would look like, and if the backend is going to try to use load-acquire semantics). Build with this change applied BEFORE rust-lang#140176 was reverted to demonstrate that there are no linking issues with either MSVC or MinGW: <https://github.com/rust-lang/rust/actions/runs/15078657205> Incidentally, I fixed `tests/run-make/no-alloc-shim` to work with MSVC as I needed it to be able to test locally (FYI for rust-lang#128602) r? `@bjorn3` cc `@jieyouxu`

src/tools/miri/src/shims/extern_static.rs

RalfJung · 2025-06-07T13:20:06Z

@bors r-

bjorn3 · 2025-06-09T18:37:47Z

@bors r+

bors · 2025-06-09T18:37:50Z

📌 Commit cbdbd81 has been approved by bjorn3

It is now in the queue for this repository.

Change __rust_no_alloc_shim_is_unstable to be a function This fixes a long sequence of issues: 1. A customer reported that building for Arm64EC was broken: rust-lang#138541 2. This was caused by a bug in my original implementation of Arm64EC support, namely that only functions on Arm64EC need to be decorated with `#` but Rust was decorating statics as well. 3. Once I corrected Rust to only decorate functions, I started linking failures where the linker couldn't find statics exported by dylib dependencies. This was caused by the compiler not marking exported statics in the generated DEF file with `DATA`, thus they were being exported as functions not data. 4. Once I corrected the way that the DEF files were being emitted, the linker started failing saying that it couldn't find `__rust_no_alloc_shim_is_unstable`. This is because the MSVC linker requires the declarations of statics imported from other dylibs to be marked with `dllimport` (whereas it will happily link to functions imported from other dylibs whether they are marked `dllimport` or not). 5. I then made a change to ensure that `__rust_no_alloc_shim_is_unstable` was marked as `dllimport`, but the MSVC linker started emitting warnings that `__rust_no_alloc_shim_is_unstable` was marked as `dllimport` but was declared in an obj file. This is a harmless warning which is a performance hint: anything that's marked `dllimport` must be indirected via an `__imp` symbol so I added a linker arg in the target to suppress the warning. 6. A customer then reported a similar warning when using `lld-link` (<rust-lang#140176 (comment)>). I don't think it was an implementation difference between the two linkers but rather that, depending on the obj that the declaration versus uses of `__rust_no_alloc_shim_is_unstable` landed in we would get different warnings, so I suppressed that warning as well: rust-lang#140954. 7. Another customer reported that they weren't using the Rust compiler to invoke the linker, thus these warnings were breaking their build: <rust-lang#140176 (comment)>. At that point, my original change was reverted (rust-lang#141024) leaving Arm64EC broken yet again. Taking a step back, a lot of these linker issues arise from the fact that `__rust_no_alloc_shim_is_unstable` is marked as `extern "Rust"` in the standard library and, therefore, assumed to be a foreign item from a different crate BUT the Rust compiler may choose to generate it either in the current crate, some other crate that will be statically linked in OR some other crate that will by dynamically imported. Worse yet, it is impossible while building a given crate to know if `__rust_no_alloc_shim_is_unstable` will statically linked or dynamically imported: it might be that one of its dependent crates is the one with an allocator kind set and thus that crate (which is compiled later) will decide depending if it has any dylib dependencies or not to import `__rust_no_alloc_shim_is_unstable` or generate it. Thus, there is no way to know if the declaration of `__rust_no_alloc_shim_is_unstable` should be marked with `dllimport` or not. There is a simple fix for all this: there is no reason `__rust_no_alloc_shim_is_unstable` must be a static. It needs to be some symbol that must be linked in; thus, it could easily be a function instead. As a function, there is no need to mark it as `dllimport` when dynamically imported which avoids the entire mess above. There may be a perf hit for changing the `volatile load` to be a `tail call`, so I'm happy to change that part back (although I question what the codegen of a `volatile load` would look like, and if the backend is going to try to use load-acquire semantics). Build with this change applied BEFORE rust-lang#140176 was reverted to demonstrate that there are no linking issues with either MSVC or MinGW: <https://github.com/rust-lang/rust/actions/runs/15078657205> Incidentally, I fixed `tests/run-make/no-alloc-shim` to work with MSVC as I needed it to be able to test locally (FYI for rust-lang#128602) r? `@bjorn3` cc `@jieyouxu`

Rollup of 13 pull requests Successful merges: - #134442 (Specify the behavior of `file!`) - #134841 (Look at proc-macro attributes when encountering unknown attribute) - #140372 (Exhaustively handle parsed attributes in CheckAttr) - #140766 (Stabilize keylocker) - #141061 (Change __rust_no_alloc_shim_is_unstable to be a function) - #142042 (Make E0621 missing lifetime suggestion verbose) - #142101 (core::ptr: deduplicate more method docs) - #142176 (tests: Split dont-shuffle-bswaps along opt-levels and arches) - #142258 (platform-support.md: Mention specific Linux kernel version or later) - #142260 (Miri subtree update) - #142262 (Mark `core::slice::memchr` as `#[doc(hidden)]`) - #142272 (tests: Change ABIs in tests to more future-resilient ones) - #142275 (rustdoc: Refractor `clean_ty_generics`) r? `@ghost` `@rustbot` modify labels: rollup

Change __rust_no_alloc_shim_is_unstable to be a function This fixes a long sequence of issues: 1. A customer reported that building for Arm64EC was broken: rust-lang#138541 2. This was caused by a bug in my original implementation of Arm64EC support, namely that only functions on Arm64EC need to be decorated with `#` but Rust was decorating statics as well. 3. Once I corrected Rust to only decorate functions, I started linking failures where the linker couldn't find statics exported by dylib dependencies. This was caused by the compiler not marking exported statics in the generated DEF file with `DATA`, thus they were being exported as functions not data. 4. Once I corrected the way that the DEF files were being emitted, the linker started failing saying that it couldn't find `__rust_no_alloc_shim_is_unstable`. This is because the MSVC linker requires the declarations of statics imported from other dylibs to be marked with `dllimport` (whereas it will happily link to functions imported from other dylibs whether they are marked `dllimport` or not). 5. I then made a change to ensure that `__rust_no_alloc_shim_is_unstable` was marked as `dllimport`, but the MSVC linker started emitting warnings that `__rust_no_alloc_shim_is_unstable` was marked as `dllimport` but was declared in an obj file. This is a harmless warning which is a performance hint: anything that's marked `dllimport` must be indirected via an `__imp` symbol so I added a linker arg in the target to suppress the warning. 6. A customer then reported a similar warning when using `lld-link` (<rust-lang#140176 (comment)>). I don't think it was an implementation difference between the two linkers but rather that, depending on the obj that the declaration versus uses of `__rust_no_alloc_shim_is_unstable` landed in we would get different warnings, so I suppressed that warning as well: rust-lang#140954. 7. Another customer reported that they weren't using the Rust compiler to invoke the linker, thus these warnings were breaking their build: <rust-lang#140176 (comment)>. At that point, my original change was reverted (rust-lang#141024) leaving Arm64EC broken yet again. Taking a step back, a lot of these linker issues arise from the fact that `__rust_no_alloc_shim_is_unstable` is marked as `extern "Rust"` in the standard library and, therefore, assumed to be a foreign item from a different crate BUT the Rust compiler may choose to generate it either in the current crate, some other crate that will be statically linked in OR some other crate that will by dynamically imported. Worse yet, it is impossible while building a given crate to know if `__rust_no_alloc_shim_is_unstable` will statically linked or dynamically imported: it might be that one of its dependent crates is the one with an allocator kind set and thus that crate (which is compiled later) will decide depending if it has any dylib dependencies or not to import `__rust_no_alloc_shim_is_unstable` or generate it. Thus, there is no way to know if the declaration of `__rust_no_alloc_shim_is_unstable` should be marked with `dllimport` or not. There is a simple fix for all this: there is no reason `__rust_no_alloc_shim_is_unstable` must be a static. It needs to be some symbol that must be linked in; thus, it could easily be a function instead. As a function, there is no need to mark it as `dllimport` when dynamically imported which avoids the entire mess above. There may be a perf hit for changing the `volatile load` to be a `tail call`, so I'm happy to change that part back (although I question what the codegen of a `volatile load` would look like, and if the backend is going to try to use load-acquire semantics). Build with this change applied BEFORE rust-lang#140176 was reverted to demonstrate that there are no linking issues with either MSVC or MinGW: <https://github.com/rust-lang/rust/actions/runs/15078657205> Incidentally, I fixed `tests/run-make/no-alloc-shim` to work with MSVC as I needed it to be able to test locally (FYI for rust-lang#128602) r? ``@bjorn3`` cc ``@jieyouxu``

Rollup of 12 pull requests Successful merges: - #134442 (Specify the behavior of `file!`) - #134841 (Look at proc-macro attributes when encountering unknown attribute) - #140372 (Exhaustively handle parsed attributes in CheckAttr) - #140766 (Stabilize keylocker) - #141061 (Change __rust_no_alloc_shim_is_unstable to be a function) - #142042 (Make E0621 missing lifetime suggestion verbose) - #142101 (core::ptr: deduplicate more method docs) - #142258 (platform-support.md: Mention specific Linux kernel version or later) - #142260 (Miri subtree update) - #142262 (Mark `core::slice::memchr` as `#[doc(hidden)]`) - #142272 (tests: Change ABIs in tests to more future-resilient ones) - #142275 (rustdoc: Refractor `clean_ty_generics`) r? `@ghost` `@rustbot` modify labels: rollup

RalfJung · 2025-06-10T10:32:47Z

@bors r-
failed in #142283

dpaoliello · 2025-06-10T16:41:30Z

@bjorn3 could you please help me understand how this test was passing before?

It's a linker failure in the tests/ui/sanitizer/dataflow.rs test.

   = note: /usr/bin/ld: /checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/sanitizer/dataflow/a.dataflow.a934cfd234e75439-cgu.0.rcgu.o: in function `_ZN8dataflow4main17h053d7a3d932e2846E.dfsan':
           dataflow.a934cfd234e75439-cgu.0:(.text._ZN8dataflow4main17h053d7a3d932e2846E.dfsan+0x161): undefined reference to `_RNvCsi58mtoTmQEJ_7___rustc35___rust_no_alloc_shim_is_unstable_v2.dfsan'
           collect2: error: ld returned 1 exit status

Was the load previously being optimized out? Seems like some of the other tests would have caught that...

dpaoliello · 2025-06-10T16:42:53Z

Oh, interesting, the symbol has a .dfsan suffix... so is this a name mangling issue? Or are we supposed to be generating a different symbol name for this case?

bjorn3 · 2025-06-10T16:49:20Z

I suspect this sanitizer mangles the names of functions, but not of globals. I think the issue here is that the version script for libstd.so only exported the non-.dfsan version, while the executable needs the .dfsan version.

dpaoliello · 2025-06-10T18:15:12Z

Ugh, ok, so we need to generate the shim if the crate that would generate the shim has different sanitizers enabled? Or are there some sanitizers that don't change mangling?

bjorn3 · 2025-06-10T18:22:54Z

@rcvalle how is the dataflow sanitizer supposed to handle the case where the standard library is compiled without it enabled, but the main executable is compiled with it enabled. Is that supposed to work or does the minimal test that you added work by accident before this PR? And if it is supposed to work, is there a way to predict when the symbol mangling happens such that we can change the version script accordingly?

dpaoliello · 2025-06-10T19:07:15Z

Looks like we could apply the DisableSanitizerInstrumentation attribute to it to disable dfsan from messing with it, but there's currently no Rust attribute which maps to that. Doesn't really work with the existing no_sanitize attribute since it disables a bunch of different sanitizers.

rustbot assigned bjorn3 May 15, 2025

This comment has been minimized.

Sign in to view

dpaoliello force-pushed the shimasfn branch from 8aa8b03 to 9c1e636 Compare May 16, 2025 16:55

This comment has been minimized.

Sign in to view

dpaoliello force-pushed the shimasfn branch from 9c1e636 to 6280a2f Compare May 16, 2025 20:37

rustbot added the A-run-make Area: port run-make Makefiles to rmake.rs label May 16, 2025

This comment has been minimized.

Sign in to view

dpaoliello force-pushed the shimasfn branch from 6280a2f to 7ebb72c Compare May 16, 2025 22:41

dpaoliello force-pushed the shimasfn branch from 7ebb72c to cee5245 Compare May 19, 2025 17:18

dpaoliello marked this pull request as ready for review May 19, 2025 17:19

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label May 19, 2025

rustbot removed the T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue. label May 19, 2025

bjorn3 reviewed May 19, 2025

View reviewed changes

antoyo reviewed May 19, 2025

View reviewed changes

compiler/rustc_codegen_gcc/src/allocator.rs Show resolved Hide resolved

jieyouxu added A-linkage Area: linking into static, shared libraries and binaries A-allocators Area: Custom and system allocators labels May 19, 2025

dpaoliello force-pushed the shimasfn branch from cee5245 to e3597ca Compare May 19, 2025 19:09

This comment has been minimized.

Sign in to view

bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Jun 5, 2025

jieyouxu mentioned this pull request Jun 5, 2025

run-make: audit the ignore-{windows,msvc,windows-msvc} tests #128602

Open

28 tasks

GuillaumeGomez mentioned this pull request Jun 7, 2025

Rollup of 6 pull requests #142153

Closed

RalfJung reviewed Jun 7, 2025

View reviewed changes

src/tools/miri/src/shims/extern_static.rs Show resolved Hide resolved

RalfJung mentioned this pull request Jun 7, 2025

Enable Non-determinism of float operations in Miri and change std tests #138062

Merged

bors 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 Jun 7, 2025

Change __rust_no_alloc_shim_is_unstable to be a function

cbdbd81

dpaoliello force-pushed the shimasfn branch from 163d29a to cbdbd81 Compare June 9, 2025 17:12

bors 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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jun 9, 2025

workingjubilee mentioned this pull request Jun 10, 2025

Rollup of 13 pull requests #142278

Closed

workingjubilee mentioned this pull request Jun 10, 2025

Rollup of 12 pull requests #142283

Closed

bors 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 Jun 10, 2025

Change __rust_no_alloc_shim_is_unstable to be a function #141061

Are you sure you want to change the base?

Change __rust_no_alloc_shim_is_unstable to be a function #141061

Conversation

dpaoliello commented May 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

bjorn3 commented May 18, 2025

Uh oh!

dpaoliello commented May 19, 2025

Uh oh!

rustbot commented May 19, 2025

Uh oh!

dpaoliello commented May 19, 2025

Uh oh!

bjorn3 left a comment

Choose a reason for hiding this comment

Uh oh!

bjorn3 May 19, 2025

Choose a reason for hiding this comment

Uh oh!

dpaoliello May 19, 2025

Choose a reason for hiding this comment

Uh oh!

bjorn3 May 19, 2025

Choose a reason for hiding this comment

Uh oh!

dpaoliello May 19, 2025

Choose a reason for hiding this comment

Uh oh!

bjorn3 May 19, 2025

Choose a reason for hiding this comment

Uh oh!

RalfJung May 19, 2025

Choose a reason for hiding this comment

Uh oh!

dpaoliello May 19, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

dpaoliello commented May 19, 2025

Uh oh!

rustbot commented May 19, 2025

Uh oh!

This comment has been minimized.

bjorn3 commented May 19, 2025

Uh oh!

dpaoliello commented May 19, 2025

Uh oh!

Uh oh!

RalfJung commented Jun 7, 2025

Uh oh!

bjorn3 commented Jun 9, 2025

Uh oh!

bors commented Jun 9, 2025

Uh oh!

RalfJung commented Jun 10, 2025

Uh oh!

dpaoliello commented Jun 10, 2025

Uh oh!

dpaoliello commented Jun 10, 2025

Uh oh!

bjorn3 commented Jun 10, 2025

Uh oh!

dpaoliello commented Jun 10, 2025

Uh oh!

bjorn3 commented Jun 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dpaoliello commented Jun 10, 2025

Uh oh!

Uh oh!

dpaoliello commented May 15, 2025 •

edited

Loading

bjorn3 commented Jun 10, 2025 •

edited

Loading