# HG changeset patch
# User Xidorn Quan <me@upsuper.org>
# Date 1525259227 -36000
# Node ID 904aaf73eb3a620cb2ea3f44ee35243e0b385ca9
# Parent  504919daeab8d70c4fb613c356a26ca516440aec
Bug 1457524 part 4 - Allow 16% false positives in test bloom::create_and_insert_some_stuff. r=heycam

It seems that the result of hash algorithm used in bloom filter depends
on the pointer length. On 64bit platforms, there are 135 false positives
in the first part of that test, and 8 in the second part. However, on
32bit platforms, the numbers become 157 and 16 correspondingly.

16 is still less than 20% in the second part, so all fine, but 157 is
slightly larger than 15% in the test assertion. Given it is what we are
shipping, we probably should just accept this and loosen the assertion.

MozReview-Commit-ID: 9kFXBzLFAzE

diff --git a/servo/components/selectors/bloom.rs b/servo/components/selectors/bloom.rs
--- a/servo/components/selectors/bloom.rs
+++ b/servo/components/selectors/bloom.rs
@@ -320,17 +320,17 @@ fn create_and_insert_some_stuff() {
 
     for i in 0_usize .. 1000 {
         assert!(bf.might_contain(&i));
     }
 
     let false_positives =
         (1001_usize .. 2000).filter(|i| bf.might_contain(i)).count();
 
-    assert!(false_positives < 150, "{} is not < 150", false_positives); // 15%.
+    assert!(false_positives < 160, "{} is not < 160", false_positives); // 16%.
 
     for i in 0_usize .. 100 {
         bf.remove(&i);
     }
 
     for i in 100_usize .. 1000 {
         assert!(bf.might_contain(&i));
     }
