Age | Commit message (Collapse) | Author |
|
loaded
ruby/debug uses `irb/color` selectively:
https://github.com/ruby/debug/blob/0ac22406bb8f65bc76f9f5576a00c729cac693af/lib/debug/color.rb#L4
And in that case, `IRB.conf` won't be defined. So Color.colorable? needs
to consider that.
This also fixes the Ruby trunk CI.
https://github.com/ruby/irb/commit/b2cd07e795
|
|
* 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
|
|
https://github.com/ruby/rdoc/commit/f727854bd5
|
|
|
|
https://github.com/ruby/rdoc/commit/854b370763
|
|
https://github.com/ruby/rdoc/commit/c051eb90d1
|
|
Initialization depending on VM is separated.
https://github.com/ruby/rdoc/commit/030d10fccd
|
|
|
|
will JIT them.
Notes:
Merged: https://github.com/ruby/ruby/pull/6014
|
|
Also slightly broaden the cases where << on two strings will generate
specialised code rather than a plain method call.
Notes:
Merged: https://github.com/ruby/ruby/pull/6022
|
|
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
|
|
(https://github.com/ruby/reline/pull/413)
https://github.com/ruby/reline/commit/bd49537964
|
|
|
|
Not to generate .dSYM directories by MJIT runs, which are left in
large numbers after each test.
|
|
to load
Show an absolute path instead of an unhelpful relative path.
https://github.com/rubygems/rubygems/commit/f1eed36e2f
|
|
It wasn't specific to UCRT64
https://github.com/ruby/ruby/runs/7062992464
|
|
|
|
|
|
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
c2e37c8ff7da395f33fae546d9ae9e2408fc9236.
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
|
|
|
|
|
|
|
|
YJIT_BUILD is more relevant outside of YJIT.
|
|
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.
|
|
Fix https://github.com/ruby/irb/pull/353
https://github.com/ruby/irb/commit/7db93f9326
|
|
https://github.com/ruby/irb/commit/e024ab716b
|
|
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
|
|
|
|
When testing under the ruby/ruby setup, mkmf.rb needs to the `$extout`
global variable set properly.
This is because, in this particular case, the `ruby.h` header needed to
compile extensions is constructed from
`$(extout)/include($arch)/ruby/config.h` but `$extout` is not set by
default.
I tried to fix this in mkmf.rb itself but I couldn't figure it. But
setting it externally to workaround the issue fixes the specs, so I'll
start with that. Also setting it externally causes issues when running
specs upstream against Ruby 2.3 (I guess because of some difference with
Ruby 2.3 mkmf.rb implementation). So I'm avoiding doing it on Ruby 2.3 to
woraround that.
https://github.com/rubygems/rubygems/commit/d782984585
|
|
|
|
While generate_index did clean up temporary directory, when running with
--update flag, that did not happen and the temporary directory was left
behind.
This commit fixes that and modifies tests in order to make sure this is
not reintroduced later on.
Fixes #5635.
https://github.com/rubygems/rubygems/commit/9fa34dc329
|
|
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/6036
|
|
|
|
https://github.com/ruby/io-wait/commit/0fa6e3f7ba
|
|
Fix https://github.com/ruby/io-wait/pull/11
https://github.com/ruby/io-wait/commit/845f9a1f55
|
|
(https://github.com/ruby/io-wait/pull/20)
https://github.com/ruby/io-wait/commit/c5c6abbb5c
|
|
|
|
defined by Ruby. (https://github.com/ruby/io-wait/pull/19)
* Fix return value compatibility with Ruby 2.x.
* Don't add `IO#wait*` methods in Ruby 3.2+.
https://github.com/ruby/io-wait/commit/54c504d089
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/6060
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/6059
|
|
|
|
ISeqs loaded from binary were breaking because the storage partition
calculation had bugs in it. Specifically it couldn't take in to account
the case when inline storage was overallocated (for example when we
allocate inline storage for an instruction but peephole optimization
eliminates that instruction).
`RUBY_ISEQ_DUMP_DEBUG=to_binary make test-all` would break, and this
patch fixes it
Notes:
Merged: https://github.com/ruby/ruby/pull/6061
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/6054
|
|
The test in [1] was removed because it stopped working when we limited
the power of Kernel#binding in [2]. However, the underlying issue could
still be reproduced using blocks. Add back a regression test.
I tested the test by commenting out the fix from [1].
[1]: 54c91042ed61a869d4a66fc089b21f56d165265f
[2]: 343ea9967e4a6b279eed6bd8e81ad0bdc747f254
|
|
If the iseqs don't have any objects in them that need marking, then
immediately free the bitmap buffer
Notes:
Merged: https://github.com/ruby/ruby/pull/6058
|
|
We can avoid allocating a bitmap when the number of elements in the iseq
is fewer than the size of an iseq_bits_t
Notes:
Merged: https://github.com/ruby/ruby/pull/6058
|
|
YJIT is now a build-time opt-in so on platforms that YJIT could support
it could still be unavailable due to user discretion. Use MJIT for --jit
and don't display YJIT related command line options in --help when YJIT
is not included in the build.
|
|
Co-authored-by: Tomás Coêlho <36938811+tomascco@users.noreply.github.com>
Notes:
Merged: https://github.com/ruby/ruby/pull/6053
|