miri: support 'promising' alignment for symbolic alignment check #117840

RalfJung · 2023-11-12T15:12:06Z

Then use that ability in slice::align_to, so that even with -Zmiri-symbolic-alignment-check, it no longer has to return spuriously empty "middle" parts.

Fixes rust-lang/miri#3068

rustbot · 2023-11-12T15:12:14Z

r? @cjgillot

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

rustbot · 2023-11-12T15:12:17Z

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

The Miri subtree was changed

cc @rust-lang/miri

cjgillot · 2023-11-19T21:05:06Z

library/core/src/ptr/mut_ptr.rs

+            const fn compiletime(_ptr: *const (), _align: usize) {}
+
+            // SAFETY: the extra behavior at runtime is for UB checks only.
+            unsafe {
+                intrinsics::const_eval_select(
+                    (self.wrapping_add(ret).cast_const().cast(), align),
+                    compiletime,
+                    runtime,
+                );
+            }


Can we simplify this by adding an empty impl in the interpreter in the non-miri case?

An empty impl for what? miri_promise_symbolic_alignment? I'd rather not, that would be observable on stable.

The alternative to the approach I chose is to make this an intrinsic. But it felt too Miri-specific to justify a new intrinsic.

library/core/src/slice/mod.rs

RalfJung · 2023-11-20T08:04:10Z

@rustbot review

bors · 2023-11-21T18:07:27Z

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

RalfJung · 2023-12-02T18:06:53Z

@cjgillot I think I've taken care of your comments.

cjgillot · 2023-12-03T15:08:19Z

Thanks.
@bors r+

bors · 2023-12-03T15:08:22Z

📌 Commit c823ea9 has been approved by cjgillot

It is now in the queue for this repository.

bors · 2023-12-03T18:26:47Z

⌛ Testing commit c823ea9 with merge 29ff7bf...

miri: support 'promising' alignment for symbolic alignment check Then use that ability in `slice::align_to`, so that even with `-Zmiri-symbolic-alignment-check`, it no longer has to return spuriously empty "middle" parts. Fixes rust-lang/miri#3068

bors · 2023-12-03T18:56:41Z

💔 Test failed - checks-actions

RalfJung · 2023-12-03T20:51:36Z

@bors r=cjgillot

bors · 2023-12-03T20:51:39Z

📌 Commit 2a3fcc0 has been approved by cjgillot

It is now in the queue for this repository.

bors · 2023-12-03T22:53:47Z

⌛ Testing commit 2a3fcc0 with merge c9808f8...

bors · 2023-12-04T00:57:25Z

☀️ Test successful - checks-actions
Approved by: cjgillot
Pushing c9808f8 to master...

rust-timer · 2023-12-04T02:20:34Z

