save-analysis: use a decoupled representation for dumped data #33370
Conversation
|
@bors: r+ |
|
📌 Commit dca29d7 has been approved by |
|
@bors: r- |
|
@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. |
|
@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? |
|
@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 |
Save ids fix
|
@nrc I just merged your PR :) |
|
@bors: r+ |
|
📌 Commit 192e336 has been approved by |
|
⌛ Testing commit 192e336 with merge 72cfc12... |
|
💔 Test failed - auto-win-msvc-64-opt |
|
@bors: retry |
save-analysis: use a decoupled representation for dumped data Closes rust-lang#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 `Span`s). In case we still want to dump extents we could add them to `SpanData`. 1. `DefId`s 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).
save-analysis: use a decoupled representation for dumped data Closes rust-lang#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 `Span`s). In case we still want to dump extents we could add them to `SpanData`. 1. `DefId`s 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).
save-analysis: use a decoupled representation for dumped data Closes rust-lang#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 `Span`s). In case we still want to dump extents we could add them to `SpanData`. 1. `DefId`s 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).
Closes #33348
This will probably break any tool relying on the csv backend of save_analysis, for the following reasons:
DumpusesSpanDatanow instead of internalSpans). In case we still want to dump extents we could add them toSpanData.DefIds are no longer dumped as a pair of(ref_id, ref_crate). Instead, they are dumped as a singleId.@nrc You said something about storing the id in a
u64, but you didn't explain why. I kept usingu32in 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).