When we use `test_prism_eval`, failed tests will point to the line
number of the `test_prism_eval` method definition instead of the test
that failed. If we use `assert_prism_eval` instead, failed tests will
properly poin to the test that failed because the test framework knows
to stop the backtrace earlier.
Before line number in failure points to helper definition:
```
Prism::TestCompilePrism#test_RegularExpressionNode = 0.21 s
1) Failure:
Prism::TestCompilePrism#test_RegularExpressionNode [test/ruby/test_compile_prism.rb:755]:
</pit/> (Windows-31J) expected but was
</pit/> (US-ASCII).
```
After line number in failure points to test that failed:
```
Prism::TestCompilePrism#test_RegularExpressionNode = 0.00 s
1) Failure:
Prism::TestCompilePrism#test_RegularExpressionNode [test/ruby/test_compile_prism.rb:334]:
</pit/> (Windows-31J) expected but was
</pit/> (US-ASCII).
```
Since Linux 4.5, sendmsg(2) fails with ETOOMANYREFS if the number of
"in-flight" IOs, which has been sent by sendmsg(2) but has not yet
accepted by recvmsg(2), exceeds the RLIMIT_NOFILE resource limit.
https://rubyci.s3.amazonaws.com/arm64-neoverse-n1/ruby-master/log/20231025T090004Z.fail.html.gz
```
1) Error:
TestSocket_UNIXSocket#test_fd_passing_race_condition:
Errno::ETOOMANYREFS: Too many references: cannot splice - sendmsg(2)
```
This change reduces the number of times of IO passing under 1024,
which is a default limit in many environments.
* Fix [Bug #19632]: Disable external iterator for frozen enumerator
Currently, methods to manipulate an external iterator like `#next`
and `#feed` can be called even if a receiver of an enumerator is
frozen. However, these methods change the state of an external
iterator in an enumerator. Therefore, it seems a BUG to me, and
these methods should raise FrozenError if the receiver is frozen.
This fixed the following methods to raise FrozenError if the receiver is
frozen.
- `Enumerator#next`
- `Enumerator#next_values`
- `Enumerator#peek`
- `Enumerator#peek_values`
- `Enumerator#feed`
- `Enumerator#rewind`
* Fix a typo in the document
Thanks @Maumagnaguagno.
There is no longer a limit on the number of IVs you can store.
SHAPE_MAX_NUM_IVS was used to work around the IV10K problem (the well
known problem where setting 10k instance variables in a row would be too
slow). The redblack tree works well at any shape depth, even depths
greater than 80, and solves the IV10K problem.
This is an experimental commit that uses a functional red-black tree to
create an index of the ancestor shapes. It uses an Okasaki style
functional red black tree:
https://www.cs.tufts.edu/comp/150FP/archive/chris-okasaki/redblack99.pdf
This tree is advantageous because:
* It offers O(n log n) insertions and O(n log n) lookups.
* It shares memory with previous "versions" of the tree
When we insert a node in the tree, only the parts of the tree that need
to be rebalanced are newly allocated. Parts of the tree that don't need
to be rebalanced are not reallocated, so "new trees" are able to share
memory with old trees. This is in contrast to a sorted set where we
would have to duplicate the set, and also resort the set on each
insertion.
I've added a new stat to RubyVM.stat so we can understand how the red
black tree increases.
This reverts the commits for the master branch of RBS:
- commit f717faac632dd8664d0967f8e639b84d5d032854: "Update rbs
revision to test"
The target revision to test is in master branch, not for 3.2.x.
- commit 9e93af5329f35092c3de3ea37d4e9e181b800bb2: "Skip RBS
`RbConfig::TOPDIR` test that is `nil` before installation"
RbConfig_test.rb is not updated in 3.2.x branch.
Jemma Issroff
HParker
Samuel Giddins
eileencodes
Nobuyoshi Nakada
Yusuke Endoh
Hiroshi SHIBATA
OKURA Masafumi
Kouhei Yanagita
Hiroya Fujinami
Kazuhiro NISHIYAMA
yui-knk
Aaron Patterson
Aaron Patterson
dependabot[bot]