-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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: collect trait impls as an early pass #53162
rustdoc: collect trait impls as an early pass #53162
Conversation
r? @rust-lang/rustdoc |
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 |
❤️ ❌ 💯 |
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 |
Ohhhhhh boy, i broke a lot of things. Back to the drawing board... EDIT: Okay, let's try to break down what assumptions i broke, based on what tests failed and how...
|
Can't wait for you to finish this! :) |
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 |
0892a85
to
e28e643
Compare
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 |
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 |
Pushed a new commit that (at least locally) should fix the issue that caused linkchecker to fail. Let's see if this works... A possible refactor that i'd like to do, but which may be out of scope for this PR by now, is to move the trait impls to a different list instead of piling them into the root of the crate. This echoes what the HIR already does, since that's the list we're using to extract local impls here. |
let (trait_items, generics) = if let Some(nodeid) = tcx.hir.as_local_node_id(did) { | ||
match tcx.hir.expect_item(nodeid).node { | ||
hir::ItemKind::Impl(.., ref gen, _, _, ref item_ids) => { | ||
( |
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.
Super weird indent, didn't understand at first what I was reading haha.
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 a good way to do something like this, though? The first item of the tuple is too long to just fit on one line.
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.
No, it's fine as is. Just wanted to comment on it though.
src/librustdoc/passes/mod.rs
Outdated
return None; | ||
} | ||
} | ||
if let Some(generics) = imp.trait_.as_ref().and_then(|t| t.generics()) { | ||
for typaram in generics { | ||
if let Some(did) = typaram.def_id() { | ||
if did.is_local() && !self.retained.contains(&did) { | ||
debug!("ImplStripper: stripped item in trait's generics; \ | ||
removing 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.
Bad indent.
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.
What's the proper way to indent this, then? The string is too long to fit on one line.
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.
The content of the string should be after the "
:
"long
string"
// and not:
"long
string"
@@ -8,6 +8,8 @@ | |||
// option. This file may not be copied, modified, or distributed | |||
// except according to those terms. | |||
|
|||
// ignore-stage1 |
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.
👍 👍 👍 👍
@@ -0,0 +1,28 @@ | |||
// Copyright 2012-2013 The Rust Project Developers. See the COPYRIGHT |
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 think date can be changed.
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.
Oops, that's what i get for copying headers blindly. 😅
With the tests it's now all good for me. r=me once CI is green. |
Travis is green! @bors r=GuillaumeGomez |
📌 Commit 74b9f1fd57106730883e0e6a810efed341543cf3 has been approved by |
Why is this being done as a pass? |
constraints: - clean/inline.rs needs this map to fill in traits when inlining - fold.rs needs this map to allow passes to fold trait items - html/render.rs needs this map to seed the Cache.traits map of all known traits The first two are the real problem, since `DocFolder` only operates on `clean::Crate` but `clean/inline.rs` only sees the `DocContext`. The introduction of early passes means that these two now exist at the same time, so they need to share ownership of the map. Even better, the use of `Crate` in a rustc thread pool means that it needs to be Sync, so it can't use `Lrc<Lock>` to manually activate thread-safety. `parking_lot` is reused from elsewhere in the tree to allow use of its `ReentrantMutex`, as the relevant parts of rustdoc are still single-threaded and this allows for easier use in that context.
ec86a73
to
1106577
Compare
🔥 😡 lockfiles 😡 🔥 Going to wait for travis again to make sure i didn't accidentally break the build. The next couple PRs in the queue don't modify the lockfile, so with that last priority bump this should hopefully not have to deal with this again? |
@bors r=GuillaumeGomez |
📌 Commit 1106577 has been approved by |
⌛ Testing commit 1106577 with merge 1a42b7dceeed1195c1599995bcda32f99739e68b... |
Your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem. 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 |
💔 Test failed - status-travis |
…=GuillaumeGomez rustdoc: collect trait impls as an early pass Fixes #52545, fixes #41480, fixes #36922 Right now, rustdoc pulls all its impl information by scanning a crate's HIR for any items it finds. However, it doesn't recurse into anything other than modules, preventing it from seeing trait impls that may be inside things like functions or consts. Thanks to #53002, now these items actually *exist* for rustdoc to see, but they still weren't getting collected for display. But there was a secret. Whenever we pull in an item from another crate, we don't have any of its impls in the local HIR, so instead we ask the compiler for *everything* and filter out after the fact. This process is only triggered if there's a cross-crate re-export in the crate being documented, which can sometimes leave this info out of the docs. This PR instead moves this collection into an early pass, which occurs immediately after crate cleaning, so that that collection occurs regardless. In addition, by including the HIR's own `trait_impls` in addition to the existing `all_trait_implementations` calls, we can collect all these tricky trait impls without having to scan for them!
☀️ Test successful - status-appveyor, status-travis |
Fixes #52545, fixes #41480, fixes #36922
Right now, rustdoc pulls all its impl information by scanning a crate's HIR for any items it finds. However, it doesn't recurse into anything other than modules, preventing it from seeing trait impls that may be inside things like functions or consts. Thanks to #53002, now these items actually exist for rustdoc to see, but they still weren't getting collected for display.
But there was a secret. Whenever we pull in an item from another crate, we don't have any of its impls in the local HIR, so instead we ask the compiler for everything and filter out after the fact. This process is only triggered if there's a cross-crate re-export in the crate being documented, which can sometimes leave this info out of the docs. This PR instead moves this collection into an early pass, which occurs immediately after crate cleaning, so that that collection occurs regardless. In addition, by including the HIR's own
trait_impls
in addition to the existingall_trait_implementations
calls, we can collect all these tricky trait impls without having to scan for them!