Uh oh!
There was an error while loading. Please reload this page.
Sort bounds by DefPathHash during astconv - #83005
Conversation
rust-highfive
commented
Mar 11, 2021
r? @lcnr (rust-highfive has picked a reviewer for you, use r? to override) |
This comment has been minimized.
This comment has been minimized.
lcnr
commented
Mar 11, 2021
r=me after blessing the ui tests i've already had a similar bug in the past iirc, not sure if there's a way to prevent bugs like this from happening 🤔 |
I had opened #83006 to track removing the |
cc rust-lang#82920 The value of a `DefId` is not stable across compilation sessions. If we sort by `DefIds`, and then include the sorted list as part of a query result, then the query will no longer be a pure function of its input (e.g. the `DefId` can change while the `DefPathHash` remains the same). For reasons that are not yet clear, this issue lead to segfaults and garbage slice index values when the project in the linked issue was built with a particular incremental cache.
c5343eb to
9339982CompareAaron1011
commented
Mar 11, 2021
@bors r=lcnr |
bors
commented
Mar 11, 2021
📌 Commit 9339982 has been approved by |
Aaron1011
commented
Mar 11, 2021
This most general fix for this kind of issue is something like #83007. However, benchmarks currently show that the cost is extremely high. |
This comment has been minimized.
This comment has been minimized.
Aaron1011
commented
Mar 11, 2021
It looks like I'm getting different output locally. Did this somehow make the order less stable? |
Aaron1011
commented
Mar 11, 2021
@michaelwoerister You worked on |
Aaron1011
commented
Mar 11, 2021
@bors r- |
michaelwoerister
commented
Mar 12, 2021
Let me take a look ... |
| auto_traits.sort_by_key(|i| i.trait_ref().def_id()); | ||
| // Sort by `DefPathHash` so that the order is stable across compilation sessions | ||
| auto_traits.sort_by_key(|i| self.tcx().def_path_hash(i.trait_ref().def_id())); | ||
| auto_traits.dedup_by_key(|i| i.trait_ref().def_id()); |
There was a problem hiding this comment.
This is probably the reason for the test failures: dedup_by_key assumes that the Vec is sorted by the given key. So this should be auto_traits.dedup_by_key(|i| self.tcx().def_path_hash(i.trait_ref().def_id()));
Maybe it would make sense to use a rustc_data_structures::sorted_map::SortedMap here.
There was a problem hiding this comment.
Since def path hash equality implies that the DefIds are equal, I thought that deduplicating by DefId would still work, since equal DefIds should still be adjacent to each other.
There was a problem hiding this comment.
Also, the failure appears to be caused be re-ordered errors, not duplicated errors.
rust-log-analyzer
commented
Mar 12, 2021
The job Click to see the possible cause of the failure (guessed by this bot) |
Aaron1011
commented
Mar 12, 2021
After some further consideration, I don't think sorting by rust/compiler/rustc_interface/src/util.rs Lines 500 to 503 in b3e19a2 This is generated by Cargo from a large amount of information: https://github.com/rust-lang/cargo/blob/c4adfd553b7210d1aeb462d6d4b1dabfd2d0910e/src/cargo/core/compiler/context/compilation_files.rs#L489-L565 In particular, the name of the host platform is included: https://github.com/rust-lang/cargo/blob/c4adfd553b7210d1aeb462d6d4b1dabfd2d0910e/src/cargo/core/compiler/context/compilation_files.rs#L582-L585 This means that we'll get different This means that sorting by Instead, I think we should avoid sorting by both |
Aaron1011
commented
Mar 12, 2021
It turns out that the difference in ordering between my machine and the PR builder was caused by my local |
cjgillot
commented
Mar 12, 2021
The fact that we sort the vectors by |
The problem is that the value of a
The relevant query result is |
Aaron1011
commented
Mar 13, 2021
Closing in favor of #83074, which avoids the sorting alogether. |
cc #82920
The value of a
DefIdis not stable across compilation sessions. If wesort by
DefIds, and then include the sorted list as part of a queryresult, then the query will no longer be a pure function of its input
(e.g. the
DefIdcan change while theDefPathHashremains the same).For reasons that are not yet clear, this issue lead to segfaults and
garbage slice index values when the project in the linked issue was
built with a particular incremental cache.