remove scalar size mismatch interpreter error, make it an ICE instead

[RalfJung]

This error was added in #71569 to deal with ICEs on incorrect Miri shim signatures. However, that was a partial fix: if the signature is "even more incorrect", using a non-scalar type where the type should be scalar, we still ICE. The proper fix is tracked in rust-lang/miri#3842, and that is already used for a good chunk of our shims.

I don't think it's worth keeping around the old, incomplete check here, so let's get rid of it.

Sadly, the to_$int methods on Scalar still return a Result as they must still error if the scalar is a pointer and we are in const-eval where we cannot turn that pointer into an integer. We should probably use ScalarInt in a lot more places where we currently use Scalar to statically exclude this case... but that's a change for another time.

[rustbot]

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

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

Some changes occurred to the CTFE machinery

cc @oli-obk, @lcnr

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri, @oli-obk, @lcnr

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[rustbot]

r? @petrochenkov

rustbot has assigned @petrochenkov.
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: compiler, mir
• compiler, mir expanded to 75 candidates
• Random selection from 18 candidates

[petrochenkov]

@bors r+

[rust-bors]

📌 Commit 93c99eb has been approved by petrochenkov

It is now in the queue for this repository.

[panstromek]

for #161289

@rust-timer build 02877d8

[rust-timer]

Finished benchmarking commit (02877d8): comparison URL.

Overall result: ❌ regressions - please read:

Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf.

Next, please: If you can, justify the regressions found in this try perf run in writing along with @rustbot label: +perf-regression-triaged. If not, fix the regressions and do another perf run. Neutral or positive results will clear the label automatically.

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

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	0.5%	[0.4%, 0.6%]	6
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.5%	[0.4%, 0.6%]	6

Max RSS (memory usage)

Results (primary -2.5%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	2.2%	[2.2%, 2.2%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-7.2%	[-7.2%, -7.2%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-2.5%	[-7.2%, 2.2%]	2

Cycles

Results (primary 2.1%, secondary 5.5%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	2.1%	[2.1%, 2.1%]	1
Regressions ❌ (secondary)	5.5%	[5.5%, 5.5%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.1%	[2.1%, 2.1%]	1

Binary size

Results (secondary 0.0%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.0%	[0.0%, 0.0%]	19
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Bootstrap: 455.347s -> 456.26s (0.20%)
Artifact size: 398.98 MiB -> 399.05 MiB (0.02%)

[panstromek]

Looks like this caused a regression in #161289

This intuitively seems like it should be an improvement instead, so it looks unexpected. Do we know where this regression is coming from? Can we do something about it?

[RalfJung]

Indeed this is very strange, I can only guess the the inliner is making worse decisions in some places now?

[Mark-Simulacrum]

Going to mark this as triaged as the fix PR seems to be on track. Thanks for digging in!