document #[global_allocator] constraints by RalfJung · Pull Request #159720 · rust-lang/rust

RalfJung · 2026-07-22T14:36:07Z

#[global_allocator] is opsem magic. For instance, even if we do

use std::alloc::System;

#[global_allocator]
static ALLOC: System = System;

it is still UB to allocate via std::alloc::alloc() and deallocate via System.dealloc(). This is because we add special magic LLVM attributes in the #[global_allocator] machinery that tell LLVM about our global allocation methods so it can optimize accordingly, and mixing allocators is against those rules.

Cc @rust-lang/opsem @rust-lang/lang @nia-e @maxdexh
@nikic is this enough to ensure that adding your intrinsics is sound?

rustbot · 2026-07-22T14:36:10Z

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

rustbot · 2026-07-22T14:36:13Z

r? @aapoalas

rustbot has assigned @aapoalas.
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: libs
libs expanded to 12 candidates
Random selection from 7 candidates

RalfJung · 2026-07-22T15:23:50Z

    /// Clients wishing to abort computation in response to an
    /// allocation error are encouraged to call the [`handle_alloc_error`] function,
-    /// rather than directly invoking `panic!` or similar.
+    /// rather than directly invoking `panic!` or similar (but note that both may unwind).


This may need updating if #159702 lands as-is

View changes since the review

RalfJung · 2026-07-23T07:43:26Z

Always great when you push to your branch and github doesn't show the changes...

Anyway I pushed a note to alloc saying that the contents of that allocation are uninitialized even if the allocator previously initialized them. I'll add a similar note to dealloc saying that the allocator will see uninitialized memory inside the allocation even if the program previously initialized the allocation contents.

RalfJung · 2026-07-23T07:55:43Z

Oh great this time it is not even showing the "processing push" thing. It's just.. ignoring my push entirely?

maxdexh · 2026-07-23T07:58:10Z

the contents of that allocation are uninitialized even if the allocator previously initialized them
the allocator will see uninitialized memory inside the allocation even if the program previously initialized the allocation contents

I assume that's for LLVM?

Maybe there could be some kind of requirement that users and implementors of global allocators can't assume anything about what the allocator/rest of the program does to the memory, other than that they follow the documented requirements?

Because I feel like you can still make some pretty weird assumptions if you know the allocator impl, like assuming that you are allowed to write slightly past the end of an allocation because you know that the global allocator you chose has left some unused space there (which to my understanding is not allowed by LLVM either). The current docs of the functions in alloc literally just state that calls are forwarded to the allocator registered with global_allocator.

RalfJung · 2026-07-23T08:08:04Z

Maybe there could be some kind of requirement that users and implementors of global allocators can't assume anything about what the allocator/rest of the program does to the memory, other than that they follow the documented requirements?

That's basically what this is, but I think we have to spell out what this means.

assuming that you are allowed to write slightly past the end of an allocation

Ah right, we need to add something about that.

maxdexh · 2026-07-23T08:10:41Z

It's kind of already there with the "you cannot access the memory until a pointer to it has been returned" (implicitly saying that the pointer is valid for the size of the allocation), but especially with the return value of Allocator::allocate being NonNull<[u8]>, someone could think the wrong thing.

RalfJung · 2026-07-23T08:20:00Z

Oh I guess here is where this already says "methods must implement their contract". But what is that part about "layout queries"? I have no idea what is even meant by this and what it has to do with the 2nd sentence.

View changes since the review

I read that as talking about some possible get_optimal_layout_for_size_and_align() method on allocators.

This was added when GlobalAlloc was stabilized. I think it's probably talking about the layout calculations in realloc.

I have removed the first sentence, and my new bullet point about implementing the contract.

RalfJung · 2026-07-23T09:11:10Z

+/// - The pointer passed to this function must have been obtained by invoking [`alloc`],
+///   [`alloc_zeroed`], or [`realloc`], *not* by invoking the underlying methods on [`GlobalAlloc`].


I have gone back and forth on whether this new text should be in the "safety" section or not. Some of it is preconditions, which we typically put in "safety" (e.g. this item here), others describe the postcondition, which we usually don't have in "safety".

View changes since the review

RalfJung · 2026-07-23T09:11:36Z

I extended the PR quite a bit with more things people need to be aware of, so if you read it previously then please have another look.

maxdexh · 2026-07-23T09:24:27Z

+/// cannot assume anything about what the allocator does, other than the documented requirements.
+/// This means:
+///
+/// - This function may non-deterministically entirely skip the underlying allocator, e.g. if the


