Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rustdoc: Cleanup various clean types #88379

Merged
merged 16 commits into from
Oct 9, 2021
Merged

Conversation

camelid
Copy link
Member

@camelid camelid commented Aug 27, 2021

Cleanup various clean types.

@camelid camelid added C-cleanup Category: PRs that clean code up or issues documenting cleanup. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. labels Aug 27, 2021
@BubbaSheen

This comment has been minimized.

@jyn514 jyn514 self-assigned this Aug 27, 2021
Copy link
Member

@jyn514 jyn514 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got about halfway through and ran out of time - this is amazing work ❤️ not sure why it's marked as a draft, but feel free to ignore the comments until you're happy with it :)

src/librustdoc/html/render/mod.rs Outdated Show resolved Hide resolved
src/librustdoc/html/render/mod.rs Outdated Show resolved Hide resolved
src/librustdoc/clean/types.rs Outdated Show resolved Hide resolved
res: self.res,
segments: if self.is_global() { &self.segments[1..] } else { &self.segments }.clean(cx),
segments: self.segments.clean(cx),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, what will segments[0] be for a global path? Just an empty string?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought kw::PathRoot, but it may not be because otherwise I'd expect tests to be failing. I'll have to look into it.

Copy link
Member Author

@camelid camelid Sep 1, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It will be kw::PathRoot, which renders as {{root}}, but I haven't found a way to make rustdoc (erroneously) print out {{root}}::foo::bar. (It may be possible though.)

src/librustdoc/clean/auto_trait.rs Outdated Show resolved Hide resolved
// Paths like `T::Output` and `Self::Output` should be rendered with all segments.
resolved_path(f, did, path, is_generic, use_absolute, cx)
resolved_path(f, did, path, path.is_generic(), use_absolute, cx)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You don't need to pass in path.is_generic, you can calculate it in resolved_path.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're looking at an old diff; I changed path.is_generic() to false in a later commit (the one we're nervous about ;).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I should probably remove the comment above this call too.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have since dropped the commit that removed is_generic(), so this place now has resolved_path(..., path.is_assoc_ty()). I think resolved_path and related functions need to be cleaned up a lot in general, but I think let's do that in a different PR so this one doesn't keep growing ;)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, it looks like I should be able to pretty easily clean up resolved_path such that the argument that path.is_generic() is used for is removed!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

... or not; it looks like there's a single place where use_absolute is not false and not None :/

src/librustdoc/html/format.rs Outdated Show resolved Hide resolved
src/librustdoc/clean/types.rs Outdated Show resolved Hide resolved
src/librustdoc/html/render/print_item.rs Outdated Show resolved Hide resolved
src/librustdoc/html/render/mod.rs Outdated Show resolved Hide resolved
@camelid
Copy link
Member Author

camelid commented Aug 27, 2021

Got about halfway through and ran out of time - this is amazing work ❤️ not sure why it's marked as a draft, but feel free to ignore the comments until you're happy with it :)

Thank you! ❤️

It's mainly marked as draft because some of the changes need more investigation (e.g., #88379 (comment)).

@camelid
Copy link
Member Author

camelid commented Aug 27, 2021

Rebased to fix merge conflicts.

@camelid camelid added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Aug 27, 2021
@rust-log-analyzer

This comment has been minimized.

@jyn514
Copy link
Member

jyn514 commented Aug 28, 2021

It's mainly marked as draft because some of the changes need more investigation (e.g., #88379 (comment)).

Ok. Can you split those into a separate PR so we can land the rest? There are a lot of great changes here :) but it's an awfully large diff and it makes it harder to review the more subtle changes.

@camelid
Copy link
Member Author

camelid commented Aug 28, 2021

It's mainly marked as draft because some of the changes need more investigation (e.g., #88379 (comment)).

Ok. Can you split those into a separate PR so we can land the rest? There are a lot of great changes here :) but it's an awfully large diff and it makes it harder to review the more subtle changes.

Sure! That's another reason why I marked it as draft, since I expected it would need to be split up.

@camelid camelid force-pushed the cleanup-clean branch 2 times, most recently from 96add5b to 6ecaa70 Compare August 28, 2021 02:14
@camelid
Copy link
Member Author

camelid commented Aug 28, 2021

@bors rollup=never

Since this may improve performance.

@rust-log-analyzer

This comment has been minimized.

@camelid camelid force-pushed the cleanup-clean branch 3 times, most recently from c901187 to 1fca27b Compare September 1, 2021 18:44
@camelid camelid added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Sep 1, 2021
@camelid
Copy link
Member Author

camelid commented Sep 1, 2021

@jyn514 Ok, I think this should be ready for another review. There are a few unresolved threads:

  1. rustdoc: Cleanup various clean types #88379 (comment)
  2. rustdoc: Cleanup various clean types #88379 (comment)
  3. rustdoc: Cleanup various clean types #88379 (comment)

