-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Refactor librustdoc html backend #73767
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @GuillaumeGomez (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
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.
Please just remove the diag
parameter where it's unused. Otherwise looks good to me, thanks for working on this!
src/librustdoc/html/render.rs
Outdated
@@ -112,6 +113,9 @@ struct Context { | |||
id_map: Rc<RefCell<IdMap>>, | |||
pub shared: Arc<SharedContext>, | |||
pub cache: Arc<Cache>, | |||
pub parent: Rc<RefCell<Renderer>>, |
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.
Just a note (for myself and any other potential reviewer): those 3 variables were before in the run
function which became split in the FormatRenderer
trait.
src/librustdoc/formats/mod.rs
Outdated
} | ||
|
||
renderer.after_krate(&krate)?; | ||
renderer.after_run(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.
Note: this allows to check if any errors has occurred during the run, which allows to make the code inside after_krate
a bit lighter.
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
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.
Looks good! I left a few nits, feel free to ignore if they are preexisting.
☔ The latest upstream changes (presumably #73779) made this pull request unmergeable. Please resolve the merge conflicts. |
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.
I like the idea but this is going to conflict with every one of the intra-doc link PRs 😅
84ecd62
to
986f9a0
Compare
@jyn514 I couldn't find those PRs, do you mean they'll conflict because of moving |
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.
Looks good to me! Considering this is a huge PR (even if mainly doing code moves), I'll wait for at least one more review from someone on the @rust-lang/rustdoc team (ping @ollie27 )
☔ The latest upstream changes (presumably #74117) made this pull request unmergeable. Please resolve the merge conflicts. |
986f9a0
to
ad31823
Compare
@ollie27 Friendly ping, would you be able to review this? |
☔ The latest upstream changes (presumably #74330) made this pull request unmergeable. Please resolve the merge conflicts. |
Perhaps another person on @rust-lang/rustdoc can give this a once-over. I nominate... r? @Manishearth |
@jyn514 wanna review this? |
ad31823
to
4c4f300
Compare
☔ The latest upstream changes (presumably #74710) made this pull request unmergeable. Please resolve the merge conflicts. |
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.
minor nit, otherwise r=me!
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.
Most of these are about pre-existing issues, feel free to merge without addressing.
} | ||
} | ||
|
||
impl PathError for Error { |
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.
Pre-existing, but do you know why rustdoc uses a separate error type and trait here? It has wrappers around both io::Error
and std::error::Error
.
} | ||
|
||
impl PathError for Error { | ||
fn new<S, P: AsRef<Path>>(e: S, path: P) -> Error |
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.
Pre-existing, but this would be better taking P: Into<PathBuf>
instead which avoids an unnecessary allocation if passing a PathBuf
.
/// Maintains a mapping of local crate `DefId`s to the fully qualified name | ||
/// and "short type description" of that node. This is used when generating | ||
/// URLs when a type is being linked to. External paths are not located in | ||
/// this map because the `External` type itself has all the information | ||
/// necessary. | ||
pub paths: FxHashMap<DefId, (Vec<String>, ItemType)>, |
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.
Pre-existing, but would it be better to use LocalDefId
if these are only for the current crate?
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.
Probably, although it's kind of convenient that all the mappings in Cache
use a full DefId
. Otherwise I think you'd need to add checks that a given item is local before pulling out it's LocalDefId
and looking it up in those maps.
/// Maps a type ID to all known implementations for that type. This is only | ||
/// recognized for intra-crate `ResolvedPath` types, and is used to print | ||
/// out extra documentation on the page of an enum/struct. | ||
/// | ||
/// The values of the map are a list of implementations and documentation | ||
/// found on that implementation. | ||
pub impls: FxHashMap<DefId, Vec<Impl>>, |
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.
Do you know if this includes types from other crates as well?
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.
Nope, don't see std or other types in there unless i'm reexporting them. It does have the numeric primitives + char and bool but I assume that's either from the prelude or just because they're special.
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.
Got it. In general, if it doesn't have types from other crates it should use LocalDefId
but that can be delayed to a later PR.
parent: Option<DefId>, | ||
parent_idx: Option<usize>, | ||
search_type: Option<IndexItemFunctionType>, | ||
pub struct IndexItem { |
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.
If you make this fully pub
, rustc won't warn about dead code.
pub struct IndexItem { | |
pub(crate) struct IndexItem { |
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.
Can't restrict it since it's exposed through Cache
stripped_mod: bool, | ||
masked_crates: FxHashSet<CrateNum>, | ||
|
||
pub search_index: Vec<IndexItem>, |
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 looks like there is both a formats::cache
and a html::render::cache
. Maybe this belongs with render
? I don't see why backends other than HTML would need a JS search index.
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 it would definitely be better to have search_index
in html::render::SharedContext
but it requires a bit of work to separate out the logic to construct the index vs the cache because they're currently using the same DocFolder
pass.
@@ -361,7 +280,7 @@ impl Serialize for Generic { | |||
|
|||
/// Full type of functions/methods in the search index. | |||
#[derive(Debug)] | |||
struct IndexItemFunctionType { | |||
pub struct IndexItemFunctionType { |
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.
pub struct IndexItemFunctionType { | |
pub(crate) struct IndexItemFunctionType { |
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.
This one gets exposed by the cache so it's got to stay public (until we can move search index related stuff to html::render::SharedContext
)
📌 Commit cee8023 has been approved by |
⌛ Testing commit cee8023 with merge f1be9a90a04ae76a2798a3d0999fa651100289ce... |
💔 Test failed - checks-actions |
A bajillion test failures of the form:
|
@bors r+ |
📌 Commit 29df050 has been approved by |
@bors rollup=iffy This will cause lots of conflicts if it tries to merge at the same time as another rustdoc PR. |
@jyn514 rollups already ignore PRs that have merge conflicts when creating them |
☀️ Test successful - checks-actions, checks-azure |
This PR moves several types out of the librustdoc::html module so that they can be used by a future json backend. These changes are a re-implementation of some work done 6 months ago by @GuillaumeGomez. I'm currently working on said json backend and will put up an RFC soon with the proposed implementation.
There are a couple of changes that are more substantial than relocating structs to a different module:
Cache
is no longer part of thehtml::render::Context
type and therefor it needs to be explicitly passed to any functions that access it.html::render::run
has been rewritten to use theFormatRenderer
trait which should allow different backends to re-use the driving code.r? @GuillaumeGomez
cc @tmandry @betamos