That's a really nice way of deriving this requirement!

Sorry if I'm misremembering, but wasn't LLVM also allowed to spuriously introdoce new allocations?

View changes since the review

I don't think it can spuriously introduce new invocations of heap allocation methods. @nikic please correct me if I am wrong.

Also, fusing allocations is something it doesn't do atm but I think it would be nice to allow.

What do you mean by fusing?

Combining multiple calls to alloc into one. I've seen someone implement something like this as an optimization pass in llvm.

At least currently the LLVM LangRef doesn't permit this.

But I guess we could add something like, "the compiler may also combine multiple allocation operations into one, as long as it can also adjust all corresponding deallocation operations accordingly".

I guess semantically this means that alloc and co are a wrapper around the registered global allocator that can nondeterministically decide how exactly the registered allocator is used.

Yes that's exactly what it is. That wrapper also does all the other things: it creates a new allocation with fresh provenance for the return value of alloc, stores the original provenance somewhere, and blocks access to that part of the underlying allocation (also resetting its contents to uninitialized). Then on dealloc is looks up the original provenance, destroys the new allocation, and gives the underlying pointer to the GlobalAlloc impl.

maxdexh · 2026-07-23T09:37:12Z

+/// * It is undefined behavior for the allocator to read, write, or deallocate any memory that
+///   is *currently allocated*. This memory is owned by the user, the allocator must not touch it.
+///
 /// * It's undefined behavior if global allocators unwind. This restriction may


I think this (the "may be lifted in the future") means users of alloc and co still have to assume it can unwind. From the way that the docs of GlobalAlloc::alloc talks about handle_alloc_error, I think people will keep assuming this is not the case.

View changes since the review

The docs of GlobalAlloc::alloc say "note that both may unwind" with this PR.

I read that passage as "both panic! and handle_alloc_error may unwind", not about alloc itself?

"both panic! and handle_alloc_error may unwind",

Yes indeed. That's what you were talking about, no?

No, I meant that GlobalAlloc says "It's undefined behavior if global allocators unwind. This restriction may be lifted in the future" (I missed the correct line by one). To me that reads as: "Only std can assume that these methods do not unwind"

Ah that's what you mean. Yeah I read it the same way. I don't plan to touch that in this PR.

That's fair. I was more asking for a sentence about this on the GlobalAlloc methods or the alloc functions. Right now, this is in the safety docs of the trait, which is probably why noone using the alloc functions seems to know about it (anyone who has UB from misusing handle_alloc_error probably has UB from this too, and writing an aborting wrapper around handle_alloc_error is not enough!)

I added this to every one of these functions:

/// Users of this function have to consider that in the future, allocators may be allowed to unwind.

RalfJung · 2026-07-24T06:28:24Z

I think the answer is simply that they can't use NativeAllocator.

Or do they have use-cases for that with #[global_allocator]?

nikic · 2026-07-24T15:45:47Z

@bors r=aapoalas,nia-e,nikic

rust-bors · 2026-07-24T15:45:51Z

📌 Commit 8242b33 has been approved by aapoalas,nia-e,nikic

It is now in the queue for this repository.

🌲 The tree is currently closed for pull requests below priority 1. This pull request will be tested once the tree is reopened.

Reason for tree closure: spurious CI failures

@nia-e

…gic, r=aapoalas,nia-e,nikic document #[global_allocator] constraints `#[global_allocator]` is opsem magic. For instance, even if we do ```rust use std::alloc::System; #[global_allocator] static ALLOC: System = System; ``` it is still UB to allocate via `std::alloc::alloc()` and deallocate via `System.dealloc()`. This is because we add special magic LLVM attributes in the `#[global_allocator]` machinery that tell LLVM about our global allocation methods so it can optimize accordingly, and mixing allocators is against those rules. Cc @rust-lang/opsem @rust-lang/lang @nia-e @maxdexh @nikic is this enough to ensure that adding your intrinsics is sound?

@nia-e

…gic, r=aapoalas,nia-e,nikic document #[global_allocator] constraints `#[global_allocator]` is opsem magic. For instance, even if we do ```rust use std::alloc::System; #[global_allocator] static ALLOC: System = System; ``` it is still UB to allocate via `std::alloc::alloc()` and deallocate via `System.dealloc()`. This is because we add special magic LLVM attributes in the `#[global_allocator]` machinery that tell LLVM about our global allocation methods so it can optimize accordingly, and mixing allocators is against those rules. Cc @rust-lang/opsem @rust-lang/lang @nia-e @maxdexh @nikic is this enough to ensure that adding your intrinsics is sound?

