errors: dedup same compiler errors, present them in deterministic order - #413
Conversation
c34d7a2 to
5c88010
Compare
| #[derive(Debug, Clone, Default)] | ||
| struct DiagnosticIndex { | ||
| identities: HashSet<String>, | ||
| source_order: HashMap<usize, usize>, |
There was a problem hiding this comment.
In this case BTreeMap will be more optimized than HashMap
| source_order: HashMap<usize, usize>, | |
| source_order: BTreeMap<usize, usize>, |
There was a problem hiding this comment.
I'm skeptical. We can't make use of the BTreeMap's ordering since the actual presentation order depends on source_rank which uses data outside of the map. So it's a question of whether tree-rebalancing operations are cheaper than siphash operations.
If we are really concerned we can use a custom hasher which just casts the usizes to u64s, and that will definitely be faster than either approach.
In practice I think it doesn't matter at all, and HashMap (a) has a more full-featured API, and (b) communicates to the reader of the code that the order doesn't matter.
There was a problem hiding this comment.
Okay then, let's just leave HashMap
LesterEvSe
left a comment
LesterEvSe
left a comment
There was a problem hiding this comment.
ACK 5c88010; tested locally with just check and just check_fuzz
3 participants
The PR is meant to make the reported order of errors deterministic and deduplicated to improve UX