Description
As explained here, a boolean-to-integer cast currently just forwards the BoolValue, so we can end up with BoolValues that are associated with expressions or locations of integer type.
As a result, joinDistinctValues() and widenDistinctValues() need to defensively check that both values they operate on are BoolValues. It also just seems wrong to associate a BoolValue with an integer expression or location.
I think the right thing to do would be to create a fresh IntegerValue when we see an IntegralCast.
The only snag here is that this would break the test IntegralToBooleanCastFromBool.
This test currently tests that we can round-trip cast a bool to an integer and back again and obtain the same BoolValue that we started out with. This behavior would obviously be broken if we created a fresh IntegerValue for an IntegralCast.
I'm not sure if we're actually relying on this round-trip behavior for anything, but we should check before we change this.