Make lowering a query

[cjgillot]

Split from #88186.

This PR refactors the relationship between lowering and the resolver outputs in order to make lowering itself a query.
In a first part, lowering is changed to avoid modifying resolver outputs, by maintaining its own data structures for creating new NodeIds and so.

Then, the TyCtxt is modified to allow creating new LocalDefIds from inside it. This is done by:

• enclosing Definitions in a lock, so as to allow modification;
• creating a query register_def whose purpose is to declare a LocalDefId to the query system.

See TyCtxt::create_def and TyCtxt::iter_local_def_id for more detailed explanations of the design.

[cjgillot]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit 8f3583b024d77e73b2a2c6a05d89404fb2bad707 with merge 7c9d6056d06c28788c27759f69c7722558f629b2...

[bors]

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

[rust-timer]

Queued 7c9d6056d06c28788c27759f69c7722558f629b2 with parent 297a801, future comparison URL.

[rust-timer]

Finished benchmarking commit (7c9d6056d06c28788c27759f69c7722558f629b2): comparison url.

Summary:

• Primary benchmarks: mixed results
• Secondary benchmarks: mixed results

	Regressions 😿 (primary)	Regressions 😿 (secondary)	Improvements 🎉 (primary)	Improvements 🎉 (secondary)	All 😿 🎉 (primary)
count1	16	26	10	12	26
mean2	0.3%	0.5%	-0.4%	-0.4%	0.1%
max	0.5%	0.9%	-0.5%	-0.7%	0.5%

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

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 led 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-review -S-waiting-on-perf +perf-regression

Footnotes

1. number of relevant changes ↩

2. the arithmetic mean of the percent change ↩

[cjgillot]

r? @michaelwoerister

[bors]

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

[michaelwoerister]

I've done a first pass through the commits but I'll need a while to understand what's going on here :)

[cjgillot]

The last commit should significantly simplify how the DepGraph understand the creation of new definitions.

[bors]

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

[michaelwoerister]

Sorry for being slow to review this. I blocked off some time on Monday to do it.

[bors]

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

[michaelwoerister]

OK, I've done another pass over the PR. It looks correct to me and it has many good improvements. Great work!

I'm not entirely happy with how special the handling of Definitions is. But I think that's unavoidable in the short term. Longer term we can hopefully remove it entirely (at least in its current form).

[rustbot]

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[michaelwoerister]

This looks good to me now, @cjgillot. You can r=me if you think it's ready.

[cjgillot]

@bors r=michaelwoerister

[bors]

📌 Commit 32a30ca has been approved by michaelwoerister

It is now in the queue for this repository.

[bors]

⌛ Testing commit 32a30ca with merge 0f573a0...

[bors]

☀️ Test successful - checks-actions
Approved by: michaelwoerister
Pushing 0f573a0 to master...

[rust-timer]

Finished benchmarking commit (0f573a0): comparison url.

Instruction count

• Primary benchmarks: 😿 relevant regressions found
• Secondary benchmarks: 😿 relevant regressions found

	mean1	max	count2
Regressions 😿 (primary)	0.5%	1.1%	76
Regressions 😿 (secondary)	0.8%	2.4%	57
Improvements 🎉 (primary)	N/A	N/A	0
Improvements 🎉 (secondary)	-0.2%	-0.2%	1
All 😿🎉 (primary)	0.5%	1.1%	76

Max RSS (memory usage)

Results

• Primary benchmarks: mixed results
• Secondary benchmarks: mixed results

	mean1	max	count2
Regressions 😿 (primary)	1.4%	1.4%	1
Regressions 😿 (secondary)	2.8%	3.9%	8
Improvements 🎉 (primary)	-1.1%	-1.1%	1
Improvements 🎉 (secondary)	-3.5%	-6.8%	6
All 😿🎉 (primary)	0.1%	1.4%	2

Cycles

Results

• Primary benchmarks: no relevant changes found
• Secondary benchmarks: 😿 relevant regressions found

	mean1	max	count2
Regressions 😿 (primary)	N/A	N/A	0
Regressions 😿 (secondary)	3.4%	4.2%	6
Improvements 🎉 (primary)	N/A	N/A	0
Improvements 🎉 (secondary)	N/A	N/A	0
All 😿🎉 (primary)	N/A	N/A	0

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

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

Footnotes

1. the arithmetic mean of the percent change ↩ ↩² ↩³

2. number of relevant changes ↩ ↩² ↩³

[Mark-Simulacrum]

Results here look to be a slight regression, but overall I think are not worth further investigation -- some of the benchmarks are prone to noise over the last week or so (html5ever, tt-muncher in particular), and though other benchmarks are also affected they're not large enough that we should devote time to investigating in my opinion.