Fix rustdoc handling of primitive items

[jyn514]

This is a complicated PR and does a lot of things. I'm willing to split it up a little more if it would help reviewing, but it would be tricky and I'd rather not unless it's necessary.

What does this do?

• Fixes no_std crates do not link to primitives #73423.
• Fixes [intra-doc-links] primitives inconsistently point offline or online in std docs #79630. I'm not sure how to test this for the standard library explicitly, but you can see from some of the diffs from the no_std tests. I also tested it locally and it works correctly:
• Fixes rustdoc: Can't use anchors in links to primitive types #83083.

Why are these changes interconnected?

• Allowing anchors (rustdoc: Can't use anchors in links to primitive types #83083) without fixing the online/offline problem ([intra-doc-links] primitives inconsistently point offline or online in std docs #79630) will actually just silently discard the anchors, that's not a fix. The online/offline problem is directly related to the fragment hack; links need to go through fn href() to be fixed.
• Technically I could fix the online/offline problem without removing the error on anchors; I am willing to separate that out if it would be helpful for reviewing. However I can't fix the anchor problem without adding docs to core, since rustdoc needs all those primitives to have docs to avoid a fallback, and currently #![no_std] crates don't have docs for primitives. I also can't fix the online/offline problem without removing the fragment hack, since otherwise diffs like this will be wrong for some primitives but not others:

@@ -385,7 +381,7 @@ fn resolve_primitive_associated_item(
                         ty::AssocKind::Const => "associatedconstant",
                         ty::AssocKind::Type => "associatedtype",
                     };
-                    let fragment = format!("{}#{}.{}", prim_ty.as_sym(), out, item_name);
+                    let fragment = format!("{}.{}", out, item_name);
                     (Res::Primitive(prim_ty), fragment, Some((kind.as_def_kind(), item.def_id)))
                 })
         })

• Adding primitive docs to core without making any other change will cause links to go to core instead of std, even for crates with extern crate std. See "Breaking changes to doc(primitive)" below for why this is the case. That said, I could add some special casing to rustdoc at the same time that would let me separate this change from the others (it would fix no_std crates do not link to primitives #73423 but still special-case intra-doc links). I'm willing to separate that out if helpful for reviewing.

Add primitive documentation to libcore

This works by reusing the same include!("primitive_docs.rs") file in both core and std, and then special-casing links in core to use relative links instead of intra-doc links. This doesn't use purely intra-doc links because some of the primitive docs links to items only in std; this doesn't use purely relative links because that introduces new broken links when the docs are re-exported (e.g. String's &str deref impl, or Vec's slice deref impl).

Note that this copies the whole file to core, to avoid anyone compiling core to have to set CARGO_PKG_NAME. See https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/Who.20should.20review.20changes.20to.20linkchecker.3F/near/249939598 for more context. It also adds a tidy check to make sure the two files are kept in sync.

Fix inconsistent online/offline primitive docs

This does four things:

• Records modules with doc(primitive) in cache.external_paths. This is necessary for href() to find them later.
• Makes cache.primitive_locations available to the intra-doc link pass, by refactoring out a PrimitiveType::primitive_locations function that only uses TyCtxt.
• Special cases modules with doc(primitive) to be treated as always public for the purpose of links.
• Removes the fragment hack. cc @notriddle, I know you added some comments about this in the code (thank you for that!)

Breaking changes to doc(primitive)

"Breaking" is a little misleading here - these are changes in behavior, none of them will cause code to fail to compile.

Let me preface this by saying I think stabilizing doc(primitive) was a uniquely terrible idea. As far as I can tell, it was stabilized by oversight; it's been stable since 1.0. No one should have need to use it except the standard library, and a crater run shows that in fact no one is using it: #87050 (comment). I hope to actually make doc(primitive) a no-op unless you opt-in with a nightly feature, which will keep crates compiling without forcing rustdoc into trying to keep somewhat arbitrary behavior guarantees; but for now, this just subtly changes some of the behavior if you use doc(primitive) in a dependency.

That said, here are the changes:

• Refactoring out primitive_locations() is technically a change in behavior, since it no longer looks for primitives in crates that were passed through --extern, but not used by the crate; however, that seems like such an unlikely edge case it's not worth dealing with.
• The precedence given to primitive locations is no longer just arbitrary, it can also be inconsistent from run to run. Let me explain that more: previously, primitive locations were sorted by the CrateNum; the comment on that sort said "Favor linking to as local extern as possible, so iterate all crates in reverse topological order." Unfortunately, that's not actually what CrateNum tracks: it measures the order crates are loaded, not the number of intermediate crates between that dependency and the root crate. It happened to work as intended before because the compiler injects extern crate std; at the top of every crate, which ensured it would have the first CrateNum other than the current, but every other CrateNum was completely arbitrary (for example, core often had a later CrateNum than std). This now removes the sort on CrateNum completely and special-cases core instead. In particular, if you depend on both std and a crate which defines a doc(primitive) module, it's arbitrary whether rustdoc will use the docs from std or the ones from the other crate. cc @alexcrichton, you wrote this originally.

cc @rust-lang/rustdoc
cc @rust-lang/libs for the addition to core (the commit you're interested in is 91346c8)

[rust-highfive]

r? @CraftSpider

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

[alexcrichton]

cc @alexcrichton, you wrote this originally

Sorry, I don't really remember anything in this area so I don't think I'll be of much help

[jyn514]

@alexcrichton no worries, I got it working with roughly the same behavior :)

[GuillaumeGomez]

Are we sure we always have all the primitives? I guess unless new primitives are added we're fine, but I'm still feeling a bit uneasy... Well, not a blocker in any case.

[jyn514]

I can go through them one by one this afternoon, but they should all be there now that primitives are documented in core. This will cause an ICE if you use no_core and try to link to a primitive, but no_core isn't really supported anyway.

[bors]

📌 Commit 9ec79b92fcdd9679b61b6eae59372cab47b3cf4e has been approved by GuillaumeGomez,jyn514

[jyn514]

@bors r=GuillaumeGomez,jyn514

[bors]

📌 Commit 86fd250 has been approved by GuillaumeGomez,jyn514

[bors]

⌛ Testing commit 86fd250 with merge 0273e3b...

[bors]

☀️ Test successful - checks-actions
Approved by: GuillaumeGomez,jyn514
Pushing 0273e3b to master...

[rust-timer]

Finished benchmarking commit (0273e3b): comparison url.

Summary: This benchmark run did not return any relevant changes.

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression