Fix primitive retrieval in search index generation

[GuillaumeGomez]

Part of #60485. Fixes #74780.

Before merging, I have a few questions remaining:

Should we remove the primitive_locations field from the Cache type? If so, we'll have to replace in the few places where we use this field (not really a problem). However, this field includes the primitive types of the current crates, whereas my new implementation only includes the ones coming from external crates. I'm not sure if it'll be an issue for libcore or not (maybe not since they can be retrieved directly inside the crate, no?).

EDIT: I removed the primitive_locations field from the Cache type, so now we're only referring/using the new "primitives cache" added by this PR.

cc @rust-lang/rustdoc

r? @Manishearth

[jyn514]

Should we remove the primitive_locations field from the Cache type?

I think it's better not to duplicate it in multiple places, yeah.

However, this field includes the primitive types of the current crates, whereas my new implementation only includes the ones coming from external crates.

Is that the case? I see that this runs in impl Clean for CrateNum - won't external crates also be cleaned? Or is the ordering wrong and for this to work we need to have all the primitives before finishing the first crate?

[GuillaumeGomez]

Oh crap! I forgot to clean up stuff. >< I was too focused on my questions thing...

[Manishearth]

Now that this is no longer filling in any fields on clean::ExternalCrate I would like to move its initialization out of clean entirely. Can we write a function that takes tcx, runs cx.tcx.crates().iter().... and populates this struct, and then calls it right before clean::krate()?

Eventually (not in this PR) i'd like to move this and the cache as fields on context objects so that we don't have as many statics.

[jyn514]

---- [rustdoc] rustdoc/tuples.rs stdout ----
status: exit code: 1
 stderr:
------------------------------------------
thread 'rustc' panicked at 'no entry found for key', src/librustdoc/html/format.rs:579:33
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Looks like the cache might not be populated soon enough?

[Manishearth]

Yeah that's another reason to just lift it out of clean entirely.

I suspect that bug is because of libcore using primitives in functions and libstd hasn't been cleaned yet.

[bors]

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

[GuillaumeGomez]

I'm completely unable to understand why caching the primitive sooner prevents rustdoc to find primitive types implementations, meaning that for example, it cannot find f32::is_nan. If anyone has an idea...

[bors]

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

[crlf0710]

CI is red and there's merge conflict... And let me try ping @eddyb to see if he's got an idea about the problem here.

[camelid]

Are there any updates? It's been 3 months. I know eddyb tends to be very busy, so is there someone else who can help with this?

[jyn514]

This needs someone to put in the time debugging why it's broken.

@GuillaumeGomez do you know if PRIMITIVES has the same contents now as it did before? Like does it contain u8 after you initialize, before you call clean::krate?

[GuillaumeGomez]

iirc, it doesn't contain anything. I'll try to get back to this PR soon.

[jyn514]

I'm completely unable to understand why caching the primitive sooner prevents rustdoc to find primitive types implementations, meaning that for example, it cannot find f32::is_nan.

Can you expand on this more? What code is currently responsible for finding those primitive impls?

[GuillaumeGomez]

But "the impl" I meant the source. Apparently, changing the moment when we store them prevents to have access to this information. Also, I don't remember that the primitive types have a special implementation to retrieve this information. However, with all the recent changes, maybe it'll be possible to improve this part too. Like said a month ago, I'll try to get back to this PR some day haha.

[GuillaumeGomez]

Replaced by #81557.