[rustdoc] hide item that is not marked as doc(inline) and whose src is doc(hidden)

[xizheyin]

Part of #137342

[rustbot]

r? @notriddle

rustbot has assigned @notriddle.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[notriddle]

1. The 👻 icon should never, ever appear unless you've passed --document-hidden-items to the CLI. The fact that a documented item's consumer-visible path is a re-export of a hidden item is an implementation detail and should not appear in the docs. Also, mystery meat icons should be avoided when the reader hasn't opted into them.

2. I've also found the spot where the decision was made to ignore re-exports of hidden items: Unify behaviours for re-exports of #[doc(hidden)] #109697 (comment)

   The problem, just to summarize, is caused by namespaces. You're allowed to do this:

   mod internals {
       pub type MyType = ();
       #[doc(hidden)] pub const MyType: () = ();
   }
   #[doc(inline)] pub use internals::MyType as MyType2;

   Presumably, you don't want the const to show up, only the type.

[xizheyin]

Yeah, so as discussion here, both hidden_self_reexport and hidden_self_reexport_inline shouldn't be visible.

[xizheyin]

r? @GuillaumeGomez

[xizheyin]

This seems to work, is there anything else that needs to be changed? @GuillaumeGomez

[GuillaumeGomez]

Heading to the right direction, but still changes to be done.

[compiler-errors]

@rust-timer build 20f8c19

[rust-timer]

Finished benchmarking commit (20f8c19): comparison URL.

Overall result: ❌ regressions - please read the text below

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 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
Regressions ❌ (secondary)	167.7%	[167.7%, 167.7%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary -1.5%)

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

Cycles

Results (primary 1.3%, secondary 43.2%)

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.3%	[0.7%, 2.5%]	3
Regressions ❌ (secondary)	43.2%	[3.7%, 82.7%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	1.3%	[0.7%, 2.5%]	3

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 773.144s -> 773.568s (0.05%)
Artifact size: 362.14 MiB -> 362.17 MiB (0.01%)

[GuillaumeGomez]

Wow, ok, gonna send a fix because it's way too bad.

[xizheyin]

It seems that traversing the list causes the complexity to change from o(n) to O (n²). Is there any better way? @GuillaumeGomez

[GuillaumeGomez]

Not sure yet.

[xizheyin]

Do I need to restore it to the way it was before I submitted it?

[GuillaumeGomez]

No it's fine. The case where it's pretty terrible is made to check this case in particular. The problem here is more global. We should really rewrite how we strip hidden items because currently it's a mess.

[GuillaumeGomez]

I opened #138168 to keep track of this work.

[xizheyin]

Yes, according to my observation, there may be problems when converting from ast to clean.

[notriddle]

Do you have an algorithm in mind that will do the correct thing without the performance problem?

[GuillaumeGomez]

I think we should handle inlining and stripping at the same time. That would allow to make the conversion correctly based on the needs.