I think the second and third ones should probably be left for future PRs. So, the first one is the main thread to be discussed. Or, if there's anything else you notice or have questions about, let me know!

I can also try to split up this PR further if it would make it easier to review.

@camelid camelid marked this pull request as ready for review September 1, 2021 20:59
src/librustdoc/clean/mod.rs Outdated Show resolved Hide resolved
camelid added a commit to camelid/rust that referenced this pull request Sep 1, 2021
Instead, return `Type::Infer` since compilation should fail anyway.
That's how rustdoc handles `hir::TyKind::Err`s, so this just extends
that behavior to `ty::Err`s when analyzing associated types.

For some reason, the error is printed twice with rustdoc (though only
once with rustc). I'm not sure why that is, but it's better than
panicking.

This commit also makes rustdoc fail early in the non-projection,
non-error case, instead of returning a `Res::Err` that would likely
cause rustdoc to panic later on. This change is originally from rust-lang#88379.
@bors
Copy link
Contributor

bors commented Oct 7, 2021

💥 Test timed out

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Oct 7, 2021
@rust-log-analyzer
Copy link
Collaborator

A job failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

@camelid
Copy link
Member Author

camelid commented Oct 7, 2021

I don't understand why this one builder (auto (dist-s390x-linux, ubuntu-latest-xl)) keeps timing out. This time it timed out after 4h24m, while even the macOS builder only took 2h47m. The build time for s390x-linux for the rollup PR that merged before my PR was tested was 2h 32m, so nowhere even close to the time out for my PR. The last part of the log is:

   Compiling tracing-tree v0.1.9
[RUSTC-TIMING] tracing_tree test:false 0.682
[RUSTC-TIMING] serde_derive test:false 5.011
[RUSTC-TIMING] serde_derive test:false 5.005
[RUSTC-TIMING] tracing_subscriber test:false 3.800
   Compiling rustdoc-json-types v0.1.0 (/checkout/src/rustdoc-json-types)
[RUSTC-TIMING] serde test:false 4.384
   Compiling tera v1.10.0
[RUSTC-TIMING] serde_json test:false 2.983
[RUSTC-TIMING] rustdoc_json_types test:false 2.985
   Compiling rustdoc v0.0.0 (/checkout/src/librustdoc)
[RUSTC-TIMING] tera test:false 24.695
Error: The operation was canceled.

So is it hanging while compiling rustdoc? Other PRs in the queue have merged, so it seems like it's specific to this PR. I just don't understand how my changes could cause only one of the builders to time out. Maybe monomorphization is taking longer since I removed a few Boxes? I still don't understand how it could be more than a negligible difference though.

EDIT: Based on the build log timestamps, it seems it is indeed timing out while compiling the rustdoc crate.

@camelid
Copy link
Member Author

camelid commented Oct 7, 2021

@hkratz suggests that this timeout may be due to #89609. Hopefully that'll be fixed soon, and this can get merged!

@camelid
Copy link
Member Author

camelid commented Oct 8, 2021

@bors retry

Stopgap CI fix is in a roll up at the front of the queue.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 8, 2021
@bors
Copy link
Contributor

bors commented Oct 9, 2021

⌛ Testing commit ebbcafb with merge 6eca024aa731feb4347f21453353a31e59ac09b9...

@camelid
Copy link
Member Author

camelid commented Oct 9, 2021

Looks like bors is likely to time out again, this time with i686-gnu. Although at least this time s390x-linux succeeded!

Since the last issue was LLVM related, I checked before/after for the update to the final LLVM 13.0 (the most recent change I saw to src/llvm-project), but CI actually got faster for i686-gnu after the update. It's still possible that's the cause, but it seems unlikely to me.

@bors
Copy link
Contributor

bors commented Oct 9, 2021

💥 Test timed out

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Oct 9, 2021
@rust-log-analyzer
Copy link
Collaborator

A job failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

@camelid
Copy link
Member Author

camelid commented Oct 9, 2021

@ehuss suggested on Zulip that I retry this since it may be spurious.

@bors retry

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 9, 2021
@bors
Copy link
Contributor

bors commented Oct 9, 2021

⌛ Testing commit ebbcafb with merge a8f2463...

@bors
Copy link
Contributor

bors commented Oct 9, 2021

☀️ Test successful - checks-actions
Approved by: jyn514
Pushing a8f2463 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Oct 9, 2021
@bors bors merged commit a8f2463 into rust-lang:master Oct 9, 2021
@rustbot rustbot added this to the 1.57.0 milestone Oct 9, 2021
@camelid camelid deleted the cleanup-clean branch October 9, 2021 22:14
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (a8f2463): comparison url.

Summary: This change led to moderate relevant improvements 🎉 in compiler performance.

  • Moderate improvement in instruction counts (up to -0.8% on full builds of issue-46449)

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

@rustbot label: -perf-regression

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-cleanup Category: PRs that clean code up or issues documenting cleanup. merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants