Uh oh!
There was an error while loading. Please reload this page.
rustdoc: collect trait impls as an early pass - #53162
Conversation
QuietMisdreavus
commented
Aug 7, 2018
r? @rust-lang/rustdoc |
rust-highfive
commented
Aug 7, 2018
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 |
sgrif
commented
Aug 7, 2018
❤️ ❌ 💯 |
rust-highfive
commented
Aug 7, 2018
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...
|
GuillaumeGomez
commented
Aug 8, 2018
Can't wait for you to finish this! :) |
rust-highfive
commented
Aug 14, 2018
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
e28e643Comparerust-highfive
commented
Aug 14, 2018
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 |
rust-highfive
commented
Aug 15, 2018
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 |
QuietMisdreavus
commented
Aug 21, 2018
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. |
There was a problem hiding this comment.
Super weird indent, didn't understand at first what I was reading haha.
There was a problem hiding this comment.
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.
No, it's fine as is. Just wanted to comment on it though.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
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.
The content of the string should be after the ":
"long
string"
// and not:
"long
string"
There was a problem hiding this comment.
I think date can be changed.
There was a problem hiding this comment.
Oops, that's what i get for copying headers blindly. 😅
GuillaumeGomez
commented
Aug 27, 2018
With the tests it's now all good for me. r=me once CI is green. |
QuietMisdreavus
commented
Aug 27, 2018
Travis is green! @bors r=GuillaumeGomez |
bors
commented
Aug 27, 2018
📌 Commit 74b9f1fd57106730883e0e6a810efed341543cf3 has been approved by |
ollie27
commented
Aug 27, 2018
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
1106577CompareQuietMisdreavus
commented
Sep 20, 2018
🔥 😡 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? |
QuietMisdreavus
commented
Sep 20, 2018
@bors r=GuillaumeGomez |
bors
commented
Sep 20, 2018
📌 Commit 1106577 has been approved by |
bors
commented
Sep 20, 2018
⌛ Testing commit 1106577 with merge 1a42b7dceeed1195c1599995bcda32f99739e68b... |
rust-highfive
commented
Sep 20, 2018
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 |
bors
commented
Sep 20, 2018
💔 Test failed - status-travis |
QuietMisdreavus
commented
Sep 20, 2018
bors
commented
Sep 20, 2018
…=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!
bors
commented
Sep 20, 2018
☀️ 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_implsin addition to the existingall_trait_implementationscalls, we can collect all these tricky trait impls without having to scan for them!