Currently, all other cases do set the result to true when in the successful path. Only the Array::Double case has neglected to do so. This bug does is only present in the 64-bit DFG.
Turns out that the FTL implementation of HasIndexedProperty has a similar but different problem. In this case, the FTL is setting the boolean result. However, the value that it is setting it with needs to be inverted.
Michael helped me out with figuring out how to invert said bit. My tests appear to be passing now. Patch for fix coming soon.
Created attachment 250226 [details]
Comment on attachment 250226 [details]
View in context: https://bugs.webkit.org/attachment.cgi?id=250226&action=review
> - m_out.doubleNotEqualOrUnordered(doubleValue, doubleValue));
> - m_out.branch(checkHoleResult.value(), rarely(slowCase), usually(continuation));
> + m_out.bitNot(m_out.doubleNotEqualOrUnordered(doubleValue, doubleValue)));
> + m_out.branch(checkHoleResult.value(), usually(continuation), rarely(slowCase));
You should just use doubleEqual() instead of bitNot(doubleNotEqualOrUnordered)
Created attachment 250228 [details]
patch 2: with Fil's better doubles comparison.
Thanks. Landed in r182444: <http://trac.webkit.org/r182444>.