[JonathanBrouwer]

View all comments

This PR implements MCP rust-lang/compiler-team#1044.
It is split up into commits, each commit passes tests, and reviewing commit by commit is therefore heavily recommended. Each commit contains a description. The first commit makes the big change, and the other commits are cleanup.

This PR causes a minor performance regression, specifically on the libc and externs benchmark:
#163758 (comment)
This is caused by that parameters on foreign functions are now assigned HIR IDs and Params are allocated for them, so slightly more work is needed.
Both of these crates are basically only foreign functions, so not very representative of an average rust program.

r? @Kivooeo

[JonathanBrouwer]

@bors try @rust-timer queue

[rust-bors]

💔 Test for be17f02 failed: CI. Failed jobs:

• try - dist-aarch64-linux-quick (web logs, enhanced plaintext logs)
• try - dist-x86_64-linux-quick (web logs, enhanced plaintext logs)

[JonathanBrouwer]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: b0e36da (b0e36dabc37e5dc5550a520d05ab86f3c07ef73a)
Base parent: f48b3e6 (f48b3e61eeece268609bd920fcca1ded047db7ca)

[rust-timer]

Finished benchmarking commit (b0e36da): comparison URL.

Overall result: ❌✅ regressions and improvements - 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.1%	[0.1%, 0.1%]	3
Regressions ❌ (secondary)	1.8%	[0.3%, 3.2%]	12
Improvements ✅ (primary)	-0.2%	[-0.6%, -0.1%]	52
Improvements ✅ (secondary)	-0.3%	[-0.6%, -0.0%]	56
All ❌✅ (primary)	-0.2%	[-0.6%, 0.1%]	55

Max RSS (memory usage)

Results (secondary 0.8%)

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)	2.3%	[2.0%, 2.9%]	5
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-6.6%	[-6.6%, -6.6%]	1
All ❌✅ (primary)	-	-	0

Cycles

Results (secondary 3.7%)

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)	4.3%	[2.2%, 6.8%]	9
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.6%	[-1.6%, -1.6%]	1
All ❌✅ (primary)	-	-	0

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: 490.122s -> 491.234s (0.23%)
Artifact size: 408.65 MiB -> 409.03 MiB (0.09%)

[JonathanBrouwer]

@bors try @rust-timer queue

[JonathanBrouwer]

This was blocked on the MCP being accepted, it now is :)

[JonathanBrouwer]

@nnethercote would you like to take a look at this PR?
I think the perf regression from #163758 (comment) is just from doing more work, since we allocate more Params. This also explains the input-stats changes

[Kivooeo]

Diagnostics for this code will change, and not in a better way

struct NeedsCopy<T: Copy>(T);
extern "C" {
    fn f(x: i32, ...) -> NeedsCopy<String>;
}

Previously it gave this:

error[E0277]: the trait bound `String: Copy` is not satisfied
 --> test.rs:3:26
  |
3 |     fn f(x: i32, ...) -> NeedsCopy<String>;
  |                          ^^^^^^^^^^^^^^^^^ the trait `Copy` is not implemented for `String`

now it gives this:

error[E0277]: the trait bound `String: Copy` is not satisfied
 --> test.rs:3:18
  |
3 |     fn f(x: i32, ...) -> NeedsCopy<String>;
  |                  ^^^ the trait `Copy` is not implemented for `String`

View changes since this review

[JonathanBrouwer]

Fixed it + added a regression test.
Thanks for catching that! The root cause here is that c-variadics are just handled quite poorly in the THIR, we should improve that but I will not do that in this PR

[ada4a]

Most of these are about the fact that the calls to TyCtxt::hir_body can be pushed down now that we don't need Body in order to get the params.

View changes since this review

[JonathanBrouwer]

I believe I've addressed all feedback, thanks!
@rustbot ready

[Kivooeo]

I will need few more days to click green button, thanks for working on it and fixing everything so fast!

[JonathanBrouwer]

Take your time, a few days is already pretty fast for such a big PR :)

[ada4a]

awesome, thank you so much:) just a few follow-up nits, but otherwise lgtm

View changes since this review

[teor2345]

Thank you for cleaning up the CVarArgs mess and the pretty printing, I struggled with those a bit when making changes to this code.

Just some nits, none of them blocking.

View changes since this review

[teor2345]

I think this is already checked in the AST validation pass?
Or is there a reason to check it again?

[JonathanBrouwer]

This is indeed already checked in de AST pass, note that this only emits a delayed bug.
There are quite a few places in the HIR that assume that if there is a CVarArgs argument, it is at the end. The easiest way to make these places work as expected, is to change any CVarArgs that is not at the end, into a Err variant