tests: Adjust conformance tests to account for array invariant (#1289)

These were written before compiler optimizations and array invariant. It
is now impossible for t[1] to be stored in the hash part, as this would
violate the array invariant that says that elements 1..#t are stored in
the array.

For ipairs, it doesn't traverse the hash part anymore now, so we adjust
the code to make sure no elements outside of the 1..#t slice are
covered. For table.find, we can use find-with-offset to still access the
hash part.

Fixes #1283.

Author: zeux

tests/conformance/basic.lua

@@ -726,16 +726,15 @@ assert((function()
     return sum
 end)() == 15)
 
--- the reason why this test is interesting is that the table created here has arraysize=0 and a single hash element with key = 1.0
--- ipairs must iterate through that
+-- ipairs will not iterate through hash part
 assert((function()
-    local arr = { [1] = 42 }
+    local arr = { [1] = 1, [42] = 42, x = 10 }
     local sum = 0
     for i,v in ipairs(arr) do
     sum = sum + v
     end
     return sum
-end)() == 42)
+end)() == 1)
 
 -- the reason why this test is interesting is it ensures we do correct mutability analysis for locals
 local function chainTest(n)

tests/conformance/tables.lua

@@ -412,8 +412,8 @@ do
 
   assert(table.find({false, true}, true) == 2)
 
-  -- make sure table.find checks the hash portion as well by constructing a table literal that forces the value into the hash part
-  assert(table.find({[(1)] = true}, true) == 1)
+  -- make sure table.find checks the hash portion as well
+  assert(table.find({[(2)] = true}, true, 2) == 2)
 end
 
 -- test table.concat