Rollup of 17 pull requests Successful merges: - #158168 (Added implementation on `set_permissions_nofollow` for all primary platforms) - #138618 (Support using const pointers in asm `const` operand) - #157962 (Function item should not be used as const arg) - #158404 (trait_solver: normalize next-gen region constraints) - #158709 (rustdoc: warn on improperly interleaved HTML/MD) - #159720 (document #[global_allocator] constraints) - #159732 (optimization: don't look for diagnostic/canonical items without rustc_attrs enabled) - #159740 (reuse regular exported_non_generic_symbols logic in Miri) - #159780 (check `extern "custom"` function pointers) - #159786 (rustdoc-js: ignore editor temp files in test folder discovery) - #159819 (std::sync::poison: disable auto_cfg on PoisonError::new) - #155388 (stepping into where-clauses during normalization may be productive) - #155914 (when bailing on ambiguity, don't force other results to ambig) - #159411 ([rustdoc] Correctly handle output options with --show-coverage) - #159439 (Fix(lib/fs/win): Fall back on Win32 delete for `Dir::remove_file`) - #159809 (Avoid `#[target_features]`) - #159826 (Remove redundant `#[rustc_paren_sugar]` feature gate)

@nia-e

…gic, r=aapoalas,nia-e,nikic document #[global_allocator] constraints `#[global_allocator]` is opsem magic. For instance, even if we do ```rust use std::alloc::System; #[global_allocator] static ALLOC: System = System; ``` it is still UB to allocate via `std::alloc::alloc()` and deallocate via `System.dealloc()`. This is because we add special magic LLVM attributes in the `#[global_allocator]` machinery that tell LLVM about our global allocation methods so it can optimize accordingly, and mixing allocators is against those rules. Cc @rust-lang/opsem @rust-lang/lang @nia-e @maxdexh @nikic is this enough to ensure that adding your intrinsics is sound?

Rollup of 16 pull requests Successful merges: - #138618 (Support using const pointers in asm `const` operand) - #157962 (Function item should not be used as const arg) - #158404 (trait_solver: normalize next-gen region constraints) - #158709 (rustdoc: warn on improperly interleaved HTML/MD) - #159720 (document #[global_allocator] constraints) - #159732 (optimization: don't look for diagnostic/canonical items without rustc_attrs enabled) - #159740 (reuse regular exported_non_generic_symbols logic in Miri) - #159780 (check `extern "custom"` function pointers) - #159786 (rustdoc-js: ignore editor temp files in test folder discovery) - #159819 (std::sync::poison: disable auto_cfg on PoisonError::new) - #155388 (stepping into where-clauses during normalization may be productive) - #155914 (when bailing on ambiguity, don't force other results to ambig) - #159411 ([rustdoc] Correctly handle output options with --show-coverage) - #159439 (Fix(lib/fs/win): Fall back on Win32 delete for `Dir::remove_file`) - #159809 (Avoid `#[target_features]`) - #159826 (Remove redundant `#[rustc_paren_sugar]` feature gate)

@nia-e

…gic, r=aapoalas,nia-e,nikic document #[global_allocator] constraints `#[global_allocator]` is opsem magic. For instance, even if we do ```rust use std::alloc::System; #[global_allocator] static ALLOC: System = System; ``` it is still UB to allocate via `std::alloc::alloc()` and deallocate via `System.dealloc()`. This is because we add special magic LLVM attributes in the `#[global_allocator]` machinery that tell LLVM about our global allocation methods so it can optimize accordingly, and mixing allocators is against those rules. Cc @rust-lang/opsem @rust-lang/lang @nia-e @maxdexh @nikic is this enough to ensure that adding your intrinsics is sound?

@nia-e

…gic, r=aapoalas,nia-e,nikic document #[global_allocator] constraints `#[global_allocator]` is opsem magic. For instance, even if we do ```rust use std::alloc::System; #[global_allocator] static ALLOC: System = System; ``` it is still UB to allocate via `std::alloc::alloc()` and deallocate via `System.dealloc()`. This is because we add special magic LLVM attributes in the `#[global_allocator]` machinery that tell LLVM about our global allocation methods so it can optimize accordingly, and mixing allocators is against those rules. Cc @rust-lang/opsem @rust-lang/lang @nia-e @maxdexh @nikic is this enough to ensure that adding your intrinsics is sound?

