Make Instruction and all of its sub-structs both Hash and Eq:
Handle f64 equality as NaN == NaN which is defensible in the case of equating instructions
Handle IndexMap equality by relying on iteration order. This is suboptimal in that ordering shouldn't matter for equality checks, but sorting them would be expensive. This is where BTreeMap may actually make more sense, but that doesn't need to be addressed here. This was discussed in the past and I recall that there was a good reason not to select it, even if I forget that reason now.
TODO
right now, we just impl Eq for TypeX when it contains f64, which in effect will just cause a panic when one of those f64 is NaN. this should be better handled and possibly include a PartialEq override.
Make
Instruction
and all of its sub-structs bothHash
andEq
:NaN == NaN
which is defensible in the case of equating instructionsIndexMap
equality by relying on iteration order. This is suboptimal in that ordering shouldn't matter for equality checks, but sorting them would be expensive. This is whereBTreeMap
may actually make more sense, but that doesn't need to be addressed here. This was discussed in the past and I recall that there was a good reason not to select it, even if I forget that reason now.TODO
impl Eq for TypeX
when it containsf64
, which in effect will just cause a panic when one of thosef64
isNaN
. this should be better handled and possibly include aPartialEq
override.