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: calculate visibility on-demand #91408

Closed
wants to merge 1 commit into from

Conversation

jyn514
Copy link
Member

@jyn514 jyn514 commented Dec 1, 2021

inline_stmt_id is very hacky and will probably lose all the memory improvements I was hoping for. Maybe we can change inlined items to have the DefId of the use statement directly instead of storing both?

Helps with #90852 (doesn't fix it because I haven't yet switched to ty::Visibility directly).

r? @camelid

@jyn514 jyn514 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. I-compiletime Issue: Problems and improvements with respect to compile times. labels Dec 1, 2021
@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Dec 1, 2021
src/librustdoc/clean/mod.rs Outdated Show resolved Hide resolved
Comment on lines +355 to +356
/// If this item was inlined, the DefId of the `use` statement.
crate inline_stmt_id: Option<DefId>,
Copy link
Member Author

Choose a reason for hiding this comment

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

boooooo

src/librustdoc/clean/types.rs Outdated Show resolved Hide resolved
src/librustdoc/clean/types.rs Outdated Show resolved Hide resolved
@rust-log-analyzer

This comment has been minimized.

@jyn514 jyn514 force-pushed the visibility branch 3 times, most recently from fc9f894 to 19fdd05 Compare December 1, 2021 00:31
@jyn514 jyn514 changed the title WIP: rustdoc: calculate visibility on-demand rustdoc: calculate visibility on-demand Dec 1, 2021
@jyn514
Copy link
Member Author

jyn514 commented Dec 1, 2021

@bors try @rust-timer queue

@rust-timer
Copy link
Collaborator

Awaiting bors try build completion.

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

@rustbot rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Dec 1, 2021
@bors
Copy link
Contributor

bors commented Dec 1, 2021

⌛ Trying commit 19fdd05f4e02e7a40d8f639e38cb7ead3a8e2ab2 with merge fbec2c38e225491dba4fab51850edaaacea88976...

@jyn514 jyn514 marked this pull request as ready for review December 1, 2021 00:35
@bors
Copy link
Contributor

bors commented Dec 1, 2021

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

@rust-timer
Copy link
Collaborator

Queued fbec2c38e225491dba4fab51850edaaacea88976 with parent 207c80f, future comparison URL.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (fbec2c38e225491dba4fab51850edaaacea88976): comparison url.

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

  • Moderate improvement in instruction counts (up to -0.9% on full builds of helloworld)

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 led to changes in compiler perf.

@bors rollup=never
@rustbot label: +S-waiting-on-review -S-waiting-on-perf -perf-regression

@rustbot rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Dec 1, 2021
@camelid
Copy link
Member

camelid commented Dec 1, 2021

Up to 1% improvements on doc instructions counts :)

max-rss is a bit mixed, though I think overall positive.

@camelid
Copy link
Member

camelid commented Dec 1, 2021

inline_stmt_id is very hacky and will probably lose all the memory improvements I was hoping for. Maybe we can change inlined items to have the DefId of the use statement directly instead of storing both?

Hmm, I'd rather avoid inline_stmt_id, but using the use's DefId for the inlined items seems even hackier.

src/librustdoc/clean/mod.rs Outdated Show resolved Hide resolved
}
_ => {}
}
// If this item was inlined, show the visibility of the `use` statement, not the definition.
Copy link
Member

@camelid camelid Dec 1, 2021

Choose a reason for hiding this comment

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

This doesn't seem quite correct. Take this code for example:

// crate a

pub struct S {
  pub x: i32,
  y: i32,
}

// crate b

pub(crate) use a::S;

If --document-private-items is passed, then I think the documentation for b::S should look like this (although I may not be remembering the inlining rules quite right):

pub(crate) struct S {
  pub(crate) x: i32,
  y: i32,
}

But with your change, I think it will look like this:

pub(crate) struct S {
  pub(crate) x: i32,
  pub(crate) y: i32,
}

Can you test that code (or a variant of it to get the inlining to happen) before and after this change to check?

Copy link
Member

Choose a reason for hiding this comment

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

Or perhaps this won't happen because inlining doesn't occur for struct fields? But I feel like this sort of bug could probably occur with other items.

Copy link
Member Author

Choose a reason for hiding this comment

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

This is exactly the same behavior as before, whatever that happened to be. I just moved the logic from try_inline to visibility().

Copy link
Member Author

Choose a reason for hiding this comment

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

