rustc_intrinsic: support functions without body

[RalfJung]

We synthesize a HIR body loop {} but such bodyless intrinsics.

Most of the diff is due to turning ItemKind::Fn into a brace (named-field) enum variant, because it carries a bool-typed field now. This is to remember whether the function has a body. MIR building panics to avoid ever translating the fake loop {} body, and the intrinsic logic uses the lack of a body to implicitly mark that intrinsic as must-be-overridden.

I first tried actually having no body rather than generating the fake body, but there's a lot of code that assumes that all function items have HIR and MIR, so this didn't work very well. Then I noticed that even rustc_intrinsic_must_be_overridden intrinsics have MIR generated (they are filled with an Unreachable terminator) so I guess I am not the first to discover this. ;)

r? @oli-obk

[rustbot]

HIR ty lowering was modified

cc @fmease

[rustbot]

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

Some changes occurred to the CTFE machinery

cc @rust-lang/wg-const-eval

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[rustbot]

The Miri subtree was changed

cc @rust-lang/miri

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

[oli-obk]

Most of the diff is due to turning ItemKind::Fn into a tuple enum variant, because it carries a bool-typed field now.

I think you mean turning the tuple variant into a struct variant.

Also, annoying work, but I would prefer this change to be in a previous commit and then just adding the new field in a later commit.

[RalfJung]

Ugh, disentangling this now will be painful :(

[oli-obk]

I can review as is. The effort for me to review as is is likely less than reviewing after splitting and you doing the splitting. Just keep it in mind for future stuff.

[RalfJung]

I can try git add -p, if that works it's hopefully not too bad.

I had no idea what I would have to do for this PR. I had to do a bunch of experimentation until something worked -- even for the future I wouldn't know how to have a nice git history for that without a lot of extra effort.

[RalfJung]

Yeah that strategy wasn't too bad, took around 20 minutes.

[oli-obk]

even for the future I wouldn't know how to have a nice git history for that without a lot of extra effort.

Whenever I encounter a situation where I want to change a tuple struct/variant to a struct/struct-variant or vice versa, I stash (well nowadays I jj new) and do that change first and then continue. It's very useful if you realize you didn't want that after all. To me it's less effort as I usually end up in such a situation while nothing builds anyway, so I can make the refactor build on its own. YMMV.

[oli-obk]

Thanks, that made it reviewable on my phone xD

@bors r+

[bors]

📌 Commit 3cd3649 has been approved by oli-obk

It is now in the queue for this repository.

[bors]

⌛ Testing commit 3cd3649 with merge fd127a3...

[bors]

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

[rust-timer]

Finished benchmarking commit (fd127a3): comparison URL.

Overall result: ❌ regressions - no action needed

@rustbot label: -perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	0.1%	[0.1%, 0.1%]	1
Regressions ❌ (secondary)	0.2%	[0.2%, 0.2%]	3
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.1%	[0.1%, 0.1%]	1

Max RSS (memory usage)

Results (primary 2.2%, secondary 1.8%)

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.2%	[1.4%, 3.1%]	2
Regressions ❌ (secondary)	1.8%	[1.8%, 1.8%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.2%	[1.4%, 3.1%]	2

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: 764.045s -> 763.089s (-0.13%)
Artifact size: 325.60 MiB -> 325.61 MiB (0.00%)