There appears to be a bug in the method
IntHashSet.copy(). The new
IntHashSet that emerges from the copy appears to have all fields identical to the original except for
_mask, and the difference in the
_mask value means that existing entries are not found in a
This is code that has been stable for years, and it's not obviously unused (though that might turn out to be the case). Perhaps it only happens under rare conditions in terms of the actual map content. The bug was revealed in a new piece of code in 10.0 that makes use of
IntHashMap. As it happens, the new code doesn't actually need to invoke
copy() at all.
#1 Updated by Michael Kay almost 2 years ago
- Status changed from New to Resolved
- Applies to branch 9.9, trunk added
- Fix Committed on Branch 9.9, trunk added
First, I've established that if we copy the
_mask field, the broken test case now works OK.
in the 10.0 version, I've added a method IntMap.isMutable() which returns true for those implementations of IntMap that can be modified in-situ; for this particular index, this avoids the need to copy the map in cases where it can be updated in situ.
Please register to edit this issue