rustdoc: Unindent doc fragments on Attributes construction

[petrochenkov]

Attributes can be constructed at arbitrary points, even after the unindent_comments pass.
Attributes that are constructed too late end up unindented.

All doc fragments need to be eventually indented before use, so there are no reasons to not do this immediately during their construction.

Fixes https://rust-lang.zulipchat.com/#narrow/stream/266220-rustdoc/topic/.60unindent_comments.60.20cannot.20work.20as.20a.20separate.20pass.
I'm not sure how to make a minimized reproduction, but unindenting the fragments during their construction should fix the issue.. by construction, and I also verified that all doc strings now hit the resolver_caches.markdown_links cache in #94857.

[rust-highfive]

Some changes occurred in clean/types.rs.

cc @camelid

[rust-highfive]

r? @notriddle

(rust-highfive has picked a reviewer for you, use r? to override)

[GuillaumeGomez]

Thanks for working on this! I think it'll be positive for perf so let's confirm it!

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit 7803a41 with merge cf182b12d75c173ba0e3fa9e97529a6dece943da...

[bors]

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

[rust-timer]

Queued cf182b12d75c173ba0e3fa9e97529a6dece943da with parent 1dec35a, future comparison URL.

[rust-timer]

Finished benchmarking commit (cf182b12d75c173ba0e3fa9e97529a6dece943da): comparison url.

Summary:

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

	Regressions 😿 (primary)	Regressions 😿 (secondary)	Improvements 🎉 (primary)	Improvements 🎉 (secondary)	All 😿 🎉 (primary)
count1	1	9	0	0	1
mean2	0.4%	0.4%	N/A	N/A	0.4%
max	0.4%	0.4%	N/A	N/A	0.4%

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

Footnotes

1. number of relevant changes ↩

2. the arithmetic mean of the percent change ↩

[GuillaumeGomez]

I wonder if there is a possibility that attributes are cleaned more than once in some cases...

[petrochenkov]

Maybe.
I've seen something that could be it when debugging #94857.
If there's no explicit check against it then it's quite possible.

[GuillaumeGomez]

Since it was a pass, there was no need for it. Maybe you might know more about this @camelid ?

[camelid]

The regression is only on artificial benchmarks (I include helloworld amongst those), so it doesn't seem to matter much in practice.

I'm not sure why there's a regression; I would've expected perf improvement. The only thing I can think of is what you said, that it's being cleaned multiple times.

[petrochenkov]

I'm not sure why there's a regression; I would've expected perf improvement.

Well, we are applying unindent_comments to more attributes after all, the delta is attributes that are created after the unindent_comments pass and weren't previously unindented, that's kind of the purpose of the PR.

[GuillaumeGomez]

I'm not sure it's only the new types getting unindented that have this impact. I think it's called more than once, but let's worry about it in another PR as this is already a nice improvement. Can you open an issue to investigate about this so we don't forget please @petrochenkov ?

@bors: r+ rollup=never

[bors]

📌 Commit 7803a41 has been approved by GuillaumeGomez

[bors]

⌛ Testing commit 7803a41 with merge 8b23930...

[bors]

☀️ Test successful - checks-actions
Approved by: GuillaumeGomez
Pushing 8b23930 to master...

[rust-timer]

Finished benchmarking commit (8b23930): comparison url.

Summary:

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

	Regressions 😿 (primary)	Regressions 😿 (secondary)	Improvements 🎉 (primary)	Improvements 🎉 (secondary)	All 😿 🎉 (primary)
count1	1	10	0	0	1
mean2	0.4%	0.4%	N/A	N/A	0.4%
max	0.4%	0.5%	N/A	N/A	0.4%

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. number of relevant changes ↩

2. the arithmetic mean of the percent change ↩

[rylev]

Given there is an issue to investigate this further and the regressions are relatively small and confined to non-real-world crates, I'll mark this as triaged.

@rustbot label: +perf-regression-triaged