[Debug Info] Gracefully handle invalid `String`/`Vec` by Walnut356 · Pull Request #155509 · rust-lang/rust

Walnut356 · 2026-04-19T07:02:25Z

Somewhat related to #150392.

Currently the handling can throw an exception, which we should absolutely not do. It causes issues with debugger adapters (e.g. CodeLLDB will hang forever. Trying to stop the debugger via vscode's interface causes a CodeLLDB to leak memory constantly until RAM is depleted and the OS starts killing processes). The exception has been replaced with a printed error message and a placeholder value.

Additionally, if a String/Vec is in an "invalid" state due to niche optimization (capacity >= (1 << 63), common with Option<String>/Option<Vec<T>>), the pointer and length values will be meaningless, but are not guaranteed to be 0'd. The debugger will happily proceed as if they are useful values, and often do things like <try to read multiple GB of data from the debugee>.

I added simple checks to ensure that the capacity and length are within bounds, and that the pointer is non-null. If any check fails, the string/vec just acts as if it's empty.

Eventually this problem will be solved on LLDB's end via llvm/llvm-project#188487 or similar, but preventing issues on our end in the short term will help a lot.

try-job: aarch64-apple

rustbot · 2026-04-19T07:02:31Z

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
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: @Mark-Simulacrum

Mark-Simulacrum

r=me with if wording fixed, happy to skip/defer the helper, up to you.

View changes since this review

Mark-Simulacrum · 2026-04-26T18:43:34Z


    if length <= 0:
        return '""'
+
+    no_hi_bit_max: int = 1 << ((pointer.GetByteSize() * 8) - 1)
+    # technically length isn't a NoHighBit<usize>, but if length should always be <= capacity


Suggested change

# technically length isn't a NoHighBit<usize>, but if length should always be <= capacity

# technically length isn't a NoHighBit<usize>, but length should always be <= capacity

Not sure what if was meaning to refer to here?

Mark-Simulacrum · 2026-04-26T18:44:58Z

-    else:
-        raise Exception("ReadMemory error: %s", error.GetCString())
+    try:
+        data = process.ReadMemory(pointer.GetValueAsUnsigned(), length, error)


Should we aim for all process.ReadMemory calls to be wrapped like this? Maybe we should define our own helper to push for that? E.g., StdPathSummaryProvider probably needs the same treatment?

Ah, yeah that's a good question. It's probably best to, since swig FFI exceptions cause such catastrophic issues.

StdPathSummaryProvider probably needs the same treatment

Atm Path and OsStr providers defer directly to the vec synthetic's get_num_children and get_child_at_index. Since the vec synthetic can now detect invalid state, it'll just report an empty string.

It wouldn't be a bad idea to switch to using process.ReadMemory eventually since it's significantly more performant, but it's not too urgent since paths are usually quite short.

rust/src/etc/lldb_providers.py

Line 368 in 2f43fe4

data = process.ReadMemory(start, length, error)

- doesn't that need to get wrapped with try catch?

🤦‍♂️ i might be blind lol

rustbot · 2026-04-26T18:45:57Z

Reminder, once the PR becomes ready for a review, use @rustbot ready.

rustbot · 2026-04-27T06:16:54Z

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

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

Walnut356 · 2026-04-27T08:29:40Z

@rustbot ready

Mark-Simulacrum · 2026-05-09T17:38:43Z

@bors r+

rust-bors · 2026-05-09T17:38:46Z

📌 Commit 0a4f89e has been approved by Mark-Simulacrum

It is now in the queue for this repository.

…ulacrum [Debug Info] Gracefully handle invalid `String`/`Vec` Somewhat related to rust-lang#150392. Currently the handling can throw an exception, which we should absolutely not do. It causes issues with debugger adapters (e.g. CodeLLDB will hang forever. Trying to stop the debugger via vscode's interface causes a CodeLLDB to leak memory constantly until RAM is depleted and the OS starts killing processes). The exception has been replaced with a printed error message and a placeholder value. Additionally, if a String/Vec is in an "invalid" state due to niche optimization (`capacity >= (1 << 63)`, common with `Option<String>`/`Option<Vec<T>>`), the pointer and length values will be meaningless, but are not guaranteed to be 0'd. The debugger will happily proceed as if they are useful values, and often do things like \<try to read multiple GB of data from the debugee\>. I added simple checks to ensure that the capacity and length are within bounds, and that the pointer is non-null. If any check fails, the string/vec just acts as if it's empty. Eventually this problem will be solved on LLDB's end via llvm/llvm-project#188487 or similar, but preventing issues on our end in the short term will help a lot.

JonathanBrouwer · 2026-05-09T20:09:59Z

@bors r-
#156371 (comment)

Not sure if this is spurious
@bors try jobs=aarch64-apple

rust-bors · 2026-05-09T20:10:06Z

This pull request was unapproved.

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

View changes since this unapproval

[Debug Info] Gracefully handle invalid `String`/`Vec` try-job: aarch64-apple

rust-bors · 2026-05-09T21:16:59Z

💔 Test for 89a60ef failed: CI. Failed job:

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

Mark-Simulacrum · 2026-05-22T09:04:36Z

@bors r+

rust-bors · 2026-05-22T09:04:40Z

📌 Commit 23bd862 has been approved by Mark-Simulacrum

It is now in the queue for this repository.

…ulacrum [Debug Info] Gracefully handle invalid `String`/`Vec` Somewhat related to rust-lang#150392. Currently the handling can throw an exception, which we should absolutely not do. It causes issues with debugger adapters (e.g. CodeLLDB will hang forever. Trying to stop the debugger via vscode's interface causes a CodeLLDB to leak memory constantly until RAM is depleted and the OS starts killing processes). The exception has been replaced with a printed error message and a placeholder value. Additionally, if a String/Vec is in an "invalid" state due to niche optimization (`capacity >= (1 << 63)`, common with `Option<String>`/`Option<Vec<T>>`), the pointer and length values will be meaningless, but are not guaranteed to be 0'd. The debugger will happily proceed as if they are useful values, and often do things like \<try to read multiple GB of data from the debugee\>. I added simple checks to ensure that the capacity and length are within bounds, and that the pointer is non-null. If any check fails, the string/vec just acts as if it's empty. Eventually this problem will be solved on LLDB's end via llvm/llvm-project#188487 or similar, but preventing issues on our end in the short term will help a lot. --- try-job: aarch64-apple

Rollup of 4 pull requests Successful merges: - #155509 ([Debug Info] Gracefully handle invalid `String`/`Vec`) - #156560 (compiler: fix duplicated "the" in two doc-comments) - #156725 (Remove stale RTN FIXME for assoc item constraint fallback) - #156818 (Privacy: enqueue type alias)

[Debug Info] Gracefully handle invalid `String`/`Vec` Somewhat related to #150392. Currently the handling can throw an exception, which we should absolutely not do. It causes issues with debugger adapters (e.g. CodeLLDB will hang forever. Trying to stop the debugger via vscode's interface causes a CodeLLDB to leak memory constantly until RAM is depleted and the OS starts killing processes). The exception has been replaced with a printed error message and a placeholder value. Additionally, if a String/Vec is in an "invalid" state due to niche optimization (`capacity >= (1 << 63)`, common with `Option<String>`/`Option<Vec<T>>`), the pointer and length values will be meaningless, but are not guaranteed to be 0'd. The debugger will happily proceed as if they are useful values, and often do things like \<try to read multiple GB of data from the debugee\>. I added simple checks to ensure that the capacity and length are within bounds, and that the pointer is non-null. If any check fails, the string/vec just acts as if it's empty. Eventually this problem will be solved on LLDB's end via llvm/llvm-project#188487 or similar, but preventing issues on our end in the short term will help a lot. --- try-job: aarch64-apple

…ulacrum [Debug Info] Gracefully handle invalid `String`/`Vec` Somewhat related to rust-lang#150392. Currently the handling can throw an exception, which we should absolutely not do. It causes issues with debugger adapters (e.g. CodeLLDB will hang forever. Trying to stop the debugger via vscode's interface causes a CodeLLDB to leak memory constantly until RAM is depleted and the OS starts killing processes). The exception has been replaced with a printed error message and a placeholder value. Additionally, if a String/Vec is in an "invalid" state due to niche optimization (`capacity >= (1 << 63)`, common with `Option<String>`/`Option<Vec<T>>`), the pointer and length values will be meaningless, but are not guaranteed to be 0'd. The debugger will happily proceed as if they are useful values, and often do things like \<try to read multiple GB of data from the debugee\>. I added simple checks to ensure that the capacity and length are within bounds, and that the pointer is non-null. If any check fails, the string/vec just acts as if it's empty. Eventually this problem will be solved on LLDB's end via llvm/llvm-project#188487 or similar, but preventing issues on our end in the short term will help a lot. --- try-job: aarch64-apple

JonathanBrouwer · 2026-05-22T13:32:06Z

@bors yield
Yielding to enclosing rollup

rust-bors · 2026-05-22T13:32:10Z

Auto build was cancelled. Cancelled workflows:

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

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

…uwer Rollup of 6 pull requests Successful merges: - #155509 ([Debug Info] Gracefully handle invalid `String`/`Vec`) - #156560 (compiler: fix duplicated "the" in two doc-comments) - #156725 (Remove stale RTN FIXME for assoc item constraint fallback) - #156803 (Fix reborrow ICE in MIR place lowering) - #156818 (Privacy: enqueue type alias) - #156820 (delegation: visit body under elided-infer lifetime rib)

[Debug Info] Gracefully handle invalid `String`/`Vec` Somewhat related to #150392. Currently the handling can throw an exception, which we should absolutely not do. It causes issues with debugger adapters (e.g. CodeLLDB will hang forever. Trying to stop the debugger via vscode's interface causes a CodeLLDB to leak memory constantly until RAM is depleted and the OS starts killing processes). The exception has been replaced with a printed error message and a placeholder value. Additionally, if a String/Vec is in an "invalid" state due to niche optimization (`capacity >= (1 << 63)`, common with `Option<String>`/`Option<Vec<T>>`), the pointer and length values will be meaningless, but are not guaranteed to be 0'd. The debugger will happily proceed as if they are useful values, and often do things like \<try to read multiple GB of data from the debugee\>. I added simple checks to ensure that the capacity and length are within bounds, and that the pointer is non-null. If any check fails, the string/vec just acts as if it's empty. Eventually this problem will be solved on LLDB's end via llvm/llvm-project#188487 or similar, but preventing issues on our end in the short term will help a lot. --- try-job: aarch64-apple

rust-bors · 2026-05-22T14:21:54Z

💔 Test for 1269094 failed: CI. Failed job:

auto - aarch64-gnu-llvm-21-2 (web logs, enhanced plaintext logs)

…uwer Rollup of 10 pull requests Successful merges: - #155509 ([Debug Info] Gracefully handle invalid `String`/`Vec`) - #156229 (Install additional LLVM DLL on Windows) - #152821 (Allow forbidden target features to be hard errors) - #156560 (compiler: fix duplicated "the" in two doc-comments) - #156725 (Remove stale RTN FIXME for assoc item constraint fallback) - #156803 (Fix reborrow ICE in MIR place lowering) - #156815 (rustfmt: format const trait impls to `const impl` for syntax transition) - #156818 (Privacy: enqueue type alias) - #156820 (delegation: visit body under elided-infer lifetime rib) - #156829 (Turn `lint_index` from `Option<u16>` to `u16` for LintExpectationId)

jieyouxu · 2026-05-22T14:27:17Z

@bors retry

rust-log-analyzer · 2026-05-22T14:34:36Z

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

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

fmt check
fmt: checked 6862 files
tidy check

thread 'deps (.)' (3888) panicked at src/tools/tidy/src/deps.rs:649:24:
cmd.exec() failed with `cargo metadata` exited with an error:     Updating crates.io index
error: failed to get `powerfmt` as a dependency of package `time v0.3.47`
    ... which satisfies dependency `time = "^0.3.47"` (locked to 0.3.47) of package `cargo-test-support v0.11.3 (/checkout/src/tools/cargo/crates/cargo-test-support)`

Caused by:
  failed to load source for dependency `powerfmt`

Caused by:
  unable to update registry `crates-io`

Caused by:
  download of po/we/powerfmt failed

Caused by:
  curl failed

Caused by:
---
   5: std::thread::scoped::scope::<rust_tidy::main::{closure#1}, ()>
   6: rust_tidy::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
Bootstrap failed while executing `--stage 2 test --skip src/tools/rust-analyzer --skip tests --skip coverage-map --skip coverage-run --skip library --skip tidyselftest`
Command `/checkout/obj/build/aarch64-unknown-linux-gnu/stage1-tools-bin/rust-tidy --root-path=/checkout --cargo-path=/checkout/obj/build/aarch64-unknown-linux-gnu/stage0/bin/cargo --output-dir=/checkout/obj/build --concurrency=4 --npm-path=yarn --ci=true` failed with exit code 101
Created at: src/bootstrap/src/core/build_steps/tool.rs:1618:23
Executed at: src/bootstrap/src/core/build_steps/test.rs:1417:29

--- BACKTRACE vvv
   0: std::backtrace_rs::backtrace::libunwind::trace
             at /rustc/ef0fb8a2563200e322fa4419f09f65a63742038c/library/std/src/../../backtrace/src/backtrace/libunwind.rs:117:9
   1: std::backtrace_rs::backtrace::trace_unsynchronized::<<std::backtrace::Backtrace>::create::{closure#0}>
             at /rustc/ef0fb8a2563200e322fa4419f09f65a63742038c/library/std/src/../../backtrace/src/backtrace/mod.rs:66:14
   2: <std::backtrace::Backtrace>::create
             at /rustc/ef0fb8a2563200e322fa4419f09f65a63742038c/library/std/src/backtrace.rs:331:13
   3: <bootstrap::utils::exec::DeferredCommand>::finish_process
             at /checkout/src/bootstrap/src/utils/exec.rs:939:17
   4: <bootstrap::utils::exec::DeferredCommand>::wait_for_output::<&bootstrap::utils::exec::ExecutionContext>
             at /checkout/src/bootstrap/src/utils/exec.rs:831:21
   5: <bootstrap::utils::exec::ExecutionContext>::run
             at /checkout/src/bootstrap/src/utils/exec.rs:741:45
   6: <bootstrap::utils::exec::BootstrapCommand>::run::<&bootstrap::core::builder::Builder>
             at /checkout/src/bootstrap/src/utils/exec.rs:339:27
   7: <bootstrap::core::build_steps::test::Tidy as bootstrap::core::builder::Step>::run
             at /checkout/src/bootstrap/src/core/build_steps/test.rs:1417:29
   8: <bootstrap::core::builder::Builder>::ensure::<bootstrap::core::build_steps::test::Tidy>
             at /checkout/src/bootstrap/src/core/builder/mod.rs:1595:36
   9: <bootstrap::core::build_steps::test::Tidy as bootstrap::core::builder::Step>::make_run
             at /checkout/src/bootstrap/src/core/build_steps/test.rs:1339:21
  10: <bootstrap::core::builder::StepDescription>::maybe_run
             at /checkout/src/bootstrap/src/core/builder/mod.rs:476:13
  11: bootstrap::core::builder::cli_paths::match_paths_to_steps_and_run
             at /checkout/src/bootstrap/src/core/builder/cli_paths.rs:141:22
  12: <bootstrap::core::builder::Builder>::run_step_descriptions
             at /checkout/src/bootstrap/src/core/builder/mod.rs:1138:9
  13: <bootstrap::core::builder::Builder>::execute_cli
             at /checkout/src/bootstrap/src/core/builder/mod.rs:1117:14
  14: <bootstrap::Build>::build
             at /checkout/src/bootstrap/src/lib.rs:803:25
  15: bootstrap::main
             at /checkout/src/bootstrap/src/bin/main.rs:130:11
  16: <fn() as core::ops::function::FnOnce<()>>::call_once
             at /rustc/ef0fb8a2563200e322fa4419f09f65a63742038c/library/core/src/ops/function.rs:250:5
  17: std::sys::backtrace::__rust_begin_short_backtrace::<fn(), ()>
             at /rustc/ef0fb8a2563200e322fa4419f09f65a63742038c/library/std/src/sys/backtrace.rs:166:18
  18: std::rt::lang_start::<()>::{closure#0}
             at /rustc/ef0fb8a2563200e322fa4419f09f65a63742038c/library/std/src/rt.rs:206:18
  19: <&dyn core::ops::function::Fn<(), Output = i32> + core::panic::unwind_safe::RefUnwindSafe + core::marker::Sync as core::ops::function::FnOnce<()>>::call_once
             at /rustc/ef0fb8a2563200e322fa4419f09f65a63742038c/library/core/src/ops/function.rs:287:21
  20: std::panicking::catch_unwind::do_call::<&dyn core::ops::function::Fn<(), Output = i32> + core::panic::unwind_safe::RefUnwindSafe + core::marker::Sync, i32>
             at /rustc/ef0fb8a2563200e322fa4419f09f65a63742038c/library/std/src/panicking.rs:581:40
  21: std::panicking::catch_unwind::<i32, &dyn core::ops::function::Fn<(), Output = i32> + core::panic::unwind_safe::RefUnwindSafe + core::marker::Sync>
             at /rustc/ef0fb8a2563200e322fa4419f09f65a63742038c/library/std/src/panicking.rs:544:19
  22: std::panic::catch_unwind::<&dyn core::ops::function::Fn<(), Output = i32> + core::panic::unwind_safe::RefUnwindSafe + core::marker::Sync, i32>
             at /rustc/ef0fb8a2563200e322fa4419f09f65a63742038c/library/std/src/panic.rs:359:14
  23: std::rt::lang_start_internal::{closure#0}
             at /rustc/ef0fb8a2563200e322fa4419f09f65a63742038c/library/std/src/rt.rs:175:24
  24: std::panicking::catch_unwind::do_call::<std::rt::lang_start_internal::{closure#0}, isize>
             at /rustc/ef0fb8a2563200e322fa4419f09f65a63742038c/library/std/src/panicking.rs:581:40
---
  31: __libc_start_main
  32: _start


Command has failed. Rerun with -v to see more details.
Build completed unsuccessfully in 0:00:35
  local time: Fri May 22 14:20:50 UTC 2026
  network time: Fri, 22 May 2026 14:20:50 GMT
##[error]Process completed with exit code 1.
##[group]Run echo "disk usage:"

…uwer Rollup of 10 pull requests Successful merges: - #155509 ([Debug Info] Gracefully handle invalid `String`/`Vec`) - #156229 (Install additional LLVM DLL on Windows) - #152821 (Allow forbidden target features to be hard errors) - #156560 (compiler: fix duplicated "the" in two doc-comments) - #156725 (Remove stale RTN FIXME for assoc item constraint fallback) - #156803 (Fix reborrow ICE in MIR place lowering) - #156815 (rustfmt: format const trait impls to `const impl` for syntax transition) - #156818 (Privacy: enqueue type alias) - #156820 (delegation: visit body under elided-infer lifetime rib) - #156829 (Turn `lint_index` from `Option<u16>` to `u16` for LintExpectationId)

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

rustbot assigned Mark-Simulacrum Apr 19, 2026

Mark-Simulacrum requested changes Apr 26, 2026

View reviewed changes

rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Apr 26, 2026

rustbot added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Apr 26, 2026

gracefully handle invalid string/vec

e264a92

Walnut356 force-pushed the string_crash branch from 4529cdf to 3b9cf3e Compare April 27, 2026 06:16

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 Apr 27, 2026

Walnut356 force-pushed the string_crash branch from 3b9cf3e to 0a4f89e Compare April 28, 2026 05:13

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 May 9, 2026

JonathanBrouwer mentioned this pull request May 9, 2026

Rollup of 11 pull requests #156371

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 May 9, 2026

This comment has been minimized.

Sign in to view

rust-bors Bot pushed a commit that referenced this pull request May 9, 2026

Auto merge of #155509 - Walnut356:string_crash, r=<try>

89a60ef

[Debug Info] Gracefully handle invalid `String`/`Vec` try-job: aarch64-apple

This comment has been minimized.

Sign in to view

move string read logic to standalone function

23bd862

Walnut356 force-pushed the string_crash branch from 0a4f89e to 23bd862 Compare May 10, 2026 05:49

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 May 22, 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 May 22, 2026

jhpratt mentioned this pull request May 22, 2026

Rollup of 4 pull requests #156821

Closed

This comment has been minimized.

Sign in to view

JonathanBrouwer mentioned this pull request May 22, 2026

Rollup of 6 pull requests #156831

Closed

This comment has been minimized.

Sign in to view

JonathanBrouwer mentioned this pull request May 22, 2026

Rollup of 10 pull requests #156834

Merged

rust-bors Bot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels May 22, 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 May 22, 2026

rust-bors Bot merged commit 42bd6de into rust-lang:main May 22, 2026
12 of 13 checks passed

rustbot added this to the 1.98.0 milestone May 22, 2026

	# technically length isn't a NoHighBit<usize>, but if length should always be <= capacity
	# technically length isn't a NoHighBit<usize>, but length should always be <= capacity

Uh oh!

Conversation

Walnut356 commented Apr 19, 2026 • edited by jieyouxu Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Apr 19, 2026

Uh oh!

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

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Mark-Simulacrum Apr 26, 2026

Choose a reason for hiding this comment

Uh oh!

Mark-Simulacrum Apr 26, 2026

Choose a reason for hiding this comment

Uh oh!

Walnut356 Apr 27, 2026

Choose a reason for hiding this comment

Uh oh!

Mark-Simulacrum Apr 27, 2026

Choose a reason for hiding this comment

Uh oh!

Walnut356 Apr 28, 2026

Choose a reason for hiding this comment

Uh oh!

rustbot commented Apr 26, 2026

Uh oh!

rustbot commented Apr 27, 2026

Uh oh!

Walnut356 commented Apr 27, 2026

Uh oh!

Mark-Simulacrum commented May 9, 2026

Uh oh!

rust-bors Bot commented May 9, 2026

Uh oh!

JonathanBrouwer commented May 9, 2026

Uh oh!

rust-bors Bot commented May 9, 2026

Uh oh!

This comment has been minimized.

rust-bors Bot commented May 9, 2026

Uh oh!

This comment has been minimized.

Mark-Simulacrum commented May 22, 2026

Uh oh!

rust-bors Bot commented May 22, 2026

Uh oh!

This comment has been minimized.

JonathanBrouwer commented May 22, 2026

Uh oh!

rust-bors Bot commented May 22, 2026

Uh oh!

This comment has been minimized.

rust-bors Bot commented May 22, 2026

Uh oh!

jieyouxu commented May 22, 2026

Uh oh!

rust-log-analyzer commented May 22, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

Walnut356 commented Apr 19, 2026 •

edited by jieyouxu

Loading

Mark-Simulacrum left a comment •

edited by rustbot

Loading