Fix invalid missing documentation lint reporting for re-exports

[GuillaumeGomez]

Fixes#108570.

The problem was that, if an item is re-exported, we don't check if it's actually displayed into the documentation. To do so, I changed the check this way:

• If it's directly public, check for it.
• For re-exports, check the re-exported item directly.

Like that, if an item is re-exported, it'll just be checked on the re-export directly.

Not sure who should be set as reviewer here so I'll just ping @notriddle and wait for bors to assign someone.

[rustbot]

r? @petrochenkov

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

[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

[GuillaumeGomez]

Just discovered some weird re-exports when running in test mode in liballoc. I added #[allow(missing_docs)] on them.

[petrochenkov]

Is there any history behind these changes? What issues do they fix?
From the PR description it's entirely unclear what's going on.

Is this about documentation being lost on reexport items from other crates?
In that case it's something that needs to be actually fixed, not papered over by a lint.

[GuillaumeGomez]

Sorry, I forgot to link the issue... I'll update the first comment too. The issue: #108570

[petrochenkov]

I've just found #108570 too.

So it's not about dropped docs, but about making the missing_docs lint in rustc more in sync with doc hiding in rustdoc.
That means duplicating all the doc hiding logic from rustdoc in rustc, I'm not entirely sure it's a good idea, but I'll check in more details in the next few days.

[GuillaumeGomez]

If you have suggestions on how to prevent this duplication (which I'm not super happy about either...), I'd gladly hear it. 😉

[petrochenkov]

In the meantime let's do a perf run.
@bors try @rust-timer queue

[bors]

⌛ Trying commit a2ac0ff with merge e1a6761a2474c0d7d9183f20b15fa5426cc2c301...

[bors]

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

[bors]

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

[rust-timer]

Finished benchmarking commit (e1a6761a2474c0d7d9183f20b15fa5426cc2c301): 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

Warning ⚠: The following benchmark(s) failed to build:

• unicode-normalization-0.1.19
• cranelift-codegen-0.82.1

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
Regressions ❌ (secondary)	3.3%	[1.8%, 4.8%]	12
Improvements ✅ (primary)	-0.7%	[-0.9%, -0.4%]	4
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.7%	[-0.9%, -0.4%]	4

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)	1.9%	[0.4%, 5.5%]	4
Regressions ❌ (secondary)	3.3%	[3.3%, 3.3%]	1
Improvements ✅ (primary)	-0.5%	[-0.5%, -0.5%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	1.4%	[-0.5%, 5.5%]	5

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.5%	[0.5%, 0.5%]	1
Regressions ❌ (secondary)	4.5%	[2.8%, 6.5%]	10
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.5%	[0.5%, 0.5%]	1

[GuillaumeGomez]

That's quite the regression. I need to check how to improve this situation.

[petrochenkov]

I suggest not spending time on attempts to improve the current approach.
Using hir::ItemKind::Use is almost never a good idea, both in rustc and rustdoc.
For example, neither use_path.res.last() for single imports, nor for child in cx.tcx.hir().module_items(res_def_id) are correct, even if they lead to results resembling the truth.
(E.g. you have to add technical debt like #106952 on top of that to patch arising issues.)

The module_reexports needs to be used instead, but it doesn't return enough information.
I'll check what additional data ModChild need to contain and try to add them, it may be helpful in other places too.

[GuillaumeGomez]

Sounds good to me, thanks! Closing then.

[petrochenkov]

@GuillaumeGomez
By the way, is behavior of doc(hidden) documented anywhere?

• What nodes support it
• When it is applied recursively and when not?
• Can a doc(hidden) item be un-hidden through a non-hidden reexport?
• etc.

I thought I had some understanding, but then #107000 and related PRs changed the rules again.

[GuillaumeGomez]

It's not documented anywhere but it really should. I'll try to update the rustdoc book today so the rules of re-exports and doc(hidden) are written down somewhere and can be used as reference.