LinkedGraph: support adding nodes and edges in arbitrary order

[petrochenkov]

If an edge uses some not-yet-known node, we just leave the node's data empty, that data can be added later.

Use this support to avoid skipping edges in RetainedDepGraph.

This is continuation of #152590, that PR just fixes the ICE, this PR also preserves all the edges in debug dumps.
This is also a minimized version of #151821 with a smaller amount of data structure hacks.

[rustbot]

r? @wesleywiser

rustbot has assigned @wesleywiser.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 68 candidates
• Random selection from 15 candidates

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[petrochenkov]

Rebased on #152844.
@Zalathar perhaps you could review this? It's also a part of query system fixes / refactorings.

[Zalathar]

This looks a bit suspicious.

The more obvious implementation would be to skip data-less nodes. Is there a reason to think that nodes will always be densely initialized whenever this is called?

[petrochenkov]

The assumption is that the graph is used only when it's fully built (e.g. in assert_dep_graph/save_dep_graph).
The holes in data are supposed to occur only during the (parallel) graph building process.
If this ever changes, then it's better to fail with some noise than to silently lose nodes (like we are losing edges now).

[Zalathar]

Beyond the scope of this particular PR, but if LinkedGraph is only used by RetainedDepGraph and its use is otherwise discouraged, we should probably fully incorporate into RetainedDepGraph and get rid of it as a notionally-separate data structure.

[Zalathar]

r? me

[petrochenkov]

Beyond the scope of this particular PR, but if LinkedGraph is only used by RetainedDepGraph and its use is otherwise discouraged, we should probably fully incorporate into RetainedDepGraph and get rid of it as a notionally-separate data structure.

LinkedGraph is also used in rustc_infer/rustc_borrowck (RegionGraph).

[Zalathar]

If LinkedGraph is used in multiple places that don't all want this change, then it's a big layering violation, and I feel pretty uneasy about it.

[petrochenkov]

rustc_infer does want this (setting node data by index, not always at the end), it just can live without it unlike RetainedDepGraph.
See compiler/rustc_infer/src/infer/lexical_region_resolve/mod.rs in #151821.
And it also builds the whole graph before using it.
Although to look pretty it requires indexing the graph with arbitrary I: Idx instead of concrete NodeIndex, I didn't add it in this PR to keep the fix minimal.

[petrochenkov]

I don't think it's a layering violation, setting node data by index requires supporting None or equivalent in the graph itself.
Accesses to nodes with unset data are equivalent to e.g. out-of-bound accesses and should produce panics by default.

In this sense all_nodes is not a good API for the graph to use by default, since it exposes Nodes, which are mostly internal details. Something like all_node_datas would be better.
None of the graph users actually uses Nodes, technically they can be made private.

[Zalathar]

I looked into lexical_region_resolve and it doesn't appear to be using LinkedGraph in any essential way, so I opened #152621 to have it use its own simpler edge-index structure instead.