Uh oh!
There was an error while loading. Please reload this page.
Get rid of fake DefIds in rustdoc - #84707
Conversation
f63da48 to
b5293a5Compare
This comment has been minimized.
This comment has been minimized.
camelid
commented
Apr 29, 2021
Wow, thank you for working on this! |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
jyn514
left a comment
There was a problem hiding this comment.
Only got about halfway through the changes - the bit about contains_key also applies to lots of other changes.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Can't these be fake for blanket impls?
There was a problem hiding this comment.
pubtraitA{}pubtraitB{}impl<T:B>AforT{}I don't know, but this documents just fine
There was a problem hiding this comment.
This isn't the same behavior - before contains_key would return false for fakes. I have a feeling this will ICE.
There was a problem hiding this comment.
Should paths also accept fake ids, or should we just check if it's real and only then insert it?
There was a problem hiding this comment.
Given that this didn't ICE documenting libstd, I'm ok with just leaving it as-is.
There was a problem hiding this comment.
Hmm, it seems odd to me this would be real - can't rustdoc generate links to impls? Or is that only intra-doc links?
jyn514
commented
May 1, 2021
@Stupremee I didn't realize when reviewing that the test suite was passing - that's probably a better indicator of what's correct than my guessing. Can you document the standard library and make sure there's no panics? And then rebase this? |
Stupremee
commented
May 1, 2021
|
6621591 to
5a3f9c4CompareStupremee
commented
May 1, 2021
Everything should be ready now 🎉 |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
camelid
commented
May 1, 2021
@bors rollup=never This should make it easier to bisect if we get ICE reports. |
bors
commented
May 3, 2021
☔ The latest upstream changes (presumably #84840) made this pull request unmergeable. Please resolve the merge conflicts. |
327262e to
d3274e3CompareStupremee
commented
May 4, 2021
Should be ready to merge now. Would be good to merge soon so there are not too many conflicts coming and not too many PRs that need to be rebased on this one. r? @jyn514 |
jyn514
commented
May 4, 2021
I'd like to figure out #84707 (comment) first, I don't like merging code when I don't understand how it works. @Manishearth@GuillaumeGomez@Aaron1011 maybe one of you have ideas? |
Uh oh!
There was an error while loading. Please reload this page.
jyn514
commented
May 4, 2021
r=me with Guillaume's comment addressed, this already showing I don't have a good intuition for which ids are fake and which aren't 😆 so it's super helpful! |
Stupremee
commented
May 4, 2021
In the future someone could even do a follow up PR and try to minimize the amount of fake DefId's. I might even do that now when renaming everything. |
Manishearth
commented
May 4, 2021
That's fair. To be clear, "the renaming" is creating a FakeDefId wrapper and using it everywhere, right? As I said I'm against having |
Stupremee
commented
May 4, 2021
Yes. Thats what I pushed right now. Use |
GuillaumeGomez
left a comment
There was a problem hiding this comment.
Looks good to me now, thanks!
GuillaumeGomez
commented
May 4, 2021
We'll now be waiting for the follow-up PRs. ;) @bors: r=jyn514,GuillaumeGomez |
bors
commented
May 4, 2021
📌 Commit b6120bf has been approved by |
bors
commented
May 4, 2021
bors
commented
May 4, 2021
☀️ Test successful - checks-actions |
…efids, r=jyn514,GuillaumeGomez Minimize amount of fake `DefId`s used in rustdoc Follow up from rust-lang#84707, which minimizes the amount of fake defids to the smallest amount possible. Every `FakeDefId` that is now used in the rustdoc library must be preserved and can not be replaced with a normal `DefId`.
…efids, r=jyn514,GuillaumeGomez Minimize amount of fake `DefId`s used in rustdoc Follow up from rust-lang#84707, which minimizes the amount of fake defids to the smallest amount possible. Every `FakeDefId` that is now used in the rustdoc library must be preserved and can not be replaced with a normal `DefId`.
…efids, r=jyn514,GuillaumeGomez Minimize amount of fake `DefId`s used in rustdoc Follow up from rust-lang#84707, which minimizes the amount of fake defids to the smallest amount possible. Every `FakeDefId` that is now used in the rustdoc library must be preserved and can not be replaced with a normal `DefId`.
…lang#82465. (update: placated tidy) (update: rebased post PR rust-lang#84707 ) merge me
…lang#82465. (update: placated tidy) (update: rebased post PR rust-lang#84707 ) merge me
…mid, r=jyn514 rustdoc: Replace `FakeDefId` with new `ItemId` type Follow up from rust-lang#84707 `@Manishearth` [suggested](rust-lang#84707 (comment)) that there should be a new `ItemId` type that can distinguish between auto traits, normal ids, and blanket impls instead of using `FakeDefId`s. This type is introduced by this PR. There are still some `FIXME`s left, because I was unsure what the best solution for them would be. Especially the naming in general now is a bit weird right now and needs to be cleaned up. Now there are no "fake" ids so the `is_fake` method on `Item` does not really make sense and maybe the methods on `ItemId` should be renamed too? Also, we need to represent the new item ids in the JSON backend somehow.
Right now there are many errors left, but I wanted to show the current state since all that is left to do is fixing the errors.
Resolves#83183
r? @jyn514