[isHeSatoshi]

Fixes #1285.

The chapter says that try_mark_green re-runs a query from a dep node, and the query modifiers section says no_force prevents "forcing" a node "even if the query's key type is recoverable", but neither term is explained anywhere. This adds a section covering both, placed just before the modifiers section so the no_force bullet can point at it.

What the section says

• Re-running a query from its dep node is called forcing; the real entry point is TyCtxt::try_force_from_dep_node, and the pseudocode calls it run_query_for.
• Forcing cannot always work: a DepNode is a DepKind plus a key fingerprint, which is a stable hash, and the persisted dep graph stores nodes but not the keys they were built from.
• Failure is expected and safe: try_mark_green returns None, and the root query is re-evaluated. That costs reuse, not correctness.
• KeyFingerprintStyle and its four values, the key types that are recoverable and how, and that returning None is always allowed.

On the issue's specifics

The issue says recovery is "currently only possible when the query ID can be mapped to a DefPathHash (this is the case for CrateNum, LocalDefId, and DefId)". That was written in January 2022 and is now incomplete in two ways, so the section reflects the current code rather than the issue text:

• More key types. OwnerId, ModId and LocalModId are recoverable too. (DefId, DefId) is explicitly Opaque.
• A second mechanism. HirId has its own KeyFingerprintStyle::HirId, recovered by splitting the fingerprint back into a DefPathHash local hash and an ItemLocalId. So a DefPathHash is no longer the only route back to a key. KeyFingerprintStyle::Unit covers keys that are () or equivalent.

Where the claims come from

Read out of rust-lang/rust on master rather than recalled:

• compiler/rustc_middle/src/dep_graph/mod.rs: the KeyFingerprintStyle enum, its per-variant doc comments, and is_maybe_recoverable.
• compiler/rustc_middle/src/dep_graph/dep_node_key.rs: the DepNodeKey trait, the blanket Opaque implementation, and each concrete try_recover_key, including HirId's fingerprint split.
• compiler/rustc_middle/src/dep_graph/dep_node.rs: the design comment on force_from_dep_node_fn explaining why forcing is expected to fail from time to time and that try_mark_green failing is how that is handled.
• compiler/rustc_middle/src/dep_graph/graph.rs: try_mark_green calling try_force_from_dep_node and returning None when it fails.
• compiler/rustc_query_impl/src/execution.rs: force_query_dep_node returning false when try_recover_key yields None.

Checks

• The three rustdoc links added return HTTP 200, and the two method links use the #tymethod. anchors that exist on the DepNodeKey page.
• RUSTC_BOOTSTRAP=1 cargo run --release --manifest-path ci/sembr/Cargo.toml src reports the file as compliant.
• Both in-page anchors resolve: #forcing-dep-nodes-and-recovering-query-keys and #query-modifiers.

[rustbot]

Thanks for the PR. If you have write access, feel free to merge this PR if it does not need reviews. You can request a review using r? rustc-dev-guide or r? <username>.