We need to dump relative offsets for inline storage entries so that
loading iseqs as an array works as well. This commit also has some
minor refactoring to make computing relative ISE information easier.
This should fix the iseq dump / load as array tests we're seeing fail in
CI.
Co-Authored-By: John Hawthorn <john@hawthorn.email>
This fails if there are any unused rust-bindgen "allow" entries. For
that target we turn on Rust warnings (there are a lot) and grep for the
ones that correspond to unused allow entries.
I've added check-yjit-bindgen-unused as a dependency of
check-yjit-bindings, so unused allow entries will now fail CI.
This change also removes our single unused allow entry (VM_CALL.*) which
was known to be bad.
Some context tests assigns USE_COLORIZE to false and never change it
back. This can potentially affect other tests' result as the default
should be nil (activated) instead.
https://github.com/ruby/irb/commit/986eb16ece
Under POSIX behavior of leading // is implementation defined. Musl does
preserve it in realpath, glibc does not. That means the test was failing
when executed on alpine linux. Original issue #508 was about // in the
path, not about leading ones. When executed in such environment, the
test will still test what it should when the explicit mangling of the
path is not done.
Fixes#5652https://github.com/rubygems/rubygems/commit/0fa7373bf6
* Use colorable: argument as the only coloring control
* Centalize color controling logic at Color.colorable?
There are 2 requirements for coloring output:
1. It's supported on the platform
2. The user wants it: `IRB.conf[:USE_COLORIZE] == true`
Right now we check 1 and 2 separately whenever we colorize things.
But it's error-prone because while 1 is the default of `colorable`
parameter, 2 always need to manually checked. When 2 is overlooked, it
causes issues like https://github.com/ruby/irb/pull/362
And there's 0 case where we may want to colorize even when the user
disables it. So I think we should merge 2 into `Color.colorable?` so it
can be automatically picked up.
* Add tests for all inspect modes
* Simplify inspectors' coloring logic
* Replace use_colorize? with Color.colorable?
* Remove Context#use_colorize cause it's redundant
https://github.com/ruby/irb/commit/1c53023ac4
When running a command with the `--verbose` flag that ends up raising a
`BundlerError`, Bundler will unnecessarily print the error twice.
This commit fixes the issue by removing the duplicate logging.
https://github.com/rubygems/rubygems/commit/689004a164
macOS's AvailabilityMacros.h does not contain macros for future
versions. If a version macro is not defined, consider only earlier
versions to be targeted.
New test failures on MINGW appeared after
c2e37c8ff7.
1) Error:
Rinda::TupleSpaceProxyTest#test_00_template:
NoMethodError: undefined method `stop_service' for nil:NilClass
D:/a/ruby/ruby/src/test/rinda/test_rinda.rb:516:in `teardown'
2) Error:
Rinda::TupleSpaceProxyTest#test_ruby_talk_264062:
NoMethodError: undefined method `stop_service' for nil:NilClass
D:/a/ruby/ruby/src/test/rinda/test_rinda.rb:516:in `teardown'
Teardown happens even when the test is omitted.
See: https://github.com/ruby/ruby/runs/7058984522
As you all know, MinGW UCRT64 CI has randomly got stuck despite its
"Finished tests" output.
Looking at the logs closely, it seems like all of the recent such
reproductions end with the following output:
```
Retrying hung up testcases...
[ 1/14] Rinda::TupleSpaceProxyTest#test_ruby_talk_264062 = 0.21 s
[ 2/14] Rinda::TupleSpaceProxyTest#test_00_template = 0.01 s
[ 3/14] Rinda::TupleSpaceProxyTest#test_inp_rdp = 0.00 s
[ 4/14] Rinda::TupleSpaceProxyTest#test_core_03_notify = 0.01 s
[ 5/14] Rinda::TupleSpaceProxyTest#test_00_renewer = 0.01 s
[ 6/14] Rinda::TupleSpaceProxyTest#test_cancel_02 = 0.11 s
[ 7/14] Rinda::TupleSpaceProxyTest#test_00_DRbObject = 0.00 s
[ 8/14] Rinda::TupleSpaceProxyTest#test_core_02 = 0.11 s
[ 9/14] Rinda::TupleSpaceProxyTest#test_core_01 = 0.11 s
[10/14] Rinda::TupleSpaceProxyTest#test_remote_array_and_hash = 0.01 s
[11/14] Rinda::TupleSpaceProxyTest#test_00_tuple = 0.00 s
[12/14] Rinda::TupleSpaceProxyTest#test_take_bug_8215 = 0.41 s
[13/14] Rinda::TupleSpaceProxyTest#test_cancel_01 = 0.11 s
[14/14] Rinda::TupleSpaceProxyTest#test_symbol_tuple = 0.01 s
Finished tests in 719.252845s, 29.4292 tests/s, 3838.7154 assertions/s.
21167 tests, 2761007 assertions, 0 failures, 0 errors, 708 skips
```
https://github.com/ruby/ruby/runs/7057789554
While it seems to be retried successfully, given that it hungs up once
and this appears all the time, this test class seems a bit suspicious.
To check if it's related, let me try disabling this for now.
When outputting a (possibly truncated) value, IRB will query the
window size. However, if IRB was piped to another process, stdout
will no longer be a TTY and will not support the `winsize` method.
This fix ensure that stdout is a TTY.
https://github.com/ruby/irb/commit/125de5eeea