resolve: Preserve reexport chains in ModChildren

[petrochenkov]

This may be potentially useful for

• avoiding uses of hir::ItemKind::Use (which usually lead to correctness issues)
• preserving documentation comments on all reexports, including those from other crates
• preserving and checking stability/deprecation info on reexports
• all kinds of diagnostics

The second commit then migrates some hacky logic from rustdoc to module_reexports to make it simpler and more correct.
Ideally rustdoc should use module_reexports immediately at the top level, so hir::ItemKind::Uses are never used.
The second commit also fixes issues with #109330 and therefore
Fixes #109631
Fixes #109614
Fixes #109424

[rustbot]

r? @notriddle

(rustbot has picked a reviewer for you, use r? to override)

[petrochenkov]

@bors try @rust-timer queue

[bors]

⌛ Trying commit c3fc1061cc50992cc89e06dc3588a799abc6d576 with merge 7a2e02ca3818248e22d3a4b9735822679c02374f...

[petrochenkov]

cc @GuillaumeGomez

[bors]

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

[rust-timer]

Finished benchmarking commit (7a2e02ca3818248e22d3a4b9735822679c02374f): 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.9%	[0.5%, 1.2%]	10
Regressions ❌ (secondary)	2.5%	[0.4%, 5.9%]	7
Improvements ✅ (primary)	-0.7%	[-0.7%, -0.6%]	2
Improvements ✅ (secondary)	-0.4%	[-0.7%, -0.3%]	4
All ❌✅ (primary)	0.6%	[-0.7%, 1.2%]	12

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)	3.9%	[3.9%, 3.9%]	1
Regressions ❌ (secondary)	2.2%	[0.5%, 5.4%]	17
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.4%	[-1.5%, -1.3%]	2
All ❌✅ (primary)	3.9%	[3.9%, 3.9%]	1

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)	2.5%	[0.9%, 5.4%]	7
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

[rustbot]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[petrochenkov]

Some regressions in crates with large numbers of reexported names, like libc-0.2.124, are expected, we are simply encoding more information into metadata.

Some of the regressed crates (projection-caching, issue-88862) enter the trimmed_def_paths mode and report warnings by invoking very heavy diagnostic machinery that takes most of compilation time.

[petrochenkov]

The second commit shows some motivation for the first commit, but otherwise they are not related and I can split this PR into two for reviewing by different people if necessary.

[notriddle]

Most of the substantial changes here are being done in the resolver machinery.

r? compiler

Some of the regressed crates (projection-caching, issue-88862) enter the trimmed_def_paths mode and report warnings by invoking very heavy diagnostic machinery that takes most of compilation time.

Can you construct a test case that triggers one of these new warnings?

[petrochenkov]

@notriddle

Can you construct a test case that triggers one of these new warnings?

The warnings are not new, they are existing, they are just heavily using module_children for traversing the whole crate tree, and module_children just got more expensive due to the new field in ModChild.

[oli-obk]

@bors r+ rollup=never

About perf: This regresses a few test cases because there's a bit more rustdoc metadata in our metadata files and that just needs a bit more time to decode. These changes are needed to fix ICEs in rustdoc, which is why I'm landing it tregardless of the perf regressions. We should evaluate how to avoid regressions from rustdoc-specific metadata in general and not on an individual PR basis.

[bors]

📌 Commit 9da9373 has been approved by oli-obk

It is now in the queue for this repository.

[bors]

⌛ Testing commit 9da9373 with merge 7201301...

[bors]

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

[rust-timer]

Finished benchmarking commit (7201301): 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.7%	[0.4%, 1.0%]	17
Regressions ❌ (secondary)	1.3%	[0.4%, 5.7%]	22
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.7%	[0.4%, 1.0%]	17

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)	3.3%	[1.4%, 7.7%]	12
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.5%	[-3.8%, -1.5%]	6
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)	3.1%	[1.0%, 5.1%]	5
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

[rylev]

There are a few more regressions in the post merge perf run, but they seem to follow the same pattern as the regressions found pre-merge. I think we can just take this as a necessary trade off we need to make for the fixes that landed (as identified by @oli-obk here).

@rustbot label: +perf-regression-triaged

[petrochenkov]

These perf regressions were partially mitigated by #109772.