save-analysis: use a decoupled representation for dumped data

[aochagavia]

Closes#33348

This will probably break any tool relying on the csv backend of save_analysis, for the following reasons:

1. Dumped spans don't contain extents anymore (Dump uses SpanData now instead of internal Spans). In case we still want to dump extents we could add them to SpanData.
2. DefIds are no longer dumped as a pair of (ref_id, ref_crate). Instead, they are dumped as a single Id.

@nrc You said something about storing the id in a u64, but you didn't explain why. I kept using u32 in this branch but I can change it if you prefer that.

r? @nrc

By the way, the fact that this breaks tools relying on CSV may be a good occasion to start dumping CSV in a different way (i.e. using the serializer like in the JSON backend).

[nrc]

@bors: r+

[bors]

📌 Commit dca29d7 has been approved by nrc

[nrc]

@bors: r-

[nrc]

@aochagavia so I was thinking some more about ids, and I think what I started and which is continued here is bogus.

By using the index from the def_id and ignoring the crate num, we could have duplicate ids where two items have the same index, but are in different crates. My plan was to fix that by using a u64, where the low 32 bits would be the index and the high would be the crate num, but this doesn't work as an actual id - the client still has to do some work to convert local ids (i.e., those with crate num = 0) into non-local ones and to normalise crate numbers between crates. I feel like this is less obvious in a single id field, rather than having two fields for a def id, i.e., we're getting worse, not better. As far as I can see, there is no way to do this normalisation in the compiler and we must leave it to the client.

Sorry I didn't think of this earlier.

[aochagavia]

@nrc so the crux of the problem is normalizing crate numbers between crates. However, if the compiler itself doesn't have enough information to do it, how can we expect the clients to do it?

[nrc]

@aochagavia Once a tool has the crate dump for every crate, then a tool has all the info it needs to do the normalisation (this is what DXR does). The problem for the compiler is that it only has information on the current crate (and sort of earlier crates), but not any crates being compiler later.

Did you see my PR against this PR? https://github.com/aochagavia/rust/pull/1

[aochagavia]

@nrc I just merged your PR :)

[nrc]

@bors: r+

[bors]

📌 Commit 192e336 has been approved by nrc

[bors]

⌛ Testing commit 192e336 with merge 72cfc12...

[bors]

💔 Test failed - auto-win-msvc-64-opt

[nrc]

@bors: retry