-
Notifications
You must be signed in to change notification settings - Fork 13.1k
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
Remove unnecessary Option
wrapping around Crate.module
#83415
Conversation
Now that we record the crate's name in its `clean::Item`, pushing the crate name onto the `stack` causes duplicate paths. E.g., the URL generated for the path `::foo::bar::baz` would be something like ../foo/foo/bar/baz With this commit, the URL is corrected to ../foo/bar/baz
I'm wondering if it was originally there so that we could `take` the module which enables `after_krate` to take an `&Crate`. However, the two impls of `after_krate` only use `Crate.name`, so we can pass just the name instead.
(rust-highfive has picked a reviewer for you, use r? to override) |
@@ -87,7 +87,7 @@ crate trait DocFolder: Sized { | |||
} | |||
|
|||
fn fold_crate(&mut self, mut c: Crate) -> Crate { | |||
c.module = c.module.take().and_then(|module| self.fold_item(module)); | |||
c.module = self.fold_item(c.module).unwrap(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there ever a case where this unwrap
will fail? Why does fold_item
return an Option
anyway?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fold_item
returns None
if the itme was stripped. I don't think the whole crate can be stripped so this should be fine.
(The first two commits are from #83399.) |
} else { | ||
panic!("collect-trait-impls can't run"); | ||
} | ||
let items = if let ModuleItem(Module { ref mut items, .. }) = *krate.module.kind { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like a future enhancement could be to store a Module
instead of an Item
. Probably we would need to add a few more fields to Module
(like DefId and name) to do that.
The previous changes mean that we can now remove this `Option`.
@@ -87,7 +87,7 @@ crate trait DocFolder: Sized { | |||
} | |||
|
|||
fn fold_crate(&mut self, mut c: Crate) -> Crate { | |||
c.module = c.module.take().and_then(|module| self.fold_item(module)); | |||
c.module = self.fold_item(c.module).unwrap(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fold_item
returns None
if the itme was stripped. I don't think the whole crate can be stripped so this should be fine.
@@ -102,5 +96,5 @@ crate fn run_format<'tcx, T: FormatRenderer<'tcx>>( | |||
} | |||
} | |||
prof.extra_verbose_generic_activity("renderer_after_krate", T::descr()) | |||
.run(|| format_renderer.after_krate(&krate, diag)) | |||
.run(|| format_renderer.after_krate(crate_name, diag)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It took me a second to realize: the reason this changed is because you partially moved out of krate
when adding krate.module
to the work list.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I mentioned that in the PR description:
I'm wondering if it was originally there so that we could take the
module which enables after_krate to take an &Crate. However, the two
impls of after_krate only use Crate.name, so we can pass just the
name instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right - that explains that it's possible, the krate.module
thing explains why it's necessary. :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I should've included more information :)
📌 Commit a7f902b has been approved by |
Rollup of 9 pull requests Successful merges: - rust-lang#83051 (Sidebar trait items order) - rust-lang#83313 (Only enable assert_dep_graph when query-dep-graph is enabled.) - rust-lang#83353 (Add internal io::Error::new_const to avoid allocations.) - rust-lang#83391 (Allow not emitting `uwtable` on Android) - rust-lang#83392 (Change `-W help` to display edition level.) - rust-lang#83393 (Codeblock tooltip position) - rust-lang#83399 (rustdoc: Record crate name instead of using `None`) - rust-lang#83405 (Slight visual improvements to warning boxes in the docs) - rust-lang#83415 (Remove unnecessary `Option` wrapping around `Crate.module`) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
I'm wondering if it was originally there so that we could
take
themodule which enables
after_krate
to take an&Crate
. However, the twoimpls of
after_krate
only useCrate.name
, so we can pass just thename instead.