also, I don't think this can happen for struct fields because you can't import them directly, only the struct itself. Enum variants can be imported, but they're special-cased earlier anyway.

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 couldn't get y to appear with pub(crate) use (maybe due to #91094 ?) but with pub use the docs look like this on nightly:
image
so uhh yeah this is a pre-existing bug, good catch 😅

Copy link
Member

Choose a reason for hiding this comment

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

This is exactly the same behavior as before, whatever that happened to be. I just moved the logic from try_inline to visibility().

Ah, I see.

Comment on lines +420 to +423
let def_id = match self.inline_stmt_id {
Some(inlined) => inlined,
None => def_id,
};
Copy link
Member

Choose a reason for hiding this comment

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

Shouldn't this check be done before the big match *self.kind { above? It seems like this does extra work for inlined items, and the code's a bit harder to understand.

Copy link
Member Author

Choose a reason for hiding this comment

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

No, because then all the uses of def_id in the match would be wrong (e.g. associated_item and overriding the ExternCrateItem def_id).

Copy link
Member Author

Choose a reason for hiding this comment

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

also I'm not sure what you mean by extra work - this isn't doing an early return, it's just reassigning def_id.

Copy link
Member

Choose a reason for hiding this comment

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

What I'm suggesting is changing this to be an early return. What's the point of calculating def_id earlier if this code overrides it anyway?

@camelid camelid added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. A-visibility Area: Visibility / privacy and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 1, 2021
- lots of staring really hard at the existing code to make sure the
  behavior matches
- store `inline_stmt_id` and `crate_stmt_id` to be able to get their visibility (rustdoc stores the IDs of the item definition in `clean::Item`, not the re-export)
Comment on lines +670 to +671
/// The id of the `extern crate` statement, not the crate itself.
crate_stmt_id: LocalDefId,
Copy link
Member

@camelid camelid Dec 1, 2021

Choose a reason for hiding this comment

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

Why can't this use Item.inline_stmt_id? Or I guess is this not quite the same as inline_stmt_id? Still, it feels like they should be merged somehow since they're similar.

@bors
Copy link
Contributor

bors commented Dec 2, 2021

☔ The latest upstream changes (presumably #91291) made this pull request unmergeable. Please resolve the merge conflicts.

@camelid
Copy link
Member

camelid commented Dec 8, 2021

@bors rollup=never (since the clean/types.rs changes may impact perf)

@JohnCSimon JohnCSimon added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jan 23, 2022
@jyn514
Copy link
Member Author

jyn514 commented Feb 11, 2022

not planning to follow up on this

@jyn514 jyn514 closed this Feb 11, 2022
@Wardenfar
Copy link
Contributor

@camelid is there any interest in resolving the merge conflict on this PR ?

bors added a commit to rust-lang-ci/rust that referenced this pull request Nov 2, 2022
… r=notriddle

Make rustdoc Item::visibility computed on-demand

This is a take-over of rust-lang#91408.

Helps with rust-lang#90852 (needs to use `ty::Visibility` directly too).

cc `@camelid`
r? `@notriddle`
@jyn514 jyn514 deleted the visibility branch November 3, 2022 18:34
RalfJung pushed a commit to RalfJung/miri that referenced this pull request Nov 5, 2022
Make rustdoc Item::visibility computed on-demand

This is a take-over of rust-lang/rust#91408.

Helps with rust-lang/rust#90852 (needs to use `ty::Visibility` directly too).

cc `@camelid`
r? `@notriddle`
RalfJung pushed a commit to RalfJung/rust-analyzer that referenced this pull request Apr 20, 2024
Make rustdoc Item::visibility computed on-demand

This is a take-over of rust-lang/rust#91408.

Helps with rust-lang/rust#90852 (needs to use `ty::Visibility` directly too).

cc `@camelid`
r? `@notriddle`
RalfJung pushed a commit to RalfJung/rust-analyzer that referenced this pull request Apr 27, 2024
Make rustdoc Item::visibility computed on-demand

This is a take-over of rust-lang/rust#91408.

Helps with rust-lang/rust#90852 (needs to use `ty::Visibility` directly too).

cc `@camelid`
r? `@notriddle`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-visibility Area: Visibility / privacy C-cleanup Category: PRs that clean code up or issues documenting cleanup. I-compiletime Issue: Problems and improvements with respect to compile times. S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. 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.

9 participants