-
Notifications
You must be signed in to change notification settings - Fork 13.5k
Remove unnecessary Option
wrapping around Crate.module
#83415
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
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.