Rollup of 20 pull requests Successful merges: - #138618 (Support using const pointers in asm `const` operand) - #157962 (Lower paths to functions in const args as ConstKind::Error) - #158404 (trait_solver: normalize next-gen region constraints) - #158709 (rustdoc: warn on improperly interleaved HTML/MD) - #159720 (document #[global_allocator] constraints) - #159732 (optimization: don't look for diagnostic/canonical items without rustc_attrs enabled) - #159738 (implement `CovariantUnsafeCell`) - #159740 (reuse regular exported_non_generic_symbols logic in Miri) - #159780 (check `extern "custom"` function pointers) - #159786 (rustdoc-js: ignore editor temp files in test folder discovery) - #159819 (std::sync::poison: disable auto_cfg on PoisonError::new) - #155388 (stepping into where-clauses during normalization may be productive) - #155914 (when bailing on ambiguity, don't force other results to ambig) - #159439 (Fix(lib/fs/win): Fall back on Win32 delete for `Dir::remove_file`) - #159676 (Update wasm-component-ld to 0.5.27) - #159730 (allow accessing the contents of UnsafeCell without going through get) - #159809 (Avoid `#[target_features]`) - #159826 (Remove redundant `#[rustc_paren_sugar]` feature gate) - #159853 (Updated expect messages for `CString` struct and method documentation) - #159877 (Revert "Export `derive` at `core::derive` and `std::derive`")

@nia-e

…alas,nia-e,nikic document #[global_allocator] constraints `#[global_allocator]` is opsem magic. For instance, even if we do ```rust use std::alloc::System; #[global_allocator] static ALLOC: System = System; ``` it is still UB to allocate via `std::alloc::alloc()` and deallocate via `System.dealloc()`. This is because we add special magic LLVM attributes in the `#[global_allocator]` machinery that tell LLVM about our global allocation methods so it can optimize accordingly, and mixing allocators is against those rules. Cc @rust-lang/opsem @rust-lang/lang @nia-e @maxdexh @nikic is this enough to ensure that adding your intrinsics is sound?

rust-bors · 2026-07-25T12:48:08Z

⌛ Testing commit 8242b33 with merge c885d74...

Workflow: https://github.com/rust-lang/rust/actions/runs/30158574019

jieyouxu · 2026-07-25T13:04:44Z

Yielding this to the enclosing rollup
@bors yield

rust-bors · 2026-07-25T13:04:47Z

Auto build was cancelled. Cancelled workflows:

https://github.com/rust-lang/rust/actions/runs/30158574019

The next pull request likely to be tested is #159857.

Rollup of 20 pull requests Successful merges: - #138618 (Support using const pointers in asm `const` operand) - #157962 (Lower paths to functions in const args as ConstKind::Error) - #158404 (trait_solver: normalize next-gen region constraints) - #158709 (rustdoc: warn on improperly interleaved HTML/MD) - #159720 (document #[global_allocator] constraints) - #159732 (optimization: don't look for diagnostic/canonical items without rustc_attrs enabled) - #159738 (implement `CovariantUnsafeCell`) - #159740 (reuse regular exported_non_generic_symbols logic in Miri) - #159780 (check `extern "custom"` function pointers) - #159786 (rustdoc-js: ignore editor temp files in test folder discovery) - #159819 (std::sync::poison: disable auto_cfg on PoisonError::new) - #155388 (stepping into where-clauses during normalization may be productive) - #155914 (when bailing on ambiguity, don't force other results to ambig) - #159439 (Fix(lib/fs/win): Fall back on Win32 delete for `Dir::remove_file`) - #159676 (Update wasm-component-ld to 0.5.27) - #159730 (allow accessing the contents of UnsafeCell without going through get) - #159809 (Avoid `#[target_features]`) - #159826 (Remove redundant `#[rustc_paren_sugar]` feature gate) - #159853 (Updated expect messages for `CString` struct and method documentation) - #159877 (Revert "Export `derive` at `core::derive` and `std::derive`")

@nia-e

…gic, r=aapoalas,nia-e,nikic document #[global_allocator] constraints `#[global_allocator]` is opsem magic. For instance, even if we do ```rust use std::alloc::System; #[global_allocator] static ALLOC: System = System; ``` it is still UB to allocate via `std::alloc::alloc()` and deallocate via `System.dealloc()`. This is because we add special magic LLVM attributes in the `#[global_allocator]` machinery that tell LLVM about our global allocation methods so it can optimize accordingly, and mixing allocators is against those rules. Cc @rust-lang/opsem @rust-lang/lang @nia-e @maxdexh @nikic is this enough to ensure that adding your intrinsics is sound?

