Add `debug_assert_nounwind` and convert `assert_unsafe_precondition` #110303

nbdd0121 · 2023-04-14T00:25:06Z

assert_unsafe_precondition checks non-CTFE-evaluable conditions in runtime and performs no-op in compile time, while many of its current usage can be checked during const eval.

rustbot · 2023-04-14T00:25:12Z

r? @scottmcm

(rustbot has picked a reviewer for you, use r? to override)

rustbot · 2023-04-14T00:25:15Z

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

Stabilizing library features
Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
Changing public documentation in ways that create new stability guarantees
Changing observable runtime behavior of library APIs

saethlin · 2023-04-14T00:40:40Z

library/core/src/panic.rs

+#[unstable(feature = "core_panic", issue = "none")]
+#[allow_internal_unstable(core_panic, const_format_args)]
+#[rustc_macro_transparency = "semitransparent"]
+pub macro debug_assert_nounwind {


This macro should have documentation that explains that it should be used in unsafe contexts because it cannot compromise unwind safety. (and that debug_assert! shouldn't be because it can)

Well, actually no unwind safety is compromised and debug_assert! can be used in these contexts, because if unwinding would only happen when there's an UB, and unwinding happening at undesirable place is an allowed behaviour for UB.

That said, causing UB by unwinding certainly defeats the purpose of having these assertions for debugging.

scottmcm · 2023-04-14T00:53:58Z

Hmm, maybe it's worth using CES to not do this for some of the cases in const eval, because the old message here is better:

 ---- [ui] tests/ui/consts/const_unsafe_unreachable_ub.rs stdout ----
diff of stderr:

1	error[E0080]: evaluation of constant value failed
-	  --> $SRC_DIR/core/src/hint.rs:LL:COL
+	  --> $SRC_DIR/core/src/panicking.rs:LL:COL
3	   |
-	   = note: entering unreachable code
+	   = note: the evaluated program panicked at 'hint::unreachable_unchecked must never be reached', $SRC_DIR/core/src/panicking.rs:LL:COL
5	   |

saethlin · 2023-04-14T01:07:08Z

Ah yes this old question.

The "problem" is that we now detect more UB in const eval. The UB was previously only detected by sheer luck, because we produced an invalid value in a const, which is the only place we have explicit const UB checks by default. Otherwise, you need to pass -Zextra-const-ub-checks. (of course you have pasted I think the one example where this isn't the case)

I think the new error message is just as helpful, and perhaps it is extra reason to improve the panic messages with some formatting of the output.

scottmcm · 2023-04-14T06:14:54Z

The UB was previously only detected by sheer luck

When it comes to hint::unreachable_unchecked(), it's not "sheer luck". Const eval is absolutely going to detect that every time, or something has gone very wrong.

There are plenty of other places where I think checking with debug_assert seems entirely reasonable, though, because whether CTFE happens to notice it otherwise is far more happenstance.

lukas-code

Is it possible to replace the is_aligned_and_not_null assertions as well or would that regress the error messages too much?

lukas-code · 2023-04-14T08:56:01Z

library/core/src/panicking.rs

@@ -122,7 +135,8 @@ pub const fn panic(expr: &'static str) -> ! {
 #[cfg_attr(feature = "panic_immediate_abort", inline)]
 #[lang = "panic_nounwind"] // needed by codegen for non-unwinding panics
 #[rustc_nounwind]
-pub fn panic_nounwind(expr: &'static str) -> ! {
+#[rustc_const_unstable(feature = "core_panic", issue = "none")]
+pub const fn panic_nounwind(expr: &'static str) -> ! {


What is the impact of adding #[track_caller] here? That would improve the const panic.

That will require codegen backend changes to add the implicit caller location argument when it is manually called (as opposed through a Call MIR terminator).

I think that's fine? Debug assertions are expected to have overhead, sometimes a lot of overhead. If people are concerned about debug assertions, they should turn them off. Or we should factor these assertions out to a separate flag. Either option is preferable to sacrificing UX for those who can afford the overhead, which as far as I can tell is most people?

panic_nounwind is not just for debug assertions. panic_nounwind is used in situations where it is important to keep the code size small, and having track_caller would be contrary to that goal.

The comment above the function (helpfully hidden by github) explains this:

/// Like `panic`, but without unwinding and track_caller to reduce the impact on codesize.

Callers that do not care about code size can just call panic_nounwind_fmt(format_args!("my message")) instead, then they will get track_caller.

nbdd0121 · 2023-04-14T11:39:23Z

Is it possible to replace the is_aligned_and_not_null assertions as well or would that regress the error messages too much?

CTFE has no notation of address, so this can't be checked during const eval.

nbdd0121 · 2023-04-14T12:00:46Z

Is there a way to gate tests depending on whether debug assertion is enabled for std or not? Apparently adding compile-flags: -Cdebug-assertions=no is insufficient because that doesn't affect std.

saethlin · 2023-04-14T12:46:17Z

// ignore-debug

lukas-code · 2023-04-14T15:06:41Z

CTFE has no notation of address, so this can't be checked during const eval.

CTFE doen't have (absolute) addresses, but it still has alignment / relative addresses. So this works, but the errors do indeed look worse.

code + errors

#![feature(const_pointer_byte_offsets)]
#![feature(const_ptr_read)]
#![feature(pointer_byte_offsets)]

const _: i32 = {
    let a = [1, 2];
    unsafe { a.as_ptr().byte_add(1).read() }
};

const _: i32 = {
    unsafe { core::ptr::null::<i32>().read() }
};

CTFE errors:

error[E0080]: evaluation of constant value failed
    --> /home/lukas/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ptr/mod.rs:1188:13
     |
1188 |             crate::intrinsics::read_via_copy(src)
     |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ accessing memory with alignment 1, but alignment 4 is required
     |
note: inside `std::ptr::read::<i32>`
    --> /home/lukas/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ptr/mod.rs:1188:13
     |
1188 |             crate::intrinsics::read_via_copy(src)
     |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: inside `ptr::const_ptr::<impl *const i32>::read`
    --> /home/lukas/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ptr/const_ptr.rs:1198:18
     |
1198 |         unsafe { read(self) }
     |                  ^^^^^^^^^^
note: inside `_`
    --> src/lib.rs:7:14
     |
7    |     unsafe { a.as_ptr().byte_add(1).read() }
     |              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error[E0080]: evaluation of constant value failed
    --> /home/lukas/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ptr/mod.rs:1188:13
     |
1188 |             crate::intrinsics::read_via_copy(src)
     |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ dereferencing pointer failed: null pointer is a dangling pointer (it has no provenance)
     |
note: inside `std::ptr::read::<i32>`
    --> /home/lukas/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ptr/mod.rs:1188:13
     |
1188 |             crate::intrinsics::read_via_copy(src)
     |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: inside `ptr::const_ptr::<impl *const i32>::read`
    --> /home/lukas/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ptr/const_ptr.rs:1198:18
     |
1198 |         unsafe { read(self) }
     |                  ^^^^^^^^^^
note: inside `_`
    --> src/lib.rs:11:14
     |
11   |     unsafe { core::ptr::null::<i32>().read() }
     |              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

For more information about this error, try `rustc --explain E0080`.

assertion errors:

error[E0080]: evaluation of constant value failed
    --> /home/lukas/code/rust/library/core/src/ptr/mod.rs:1165:5
     |
1165 | /     debug_assert_nounwind!(
1166 | |         is_aligned_and_not_null(src),
1167 | |         "ptr::read requires that the pointer argument is aligned and non-null",
1168 | |     );
     | |_____^ the evaluated program panicked at 'ptr::read requires that the pointer argument is aligned and non-null', /home/lukas/code/rust/library/core/src/ptr/mod.rs:1165:5
     |
note: inside `std::ptr::read::<i32>`
    --> /home/lukas/code/rust/library/core/src/ptr/mod.rs:1165:5
     |
1165 | /     debug_assert_nounwind!(
1166 | |         is_aligned_and_not_null(src),
1167 | |         "ptr::read requires that the pointer argument is aligned and non-null",
1168 | |     );
     | |_____^
note: inside `ptr::const_ptr::<impl *const i32>::read`
    --> /home/lukas/code/rust/library/core/src/ptr/const_ptr.rs:1198:18
     |
1198 |         unsafe { read(self) }
     |                  ^^^^^^^^^^
note: inside `_`
    --> src/lib.rs:7:14
     |
7    |     unsafe { a.as_ptr().byte_add(1).read() }
     |              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     = note: this error originates in the macro `debug_assert_nounwind` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0080]: evaluation of constant value failed
    --> /home/lukas/code/rust/library/core/src/ptr/mod.rs:1165:5
     |
1165 | /     debug_assert_nounwind!(
1166 | |         is_aligned_and_not_null(src),
1167 | |         "ptr::read requires that the pointer argument is aligned and non-null",
1168 | |     );
     | |_____^ the evaluated program panicked at 'ptr::read requires that the pointer argument is aligned and non-null', /home/lukas/code/rust/library/core/src/ptr/mod.rs:1165:5
     |
note: inside `std::ptr::read::<i32>`
    --> /home/lukas/code/rust/library/core/src/ptr/mod.rs:1165:5
     |
1165 | /     debug_assert_nounwind!(
1166 | |         is_aligned_and_not_null(src),
1167 | |         "ptr::read requires that the pointer argument is aligned and non-null",
1168 | |     );
     | |_____^
note: inside `ptr::const_ptr::<impl *const i32>::read`
    --> /home/lukas/code/rust/library/core/src/ptr/const_ptr.rs:1198:18
     |
1198 |         unsafe { read(self) }
     |                  ^^^^^^^^^^
note: inside `_`
    --> src/lib.rs:11:14
     |
11   |     unsafe { core::ptr::null::<i32>().read() }
     |              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     = note: this error originates in the macro `debug_assert_nounwind` (in Nightly builds, run with -Z macro-backtrace for more info)

For more information about this error, try `rustc --explain E0080`.

nbdd0121 · 2023-04-14T15:32:41Z

That's checking for guaranteed alignment, not the actual alignment. The behaviour of is_aligned is sufficiently different between runtime and const eval time (https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=e24e516ceda8ff0217ee034eb7cb4eac) that I don't think it's reasonable to reject unchecked code based on guaranteed alignment.

bors · 2023-04-19T16:24:42Z

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

nbdd0121 · 2023-04-24T13:38:51Z

@scottmcm I've reverted the change in unreachable_unchecked. PTAL

bors · 2023-05-20T02:41:30Z

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

nbdd0121 · 2023-06-21T16:21:22Z

@rustbot ready

scottmcm · 2023-08-05T05:22:37Z

Sorry, I think this should go to a team member for review since it's a convention change
r? rust-lang/libs

Mark-Simulacrum · 2023-08-13T17:11:31Z

@scottmcm (or @nbdd0121) can someone write up a short description of the convention change here? I'm trying to put it together based on PR description etc -- is "also check some conditions at CTFE time" accurate?

r=me on the impl though

nbdd0121 · 2023-11-26T01:10:29Z

@bors r=Mark-Simulacrum

bors · 2023-11-26T01:10:32Z

📌 Commit 2c03f21 has been approved by Mark-Simulacrum

It is now in the queue for this repository.

bors · 2023-11-26T06:44:07Z

⌛ Testing commit 2c03f21 with merge 9529a5d...

bors · 2023-11-26T08:43:19Z

☀️ Test successful - checks-actions
Approved by: Mark-Simulacrum
Pushing 9529a5d to master...

bors · 2023-11-26T08:43:19Z

☀️ Test successful - checks-actions
Approved by: Mark-Simulacrum
Pushing 9529a5d to master...

rust-timer · 2023-11-26T10:05:46Z

Finished benchmarking commit (9529a5d): comparison URL.

Overall result: ❌✅ regressions and improvements - ACTION NEEDED

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.5%	[0.4%, 0.6%]	4
Regressions ❌ (secondary)	0.2%	[0.2%, 0.3%]	2
Improvements ✅ (primary)	-0.4%	[-0.4%, -0.4%]	1
Improvements ✅ (secondary)	-0.6%	[-0.6%, -0.6%]	2
All ❌✅ (primary)	0.3%	[-0.4%, 0.6%]	5

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	2.9%	[1.8%, 4.9%]	5
Regressions ❌ (secondary)	2.7%	[2.2%, 3.3%]	3
Improvements ✅ (primary)	-3.2%	[-7.2%, -0.2%]	4
Improvements ✅ (secondary)	-2.6%	[-3.6%, -1.7%]	3
All ❌✅ (primary)	0.2%	[-7.2%, 4.9%]	9

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	1.0%	[0.9%, 1.0%]	2
Regressions ❌ (secondary)	0.5%	[0.5%, 0.5%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	1.0%	[0.9%, 1.0%]	2

Binary size

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.2%	[0.0%, 0.9%]	12
Regressions ❌ (secondary)	0.0%	[0.0%, 0.1%]	14
Improvements ✅ (primary)	-0.1%	[-0.5%, -0.0%]	38
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.1%	[-0.5%, 0.9%]	50

Bootstrap: 672.47s -> 675.527s (0.45%)
Artifact size: 313.36 MiB -> 313.36 MiB (0.00%)

nnethercote · 2023-11-26T22:42:58Z

A bit of churn in the perf results. Nothing to really worry about, though, I think. Hopefully the 3s increase in bootstrap time is just noise?

@rustbot label: +perf-regression-triaged

RalfJung · 2023-11-27T07:49:56Z

tests/ui/consts/const-eval/raw-bytes.rs

@@ -1,6 +1,7 @@
 // stderr-per-bitwidth
 // ignore-endian-big
 // ignore-tidy-linelength
+// ignore-debug debug assertions catch some UB too early


This is bad. It is fairly common that developers have debug assertions enabled locally so this now means they can't run or bless this test any more.

This will regularly affect me when I work on const-eval things. I would now have to bless this test by hand by copy-pasting CI results, which is clearly not a workable development mode. I think we cannot disable this test, we need to find another solution.

EDIT: Ah turns out I have debug-assertions-std = false. But still, making const-eval development hard with debug-assertions-std = true is not a great situation.

The diff seems to be caused by Alignment::new_unchecked. IMO we should either un-do the PR for that or use a different way of creating invalid layouts for this test (that avoids the assertion).

Follow-up: #118358

RalfJung · 2023-11-27T08:20:44Z

library/core/src/panicking.rs

+#[rustc_const_unstable(feature = "core_panic", issue = "none")]
+pub const fn panic_nounwind_fmt(fmt: fmt::Arguments<'_>, force_no_backtrace: bool) -> ! {
+    #[track_caller]
+    fn runtime(fmt: fmt::Arguments<'_>, force_no_backtrace: bool) -> ! {


This should probably have at least #[cfg_attr(feature = "panic_immediate_abort", inline)], like almost all the functions in this file.

Done in #118362

make const tests independent of std debug assertions Fixes some fallout from rust-lang#110303: `ignore-debug` is bad since it makes it very annoying to develop rustc with debug assertions enabled. These tests do not really provide any interesting test coverage, we already got plenty of other tests that check that we detect invalid enums. So we can just remove them.

Rollup merge of rust-lang#118358 - RalfJung:const-tests, r=WaffleLapkin make const tests independent of std debug assertions Fixes some fallout from rust-lang#110303: `ignore-debug` is bad since it makes it very annoying to develop rustc with debug assertions enabled. These tests do not really provide any interesting test coverage, we already got plenty of other tests that check that we detect invalid enums. So we can just remove them.

make sure panic_nounwind_fmt can still be fully inlined (e.g. for panic_immediate_abort) Follow-up to rust-lang#110303.

make sure panic_nounwind_fmt can still be fully inlined (e.g. for panic_immediate_abort) Follow-up to rust-lang/rust#110303.

rustbot assigned scottmcm Apr 14, 2023

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 Apr 14, 2023

saethlin reviewed Apr 14, 2023

View reviewed changes

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

lukas-code reviewed Apr 14, 2023

View reviewed changes

This comment has been minimized.

Sign in to view

nbdd0121 force-pushed the master branch from b0728ab to 5f1c7a5 Compare April 24, 2023 01:39

nbdd0121 force-pushed the master branch from 5f1c7a5 to fba8a55 Compare June 16, 2023 13:32

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 Jun 21, 2023

rustbot assigned Mark-Simulacrum and unassigned scottmcm Aug 5, 2023

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 Nov 26, 2023

bors added the merged-by-bors This PR was explicitly merged by bors. label Nov 26, 2023

bors merged commit 9529a5d into rust-lang:master Nov 26, 2023
12 checks passed

rustbot added this to the 1.76.0 milestone Nov 26, 2023

rustbot added the perf-regression Performance regression. label Nov 26, 2023

rustbot added the perf-regression-triaged The performance regression has been triaged. label Nov 26, 2023

RalfJung reviewed Nov 27, 2023

View reviewed changes

RalfJung mentioned this pull request Nov 27, 2023

make const tests independent of std debug assertions #118358

Merged

RalfJung reviewed Nov 27, 2023

View reviewed changes

RalfJung mentioned this pull request Nov 27, 2023

make sure panic_nounwind_fmt can still be fully inlined (e.g. for panic_immediate_abort) #118362

Merged

lukas-code mentioned this pull request Dec 1, 2023

Performance regression in the past 9 days #118501

Closed

bors added a commit to rust-lang-ci/rust that referenced this pull request Dec 5, 2023

Auto merge of rust-lang#118362 - RalfJung:panic_nounwind, r=thomcc

154f645

make sure panic_nounwind_fmt can still be fully inlined (e.g. for panic_immediate_abort) Follow-up to rust-lang#110303.

github-actions bot pushed a commit to rust-lang/miri that referenced this pull request Dec 8, 2023

Auto merge of #118362 - RalfJung:panic_nounwind, r=thomcc

81dcc3b

make sure panic_nounwind_fmt can still be fully inlined (e.g. for panic_immediate_abort) Follow-up to rust-lang/rust#110303.

saethlin mentioned this pull request Feb 9, 2024

Totally-not-a-tracking-issue for UB-detecting debug assertions in the standard library #120848

Open

9 tasks

lnicola pushed a commit to lnicola/rust-analyzer that referenced this pull request Apr 7, 2024

Auto merge of #118362 - RalfJung:panic_nounwind, r=thomcc

901022e

make sure panic_nounwind_fmt can still be fully inlined (e.g. for panic_immediate_abort) Follow-up to rust-lang/rust#110303.

RalfJung pushed a commit to RalfJung/rust-analyzer that referenced this pull request Apr 27, 2024

Auto merge of #118362 - RalfJung:panic_nounwind, r=thomcc

67dec1a

make sure panic_nounwind_fmt can still be fully inlined (e.g. for panic_immediate_abort) Follow-up to rust-lang/rust#110303.

Add debug_assert_nounwind and convert assert_unsafe_precondition #110303

Add debug_assert_nounwind and convert assert_unsafe_precondition #110303

Conversation

nbdd0121 commented Apr 14, 2023

rustbot commented Apr 14, 2023

rustbot commented Apr 14, 2023

saethlin Apr 14, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

scottmcm commented Apr 14, 2023

saethlin commented Apr 14, 2023 • edited Loading

scottmcm commented Apr 14, 2023

lukas-code left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

RalfJung Nov 27, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

This comment has been minimized.

nbdd0121 commented Apr 14, 2023

nbdd0121 commented Apr 14, 2023

saethlin commented Apr 14, 2023

lukas-code commented Apr 14, 2023

nbdd0121 commented Apr 14, 2023

bors commented Apr 19, 2023

nbdd0121 commented Apr 24, 2023

bors commented May 20, 2023

nbdd0121 commented Jun 21, 2023

scottmcm commented Aug 5, 2023

Mark-Simulacrum commented Aug 13, 2023 • edited Loading

nbdd0121 commented Nov 26, 2023

bors commented Nov 26, 2023

bors commented Nov 26, 2023

bors commented Nov 26, 2023

bors commented Nov 26, 2023

rust-timer commented Nov 26, 2023

Overall result: ❌✅ regressions and improvements - ACTION NEEDED

nnethercote commented Nov 26, 2023

RalfJung Nov 27, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Add `debug_assert_nounwind` and convert `assert_unsafe_precondition` #110303

Add `debug_assert_nounwind` and convert `assert_unsafe_precondition` #110303

saethlin Apr 14, 2023 •

edited

Loading

saethlin commented Apr 14, 2023 •

edited

Loading

RalfJung Nov 27, 2023 •

edited

Loading

Mark-Simulacrum commented Aug 13, 2023 •

edited

Loading

RalfJung Nov 27, 2023 •

edited

Loading