Finished benchmarking commit (c9808f8): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

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)	-	-	0
Regressions ❌ (secondary)	2.5%	[2.5%, 2.5%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 672.475s -> 672.824s (0.05%)
Artifact size: 314.11 MiB -> 314.12 MiB (0.00%)

…cuviper align_offset, align_to: no longer allow implementations to spuriously fail to align For a long time, we have allowed `align_offset` to fail to compute a properly aligned offset, and `align_to` to return a smaller-than-maximal "middle slice". This was done to cover the implementation of `align_offset` in const-eval and Miri. See rust-lang#62420 for more background. For about the same amount of time, this has caused confusion and surprise, where people didn't realize they have to write their code to be defensive against `align_offset` failures. Another way to put this is: the specification is effectively non-deterministic, and non-determinism is hard to test for -- in particular if the implementation everyone uses to test always produces the same reliable result, and nobody expects it to be non-deterministic to begin with. With rust-lang#117840, Miri has stopped making use of this liberty in the spec; it now always behaves like rustc. That only leaves const-eval as potential motivation for this behavior. I do not think this is sufficient motivation. Currently, none of the relevant functions are stably const: `align_offset` is unstably const, `align_to` is not const at all. I propose that if we ever want to make these const-stable, we just accept the fact that they can behave differently at compile-time vs at run-time. This is not the end of the world, and it seems to be much less surprising to programmers than unexpected non-determinism. (Related: rust-lang/rfcs#3352.) `@thomcc` has repeatedly made it clear that they strongly dislike the non-determinism in align_offset, so I expect they will support this. `@oli-obk,` what do you think? Also, whom else should we involve? The primary team responsible is clearly libs-api, so I will nominate this for them. However, allowing const-evaluated code to behave different from run-time code is t-lang territory. The thing is, this is not stabilizing anything t-lang-worthy immediately, but it still does make a decision we will be bound to: if we accept this change, then - either `align_offset`/`align_to` can never be called in const fn, - or we allow compile-time behavior to differ from run-time behavior. So I will nominate for t-lang as well, with the question being: are you okay with accepting either of these outcomes (without committing to which one, just accepting that it has to be one of them)? This closes the door to "have `align_offset` and `align_to` at compile-time and also always have compile-time behavior match run-time behavior". Closes rust-lang#62420

Rollup merge of rust-lang#121201 - RalfJung:align_offset_contract, r=cuviper align_offset, align_to: no longer allow implementations to spuriously fail to align For a long time, we have allowed `align_offset` to fail to compute a properly aligned offset, and `align_to` to return a smaller-than-maximal "middle slice". This was done to cover the implementation of `align_offset` in const-eval and Miri. See rust-lang#62420 for more background. For about the same amount of time, this has caused confusion and surprise, where people didn't realize they have to write their code to be defensive against `align_offset` failures. Another way to put this is: the specification is effectively non-deterministic, and non-determinism is hard to test for -- in particular if the implementation everyone uses to test always produces the same reliable result, and nobody expects it to be non-deterministic to begin with. With rust-lang#117840, Miri has stopped making use of this liberty in the spec; it now always behaves like rustc. That only leaves const-eval as potential motivation for this behavior. I do not think this is sufficient motivation. Currently, none of the relevant functions are stably const: `align_offset` is unstably const, `align_to` is not const at all. I propose that if we ever want to make these const-stable, we just accept the fact that they can behave differently at compile-time vs at run-time. This is not the end of the world, and it seems to be much less surprising to programmers than unexpected non-determinism. (Related: rust-lang/rfcs#3352.) `@thomcc` has repeatedly made it clear that they strongly dislike the non-determinism in align_offset, so I expect they will support this. `@oli-obk,` what do you think? Also, whom else should we involve? The primary team responsible is clearly libs-api, so I will nominate this for them. However, allowing const-evaluated code to behave different from run-time code is t-lang territory. The thing is, this is not stabilizing anything t-lang-worthy immediately, but it still does make a decision we will be bound to: if we accept this change, then - either `align_offset`/`align_to` can never be called in const fn, - or we allow compile-time behavior to differ from run-time behavior. So I will nominate for t-lang as well, with the question being: are you okay with accepting either of these outcomes (without committing to which one, just accepting that it has to be one of them)? This closes the door to "have `align_offset` and `align_to` at compile-time and also always have compile-time behavior match run-time behavior". Closes rust-lang#62420

align_offset, align_to: no longer allow implementations to spuriously fail to align For a long time, we have allowed `align_offset` to fail to compute a properly aligned offset, and `align_to` to return a smaller-than-maximal "middle slice". This was done to cover the implementation of `align_offset` in const-eval and Miri. See rust-lang/rust#62420 for more background. For about the same amount of time, this has caused confusion and surprise, where people didn't realize they have to write their code to be defensive against `align_offset` failures. Another way to put this is: the specification is effectively non-deterministic, and non-determinism is hard to test for -- in particular if the implementation everyone uses to test always produces the same reliable result, and nobody expects it to be non-deterministic to begin with. With rust-lang/rust#117840, Miri has stopped making use of this liberty in the spec; it now always behaves like rustc. That only leaves const-eval as potential motivation for this behavior. I do not think this is sufficient motivation. Currently, none of the relevant functions are stably const: `align_offset` is unstably const, `align_to` is not const at all. I propose that if we ever want to make these const-stable, we just accept the fact that they can behave differently at compile-time vs at run-time. This is not the end of the world, and it seems to be much less surprising to programmers than unexpected non-determinism. (Related: rust-lang/rfcs#3352.) `@thomcc` has repeatedly made it clear that they strongly dislike the non-determinism in align_offset, so I expect they will support this. `@oli-obk,` what do you think? Also, whom else should we involve? The primary team responsible is clearly libs-api, so I will nominate this for them. However, allowing const-evaluated code to behave different from run-time code is t-lang territory. The thing is, this is not stabilizing anything t-lang-worthy immediately, but it still does make a decision we will be bound to: if we accept this change, then - either `align_offset`/`align_to` can never be called in const fn, - or we allow compile-time behavior to differ from run-time behavior. So I will nominate for t-lang as well, with the question being: are you okay with accepting either of these outcomes (without committing to which one, just accepting that it has to be one of them)? This closes the door to "have `align_offset` and `align_to` at compile-time and also always have compile-time behavior match run-time behavior". Closes rust-lang/rust#62420

rustbot assigned cjgillot Nov 12, 2023

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

RalfJung force-pushed the miri-promise-align branch from 4668e3d to a4a083e Compare November 12, 2023 15:13

This comment has been minimized.

Sign in to view

RalfJung force-pushed the miri-promise-align branch from a4a083e to eb89b2e Compare November 12, 2023 16:19

cjgillot reviewed Nov 19, 2023

View reviewed changes

RalfJung force-pushed the miri-promise-align branch from d487230 to c823ea9 Compare November 22, 2023 06:19

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-review Status: Awaiting review from the assignee but also interested parties. labels Dec 3, 2023

This comment has been minimized.

Sign in to view

bors 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 Dec 3, 2023

RalfJung added 2 commits December 3, 2023 21:51

miri: support 'promising' alignment for symbolic alignment check

bebba4f

move calling miri_promise_symbolic_alignment to a shared helper

2a3fcc0

RalfJung force-pushed the miri-promise-align branch from c823ea9 to 2a3fcc0 Compare December 3, 2023 20:51

bors removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Dec 3, 2023

bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Dec 3, 2023

bors added the merged-by-bors This PR was explicitly merged by bors. label Dec 4, 2023

bors merged commit c9808f8 into rust-lang:master Dec 4, 2023
12 checks passed

rustbot added this to the 1.76.0 milestone Dec 4, 2023

This was referenced Dec 4, 2023

rename ptr::invalid -> ptr::without_provenance #117658

Merged

compile-time evaluation: detect writes through immutable pointers #118324

Merged

RalfJung deleted the miri-promise-align branch December 4, 2023 06:37

joshlf mentioned this pull request Dec 5, 2023

Re-enable Miri symbolic alignment checking google/zerocopy#674

Open

RalfJung mentioned this pull request Feb 16, 2024

align_offset, align_to: no longer allow implementations to spuriously fail to align #121201

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

miri: support 'promising' alignment for symbolic alignment check #117840

miri: support 'promising' alignment for symbolic alignment check #117840

RalfJung commented Nov 12, 2023

rustbot commented Nov 12, 2023

rustbot commented Nov 12, 2023

This comment has been minimized.

cjgillot Nov 19, 2023

RalfJung Nov 19, 2023

RalfJung commented Nov 20, 2023

bors commented Nov 21, 2023

RalfJung commented Dec 2, 2023

cjgillot commented Dec 3, 2023

bors commented Dec 3, 2023

bors commented Dec 3, 2023

This comment has been minimized.

bors commented Dec 3, 2023

RalfJung commented Dec 3, 2023

bors commented Dec 3, 2023

bors commented Dec 3, 2023

bors commented Dec 4, 2023

rust-timer commented Dec 4, 2023

miri: support 'promising' alignment for symbolic alignment check #117840

miri: support 'promising' alignment for symbolic alignment check #117840

Conversation

RalfJung commented Nov 12, 2023

rustbot commented Nov 12, 2023

rustbot commented Nov 12, 2023

This comment has been minimized.

cjgillot Nov 19, 2023

Choose a reason for hiding this comment

RalfJung Nov 19, 2023

Choose a reason for hiding this comment

RalfJung commented Nov 20, 2023

bors commented Nov 21, 2023

RalfJung commented Dec 2, 2023

cjgillot commented Dec 3, 2023

bors commented Dec 3, 2023

bors commented Dec 3, 2023

This comment has been minimized.

bors commented Dec 3, 2023

RalfJung commented Dec 3, 2023

bors commented Dec 3, 2023

bors commented Dec 3, 2023

bors commented Dec 4, 2023

rust-timer commented Dec 4, 2023

Overall result: no relevant changes - no action needed

Instruction count

Max RSS (memory usage)

Cycles

Binary size