This changes "test/rubygems/test_case.rb" to "test/rubygems/helper.rb",
and "test/rubygems/test_utilities.rb" to "test/rubygems/utilities.rb".
The two files are a helper for tests, not test files. However, a file
starting with "test_" prefix is handled as a test file directly loaded
by test-unit because Rakefile specifies:
```
t.test_files = FileList['test/**/test_*.rb']
```
Directly loading test/rubygems/test_utilities.rb caused "uninitialized
constant Gem::TestCase". This issue was fixed by
59c6820971, but the fix caused a
"circular require" warning because test_utilities.rb and test_case.rb
are now requiring each other.
Anyway, adding "test_" prefix to a test helper file is confusing, so
this changeset reverts the fix and solve the issue by renaming them.
6460e018df
The previous behavior depending on exact float values, it seemed
to work OK on amd64 and i386, but other CI platforms are
experiencing non-deterministic test failures with it. Relax test
slightly to hopefully pass on such platforms.
Depending on the float range, there could be an off-by-one error,
where the last result that should be in the range was missed. Fix
this by checking if the computed value for the expected value
outside the range is still inside the range, and if so, increment
the step size.
Fixes [Bug #16612]
The checkmatch instruction with VM_CHECKMATCH_TYPE_CASE calls
=== without a call cache. Emit a send instruction to make the call
instead. It includes a call cache.
The call cache improves throughput of using when statements to check the
class of a given object. This is useful for say, JSON serialization.
Use of a regular send instead of checkmatch also avoids taking the VM
lock every time, which is good for multi-ractor workloads.
Calculating -------------------------------------
master post
vm_case_classes 11.013M 16.172M i/s - 6.000M times in 0.544795s 0.371009s
vm_case_lit 2.296 2.263 i/s - 1.000 times in 0.435606s 0.441826s
vm_case 74.098M 64.338M i/s - 6.000M times in 0.080974s 0.093257s
Comparison:
vm_case_classes
post: 16172114.4 i/s
master: 11013316.9 i/s - 1.47x slower
vm_case_lit
master: 2.3 i/s
post: 2.3 i/s - 1.01x slower
vm_case
master: 74097858.6 i/s
post: 64338333.9 i/s - 1.15x slower
The vm_case benchmark is a bit slower post patch, possibily due to the
larger instruction sequence. The benchmark dispatches using
opt_case_dispatch so was not running checkmatch and does not make the
=== call post patch.
20210526T070003Z.fail.html.gz
```
1) Error:
TestThread#test_thread_native_thread_id:
NotImplementedError: native_thread_id() function is unimplemented on this machine
/export/home/users/chkbuild/cb-gcc/tmp/build/20210526T070003Z/ruby/test/ruby/test_thread.rb:1338:in `native_thread_id'
/export/home/users/chkbuild/cb-gcc/tmp/build/20210526T070003Z/ruby/test/ruby/test_thread.rb:1338:in `test_thread_native_thread_id'
```
If freezing an array inside sort!, previously the array could be
modified after the freeze. This checks whether the receiver is
frozen after every yield and potential call to #> or #<,
preventing modifications if the receiver is frozen inside the
block or by the #> or #< call.
Fixes [Bug #17739]
Before this change, CDHASH operands were built as plain hashes when
loaded from binary. Without setting up the hash with the correct
st_table type, the hash can sometimes be an ar_table. When the hash is
an ar_table, lookups can call the `eql?` method on keys of the hash,
which makes the `opt_case_dispatch` instruction not "leaf" as it
implicitly declares.
The following script trips the stack canary for checking the leaf
attribute for `opt_case_dispatch` on VM_CHECK_MODE > 0 (enabled by
default with RUBY_DEBUG).
rb_vm_iseq = RubyVM::InstructionSequence
iseq = rb_vm_iseq.compile(<<-EOF)
case Class.new(String).new("foo")
when "foo"
42
end
EOF
puts rb_vm_iseq.load_from_binary(iseq.to_binary).eval
This commit changes the binary loading logic to build CDHASH with the
right st_table type. The dumping logic and the dump format stays the
same
Since refinement search is always performed, these entries should always
be public. The method entry that the refinement search returns decides
the visibility.
Fixes [Bug #17822]
609de71f04 fixes the issue by using
`throw` insn if `ensure` is used. However, that patch introduce
additional `throw` even if it is not needed. This patch solves
the issue.
This issue is pointed by @mame.
