rustdoc: Replace FakeDefId with new ItemId type

[Stupremee]

Follow up from #84707

@Manishearth suggested that there should be a new ItemId type that can distinguish between auto traits, normal ids, and blanket impls instead of using FakeDefIds.

This type is introduced by this PR.

There are still some FIXMEs 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.

[rust-highfive]

r? @GuillaumeGomez

(rust-highfive has picked a reviewer for you, use r? to override)

[jyn514]

r? @jyn514

[Manishearth]

I like this a lot, thanks for doing this! I don't really have any feedback that hasn't been brought up already aside from the boxing thing

[jyn514]

r? @CraftSpider - this looks great other than the JSON IDs. I'm fine with reverting the "Box ImplId" commit.

[Stupremee]

This should be ready now!

r? @CraftSpider

[jyn514]

Sorry, I was unclear: you don't need for_ at all now, you can reconstruct it from the impl_id alone with tcx.impl_trait_ref(impl_def_id).unwrap().self_ty().

Suggested change

	def_id: ItemId::Blanket { impl_id: impl_def_id, for_: item_def_id },
	def_id: ItemId::Blanket { impl_def_id, },

[Stupremee]

Yes, I do need it, because apparently, only the implementation id is not enough to be unique (?????????).
When I only had the impl_id, I got a panic when documenting std that assert_eq on these two failed:

  left: `Item { id: Id("b:0:2454"), crate_id: 0, name: None, span: Some(Span { filename: "library/core/src/borrow.rs", begin: (208, 0), end: (213, 1) }), visibility: Default, docs: None, links: {}, attrs: [], deprecation: None, inner: Impl(Impl { is_unsafe: false, generics: Generics { params: [GenericParamDef { name: "T", kind: Type { bounds: [], default: None } }], where_predicates: [BoundPredicate { ty: Generic("T"), bounds: [TraitBound { trait_: ResolvedPath { name: "Sized", id: Id("0:2854"), args: Some(AngleBracketed { args: [], bindings: [] }), param_names: [] }, generic_params: [], modifier: Maybe }] }] }, provided_trait_methods: [], trait_: Some(ResolvedPath { name: "Borrow", id: Id("0:2448"), args: Some(AngleBracketed { args: [Type(Generic("T"))], bindings: [] }), param_names: [] }), for_: ResolvedPath { name: "Wrapping", id: Id("0:24138"), args: Some(AngleBracketed { args: [Type(Generic("T"))], bindings: [] }), param_names: [] }, items: [Id("0:2456")], negative: false, synthetic: false, blanket_impl: Some(Generic("T")) }) }`,
 right: `Item { id: Id("b:0:2454"), crate_id: 0, name: None, span: Some(Span { filename: "library/core/src/borrow.rs", begin: (208, 0), end: (213, 1) }), visibility: Default, docs: None, links: {}, attrs: [], deprecation: None, inner: Impl(Impl { is_unsafe: false, generics: Generics { params: [GenericParamDef { name: "T", kind: Type { bounds: [], default: None } }], where_predicates: [BoundPredicate { ty: Generic("T"), bounds: [TraitBound { trait_: ResolvedPath { name: "Sized", id: Id("0:2854"), args: Some(AngleBracketed { args: [], bindings: [] }), param_names: [] }, generic_params: [], modifier: Maybe }] }] }, provided_trait_methods: [], trait_: Some(ResolvedPath { name: "Borrow", id: Id("0:2448"), args: Some(AngleBracketed { args: [Type(Generic("T"))], bindings: [] }), param_names: [] }), for_: ResolvedPath { name: "ParseFloatError", id: Id("0:23084"), args: Some(AngleBracketed { args: [], bindings: [] }), param_names: [] }, items: [Id("0:2456")], negative: false, synthetic: false, blanket_impl: Some(Generic("T")) }) }`', src/librustdoc/json/mod.rs:179:17

[jyn514]

... @CraftSpider why are those separate? I would only expect there to be one item per blanket impl, generating a separate item for every type it could apply to seems both inefficient and not particularly useful.

[CraftSpider]

I have no clue, I'd expect the same. I'll look into the code tomorrow.
First guess: the equivalent of HTML's 'implements' showing blankets that apply to that type

[Stupremee]

Should we wait with this PR until you found a solution? We can also merge this now and make a follow up PR.

[jyn514]

Hmm, yeah this seems fine in the meantime. r=me once you fix the conflict.

[CraftSpider]

Agree with Josh, this isn't a blocking concern.

[Stupremee]

Alright. @CraftSpider will you open the follow-up PR with the fix for not emitting duplicate blanket implementations and the fixed ItemId?

[bors]

☔ The latest upstream changes (presumably #86282) made this pull request unmergeable. Please resolve the merge conflicts.

[Stupremee]

r? @jyn514

[jyn514]

@bors r+

[bors]

📌 Commit a89912c has been approved by jyn514

[bors]

⌛ Testing commit a89912c with merge 9a27044...

[bors]

☀️ Test successful - checks-actions
Approved by: jyn514
Pushing 9a27044 to master...