20201112T123004Z.fail.html.gz
```
1)
File.utime allows Time instances in the far future to set mtime and
atime (but some filesystems limit it up to 2446-05-10) FAILED
Expected [559444, 2446].include? 2038
to be truthy but was false
/home/chkbuild/chkbuild/tmp/build/20201112T123004Z/ruby/spec/ruby/core/file/utime_spec.rb:80:in
`block (4 levels) in <top (required)>'
/home/chkbuild/chkbuild/tmp/build/20201112T123004Z/ruby/spec/ruby/core/file/utime_spec.rb:3:in
`<top (required)>'
```
```
$ touch foo
$ ./miniruby -e 'time = Time.at(1<<44); File.utime(time, time, "foo")'
$ ls -l foo
-rw-r--r--. 1 mame wheel 0 Jan 19 2038 foo
```
close_incoming by antoher ractor means there is no other messages
will be sent to the ractor, so Ractor.receive will block forever,
and it should raise and stop.
close_outgoing by antoher ractor means, ... I don't have good idea
to use it. It can be a private method.
Ractor#close calls both, but it does not make sense to call
different purpose methods, so I remove it.
The timer function used on windows system set timer interrupt
flag of current main ractor's executing ec and thread can detect
the end of time slice. However, to set all ec->interrupt_flag for
all running ractors, it is requires to synchronize with other ractors.
However, timer thread can not acquire the ractor-wide lock because
of some limitation.
To solve this issue, this patch introduces USE_VM_CLOCK compile option
to introduce rb_vm_t::clock. This clock will be incremented by the
timer thread and each thread can check the incrementing by comparison
with previous checked clock. At last, on windows platform this patch
introduces some overhead, but I think there is no critical performance
issue because of this modification.
Racc calls `Array#sort!` to build a state transition table. As
`Array#sort!` is not a stable sort, the output may differ depending upon
the environment.
This changeset makes the sort stable manually, and updates all
expectation files.
This benchmark demonstrates the performance of setting an instance
variable when the type of object is constantly changing. This benchmark
should give us an idea of the performance of ivar setting in a
polymorphic environment
This commit adds a debug counter for the case where the inline cache
*missed* but the ivar index table has an entry for that ivar. This is a
case where a polymorphic cache could help