Rollup of 23 pull requests Successful merges: - #159720 (document #[global_allocator] constraints) - #159732 (optimization: don't look for diagnostic/canonical items without rustc_attrs enabled) - #159738 (implement `CovariantUnsafeCell`) - #159740 (reuse regular exported_non_generic_symbols logic in Miri) - #159780 (check `extern "custom"` function pointers) - #159786 (rustdoc-js: ignore editor temp files in test folder discovery) - #159819 (std::sync::poison: disable auto_cfg on PoisonError::new) - #155388 (stepping into where-clauses during normalization may be productive) - #155914 (when bailing on ambiguity, don't force other results to ambig) - #159204 (Add support to caller_location to rustc_public) - #159411 ([rustdoc] Correctly handle output options with --show-coverage) - #159439 (Fix(lib/fs/win): Fall back on Win32 delete for `Dir::remove_file`) - #159676 (Update wasm-component-ld to 0.5.27) - #159730 (allow accessing the contents of UnsafeCell without going through get) - #159809 (Avoid `#[target_features]`) - #159810 (Add tuple never coercion collection regression test) - #159826 (Remove redundant `#[rustc_paren_sugar]` feature gate) - #159853 (Updated expect messages for `CString` struct and method documentation) - #159877 (Revert "Export `derive` at `core::derive` and `std::derive`") - #159878 (bootstrap: Remove obsolete option `build.compiletest-use-stage0-libtest`) - #159882 (Update expect messages in library/alloc/boxed.rs and library/alloc/string.rs to follow the style guide) - #159891 (Split multiline derives into std/rustc macros) - #159895 (rustc-dev-guide subtree update)

@nia-e

…gic, r=aapoalas,nia-e,nikic document #[global_allocator] constraints `#[global_allocator]` is opsem magic. For instance, even if we do ```rust use std::alloc::System; #[global_allocator] static ALLOC: System = System; ``` it is still UB to allocate via `std::alloc::alloc()` and deallocate via `System.dealloc()`. This is because we add special magic LLVM attributes in the `#[global_allocator]` machinery that tell LLVM about our global allocation methods so it can optimize accordingly, and mixing allocators is against those rules. Cc @rust-lang/opsem @rust-lang/lang @nia-e @maxdexh @nikic is this enough to ensure that adding your intrinsics is sound?

Rollup of 23 pull requests Successful merges: - #159673 (bootstrap: forward -fdebug-prefix-map when using cc) - #159720 (document #[global_allocator] constraints) - #159732 (optimization: don't look for diagnostic/canonical items without rustc_attrs enabled) - #159738 (implement `CovariantUnsafeCell`) - #159740 (reuse regular exported_non_generic_symbols logic in Miri) - #159780 (check `extern "custom"` function pointers) - #159786 (rustdoc-js: ignore editor temp files in test folder discovery) - #159819 (std::sync::poison: disable auto_cfg on PoisonError::new) - #155388 (stepping into where-clauses during normalization may be productive) - #155914 (when bailing on ambiguity, don't force other results to ambig) - #159204 (Add support to caller_location to rustc_public) - #159411 ([rustdoc] Correctly handle output options with --show-coverage) - #159439 (Fix(lib/fs/win): Fall back on Win32 delete for `Dir::remove_file`) - #159676 (Update wasm-component-ld to 0.5.27) - #159730 (allow accessing the contents of UnsafeCell without going through get) - #159809 (Avoid `#[target_features]`) - #159810 (Add tuple never coercion collection regression test) - #159826 (Remove redundant `#[rustc_paren_sugar]` feature gate) - #159853 (Updated expect messages for `CString` struct and method documentation) - #159878 (bootstrap: Remove obsolete option `build.compiletest-use-stage0-libtest`) - #159882 (Update expect messages in library/alloc/boxed.rs and library/alloc/string.rs to follow the style guide) - #159891 (Split multiline derives into std/rustc macros) - #159895 (rustc-dev-guide subtree update)

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Jul 22, 2026

rustbot assigned aapoalas Jul 22, 2026

RalfJung force-pushed the global-allocator-opsem-magic branch 2 times, most recently from d8c8418 to e85933c Compare July 22, 2026 14:40

RalfJung commented Jul 22, 2026

View reviewed changes

