don't UB on dangling ptr deref, instead check inbounds on projections

[RalfJung]

This implements rust-lang/reference#1387 in Miri. See that PR for what the change is about.

Detecting dangling references in let x = &...; is now done by validity checking only, so some tests need to have validity checking enabled. There is no longer inherently a "nodangle" check in evaluating the expression &*ptr (aside from the aliasing model).

r? @oli-obk

Based on:

• replace 'UB on raw ptr deref' with UB on place projection/access reference#1387
• const-eval: make misalignment a hard error #115524

[rustbot]

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

The Miri subtree was changed

cc @rust-lang/miri

[RalfJung]

This test no longer errors since * no longer checks that the place is dereferenceable (and CTFE doesn't do validity checks that would catch the invalid reference).

[oli-obk]

I am unsure about not testing this behaviour. On the one hand, we'd be testing UB not being detected, on the other hand, we'd want to know if this behaviour changes again...

[RalfJung]

I can add it back as a -Zextra-const-ub-checks test.

[oli-obk]

I guess I meant leaving it in as a normal test that now passes, with a note that it could stop passing at any time and that's not a breaking change. But -Zextra-const-ub-checks is also good.

[RalfJung]

This also checks that the error is not reported without the flag, so we will notice if behavior changes again.

[RalfJung]

@bors try @rust-timer queue

[bors]

⌛ Trying commit dff61cb7c2f8f2d12ce99373de4e7632f22b603b with merge 930f5dd6fbaa5068ed93e39fac128cc5f4118778...

[RalfJung]

@bors try

[bors]

⌛ Trying commit c5179d863cccdbdf224817e551ab941269e25068 with merge db3fc710c57da8e3db165b63e17f5397b020e4d0...

[bors]

☀️ Try build successful - checks-actions
Build commit: db3fc710c57da8e3db165b63e17f5397b020e4d0 (db3fc710c57da8e3db165b63e17f5397b020e4d0)

[rust-timer]

Finished benchmarking commit (db3fc710c57da8e3db165b63e17f5397b020e4d0): comparison URL.

Overall result: ❌✅ regressions and improvements - ACTION NEEDED

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

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.8%	[0.7%, 0.9%]	4
Regressions ❌ (secondary)	1.3%	[1.0%, 2.1%]	25
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-5.0%	[-5.7%, -4.4%]	6
All ❌✅ (primary)	0.8%	[0.7%, 0.9%]	4

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.4%	[1.0%, 3.8%]	2
Regressions ❌ (secondary)	4.4%	[2.2%, 5.4%]	5
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.5%	[-2.1%, -0.9%]	2
All ❌✅ (primary)	2.4%	[1.0%, 3.8%]	2

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)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-4.0%	[-4.6%, -3.6%]	5
All ❌✅ (primary)	-	-	0

Binary size

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

Bootstrap: missing data

[RalfJung]

So the stress test actually got faster, but a bunch of other benchmarks get slower. I thought of a way to keep lazy iteration, let's see if that helps. If not, the regression is probably truly caused by doing an inbounds check for each element (rather than a single check upfront), and that will be harder to avoid.

@bors try @rust-timer queue

[oli-obk]

r=me with or without test re-added

[oli-obk]

I am unsure about not testing this behaviour. On the one hand, we'd be testing UB not being detected, on the other hand, we'd want to know if this behaviour changes again...

[RalfJung]

@bors r=oli-obk

[bors]

📌 Commit 1ac153f has been approved by oli-obk

It is now in the queue for this repository.

[bors]

⌛ Testing commit 1ac153f with merge e7bdc5f...

[bors]

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing e7bdc5f to master...

[rust-timer]

Finished benchmarking commit (e7bdc5f): comparison URL.

Overall result: ❌ regressions - 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
Regressions ❌ (secondary)	0.7%	[0.5%, 1.0%]	17
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

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)	1.2%	[0.5%, 2.3%]	4
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.1%	[-1.1%, -1.1%]	1
All ❌✅ (primary)	-	-	0

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

Binary size

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

Bootstrap: 624.367s -> 625.899s (0.25%)
Artifact size: 305.57 MiB -> 305.58 MiB (0.00%)

[RalfJung]

Some regressions were expected base on prior benchmarks, this is as good as I managed to get it. Only secondary benchmarks are affected.

The likely cause is that we now are doing inbounds checks on each place projection. Previously we didn't have to do that, the check performed on * was sufficient, but now * has no more checks so there can be UB in the place projection. We could disable that UB check in const-eval, but the regressions don't seem big enough to justify that.

[pnkfelix]

Visiting for weekly perf triage

• From skimming the PR, one can see that the PR author (RalfJung) iterated on this to identify a solution that would minimize regressions.
• As noted by the PR author, only secondary benchmarks were affected.
• Also, while instruction-counts regressed, the cycle-counts
  did not, at least not enough to pass our noise threshold.
• marking as triaged.

@rustbot label: +perf-regression-triaged