Comment thread library/core/src/alloc/global.rs Outdated

This comment has been minimized.

Sign in to view

maxdexh reviewed Jul 22, 2026

View reviewed changes

Comment thread library/core/src/alloc/global.rs Outdated

RalfJung force-pushed the global-allocator-opsem-magic branch from e85933c to 7b9e695 Compare July 22, 2026 15:23

RalfJung commented Jul 22, 2026

View reviewed changes

RalfJung force-pushed the global-allocator-opsem-magic branch from 7b9e695 to cdbc976 Compare July 22, 2026 15:24

RalfJung force-pushed the global-allocator-opsem-magic branch from cdbc976 to e19509c Compare July 23, 2026 07:46

RalfJung commented Jul 23, 2026

View reviewed changes

Comment thread library/core/src/alloc/global.rs Outdated

RalfJung force-pushed the global-allocator-opsem-magic branch from e19509c to 67dab72 Compare July 23, 2026 08:14

RalfJung commented Jul 23, 2026

View reviewed changes

This comment was marked as resolved.

Sign in to view

RalfJung force-pushed the global-allocator-opsem-magic branch from 67dab72 to 4edf593 Compare July 23, 2026 08:51

RalfJung commented Jul 23, 2026

View reviewed changes

maxdexh reviewed Jul 23, 2026

View reviewed changes

Comment thread library/alloc/src/alloc.rs

RalfJung force-pushed the global-allocator-opsem-magic branch from 4edf593 to 5161919 Compare July 23, 2026 09:54

nikic approved these changes Jul 24, 2026

View reviewed changes

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 Jul 24, 2026

jhpratt mentioned this pull request Jul 24, 2026

Rollup of 18 pull requests #159871

Closed

jhpratt mentioned this pull request Jul 24, 2026

Rollup of 17 pull requests #159872

Closed

jhpratt mentioned this pull request Jul 25, 2026

Rollup of 16 pull requests #159876

Closed

jhpratt mentioned this pull request Jul 25, 2026

Rollup of 19 pull requests #159879

Closed

jhpratt mentioned this pull request Jul 25, 2026

Rollup of 20 pull requests #159888

Closed

GuillaumeGomez mentioned this pull request Jul 25, 2026

Rollup of 23 pull requests #159903

Closed

GuillaumeGomez mentioned this pull request Jul 25, 2026

Rollup of 23 pull requests #159905

Open

		/// - The pointer passed to this function must have been obtained by invoking [`alloc`],
		/// [`alloc_zeroed`], or [`realloc`], not by invoking the underlying methods on [`GlobalAlloc`].

Uh oh!

Uh oh!

Conversation

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

Uh oh!

Uh oh!

rustbot commented Jul 22, 2026

Uh oh!

rustbot commented Jul 22, 2026

Uh oh!

Uh oh!

This comment has been minimized.

Uh oh!

RalfJung Jul 22, 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!

RalfJung commented Jul 23, 2026

Uh oh!

RalfJung commented Jul 23, 2026

Uh oh!

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

Uh oh!

Uh oh!

RalfJung commented Jul 23, 2026

Uh oh!

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

Uh oh!

Uh oh!

Uh oh!

RalfJung Jul 23, 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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment was marked as resolved.

RalfJung Jul 23, 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!

RalfJung commented Jul 23, 2026

Uh oh!

maxdexh Jul 23, 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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

maxdexh Jul 23, 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!

Choose a reason for hiding this comment

Uh oh!

maxdexh Jul 23, 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!

Choose a reason for hiding this comment

Uh oh!

maxdexh Jul 23, 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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

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

RalfJung commented Jul 22, 2026 •

edited by rustbot

Loading

RalfJung Jul 22, 2026 •

edited by rustbot

Loading

maxdexh commented Jul 23, 2026 •

edited

Loading

maxdexh commented Jul 23, 2026 •

edited

Loading

RalfJung Jul 23, 2026 •

edited by rustbot

Loading

RalfJung Jul 23, 2026 •

edited by rustbot

Loading

maxdexh Jul 23, 2026 •

edited by rustbot

Loading

maxdexh Jul 23, 2026 •

edited

Loading

maxdexh Jul 23, 2026 •

edited

Loading

maxdexh Jul 23, 2026 •

edited

Loading

maxdexh Jul 23, 2026 •

edited

Loading

maxdexh Jul 23, 2026 •

edited

Loading

rust-bors Bot commented Jul 25, 2026 •

edited

Loading