- ruby-core - ml.ruby-lang.org

[ruby-core:111818] [Ruby master Feature#19344] Regexp.new: stricter handling of second argument
by zverok (Victor Shepelev) 16 Jan '23

16 Jan '23

Issue #19344 has been reported by zverok (Victor Shepelev). ---------------------------------------- Feature #19344: Regexp.new: stricter handling of second argument https://bugs.ruby-lang.org/issues/19344 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal ---------------------------------------- Since Ruby 3.2 (#18788), the second argument to `Regexp.new` can be: 1. Integer: then it is treated as a combination of `Regexp::<constant>` flags 2. String: then it is treated as a combination of string flags 3. `nil` or `false`: then it is ignored 4. **any other truthy value**: then it is treated as an "ignore case" option. The fourth one is confusing, especially since the introduction of the flexibility of flags: one might erroneously assume or forget the protocol, and the naive check will strengthen the assumption: ```ruby # maybe it accepts the array of string options?.. Regexp.new('foo', %w[i]) #=> /foo/i -- oh, seems it does # would the symbol work?.. Regexp.new('foo', :i) #=> /foo/i -- awesome, it works! ``` I propose to change (4) to only handle literal `true` value, and raise `TypeError` on any unsupported type. On compatibility: I believe that whenever the usage of boolean to distinguish "ignore case/respect case" is deliberate (like [in rubygems](https://github.com/rubygems/rubygems/blob/master/lib/rubygems/opt…) the code already passes true/false, not any random value. Otherwise, the change in Ruby 3.2 might also have broken it (what if it previously passed strings, meaning them to be "truthy values"?) PS: BTW, the documentation for (4) was completely lost in Ruby 3.2, due to [this PR](https://github.com/ruby/ruby/pull/5815). cc @jeremyevans0, @burdettelamar -- https://bugs.ruby-lang.org/

2 1

[ruby-core:111823] [PATCH] fiddle: Use C11 _Alignof to define ALIGN_OF when possible
by Khem Raj 16 Jan '23

16 Jan '23

WG14 N2350 made very clear that it is an UB having type definitions within "offsetof" [1]. This patch enhances the implementation of macro ALIGN_OF to use builtin "_Alignof" to avoid undefined behavior when using std=c11 or newer clang 16+ has started to flag this [2] Fixes build when using -std >= gnu11 and using clang16+ Older compilers gcc < 4.9 or clang < 8 has buggy _Alignof even though it may support C11, exclude those compiler versions [1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2350.htm [2] https://reviews.llvm.org/D133574 Signed-off-by: Khem Raj <raj.khem(a)gmail.com> --- ext/fiddle/fiddle.h | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/ext/fiddle/fiddle.h b/ext/fiddle/fiddle.h index 10eb9ce..ffb395e 100644 --- a/ext/fiddle/fiddle.h +++ b/ext/fiddle/fiddle.h @@ -196,7 +196,17 @@ #endif #define TYPE_UINTPTR_T (-TYPE_INTPTR_T) -#define ALIGN_OF(type) offsetof(struct {char align_c; type align_x;}, align_x) +/* GCC releases before GCC 4.9 had a bug in _Alignof. See GCC bug 52023 + <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52023>. + clang versions < 8.0.0 have the same bug. */ +#if (!defined __STDC_VERSION__ || __STDC_VERSION__ < 201112 \ + || (defined __GNUC__ && __GNUC__ < 4 + (__GNUC_MINOR__ < 9) \ + && !defined __clang__) \ + || (defined __clang__ && __clang_major__ < 8)) +# define ALIGN_OF(type) offsetof(struct {char align_c; type align_x;}, align_x) +#else +# define ALIGN_OF(type) _Alignof(type) +#endif #define ALIGN_VOIDP ALIGN_OF(void*) #define ALIGN_CHAR ALIGN_OF(char) -- 2.39.0

2 1

[ruby-core:111816] [Ruby master Bug#19343] Integer#ceildiv should respece #coerce
by kyanagi (Kouhei Yanagita) 15 Jan '23

15 Jan '23

Issue #19343 has been reported by kyanagi (Kouhei Yanagita). ---------------------------------------- Bug #19343: Integer#ceildiv should respece #coerce https://bugs.ruby-lang.org/issues/19343 * Author: kyanagi (Kouhei Yanagita) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.0 (2022-12-25 revision a528908271) [arm64-darwin21] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- https://github.com/ruby/ruby/pull/7118 This issue is similar to #19335. ```Ruby c = Object.new def c.coerce(other) = [other, 10] p 1234 / c # => 123 p 1234.div(c) # => 123 p 1234.quo(c) # => (617/5) p 1234.fdiv(c) # => 123.4 p 1234.ceildiv(c) # => in `ceildiv': undefined method `-@' for #<Object:0x000000010250ad68> (NoMethodError) ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111798] [Ruby master Bug#19335] Integer#remainder and Numeric#remainder should respect #coerce
by kyanagi (Kouhei Yanagita) 13 Jan '23

13 Jan '23

Issue #19335 has been reported by kyanagi (Kouhei Yanagita). ---------------------------------------- Bug #19335: Integer#remainder and Numeric#remainder should respect #coerce https://bugs.ruby-lang.org/issues/19335 * Author: kyanagi (Kouhei Yanagita) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.0 (2022-12-25 revision a528908271) [arm64-darwin21] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Thinking of the result of the following, `Integer#remainder` and `Numeric#remainder` should respect `#coerce`. (`BigDecimal#remainder` seems to respect `#coerce`.) ```Ruby c = Object.new def c.coerce(other) [other, 10] end p 1234 / c # => 123 p 1234.div(c) # => 123 p 1234.quo(c) # => (617/5) p 1234.fdiv(c) # => 123.4 p 1234 % c # => 4 p 1234.modulo(c) # => 4 p 1234.divmod(c) # => [123, 4] p 1234.remainder(c) # => in `remainder': comparison of Object with 0 failed (ArgumentError) p 1234.0 / c # => 123 p 1234.0.div(c) # => 123 p 1234.0.quo(c) # => (617/5) p 1234.0.fdiv(c) # => 123.4 p 1234.0 % c # => 4 p 1234.0.modulo(c) # => 4 p 1234.0.divmod(c) # => [123, 4] p 1234.0.remainder(c) # => in `remainder': comparison of Object with 0 failed (ArgumentError) require 'bigdecimal' p BigDecimal('1234.0').remainder(c) # => 0.4e1 ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:111791] [Ruby master Feature#19075] Add Array#bsearch_last and #bsearch_last_index
by kyanagi (Kouhei Yanagita) 12 Jan '23

12 Jan '23

Issue #19075 has been updated by kyanagi (Kouhei Yanagita). I have thought about this issue and am now leaning toward `bsearch(target: :last)`. I proposed `bsearch_last` at first, this is because I didn't think of an optional keyword argument for `bsearch`. Since searching the beginning and the end are the same binary searching, it seems better to call them by the same name. Let's think about the arguments. Consider the possibility of further arguments, keyword arguments would be better than positional argunents. What name should the keyword arguments be? `reverse: true` is attractive in that it allows the same name to be used for various methods, but I don't think `bsearch(reverse: true)` clearly expresses the intent of looking for the last element. The general word "reverse" seems to be vague to indicate the intent of "whether the target is the first one or the last one". I think `bsearch(target: :first)` and `bsearch(target: :last)` are the best names that convey the intent. ### About find-any mode If we adopt `bsearch(target: :last)`, I think the option (3) is the best choice. ---------------------------------------- Feature #19075: Add Array#bsearch_last and #bsearch_last_index https://bugs.ruby-lang.org/issues/19075#change-101202 * Author: kyanagi (Kouhei Yanagita) * Status: Open * Priority: Normal ---------------------------------------- PR: https://github.com/ruby/ruby/pull/6611 (I'm going to talk about `Array` here, but the same argument can be made for `Range`. If `Array#bsearch_last` is acceptable, I will work also for `Range`.) Ruby's bsearch returns the first element which satisfies the given block. ```ruby # Search the first element greater than 18 array = [10, 15, 20, 25] array.bsearch { |x| x > 18 } # => 20 ``` If we want the last element, we need to invert the condition and step backward. ```ruby # Search the last element less than 18 array = [10, 15, 20, 25] index = array.bsearch_index { |x| !(x < 18) } array[index-1] # => 15 ``` Of course, we need to consider `nil` and the boundary. ```ruby # Search the last element less than 100 index = array.bsearch_index { |x| !(x < 100) } # => nil if index.nil? array.last # => 25 else array[index-1] end ``` ```ruby # Search the last element less than 0 index = array.bsearch_index { |x| !(x < 0) } # => 0 if index.nil? array.last elsif index == 0 nil else array[index-1] end ``` This is where mistakes can easily be made, so I propose `Array#bsearch_last` and `Array#bsearch_last_index`. `Array#bsearch_last` returns the last element which satisfies the given block. `Array#bsearch` requires that all false-evaluating elements precede all true-evaluating elements. As is clear from the meaning of the method, conversely to `bsearch`, `bsearch_last` requires that all true-evaluating elements precede all false-evaluating elements. (If `bsearch_last` is acceptable, the name "find-minimum mode" should be changed.) ```ruby array = [10, 15, 20, 25] array.bsearch_last { |x| x < 18 } # => 15 array.bsearch_last { |x| x < 100 } # => 25 array.bsearch_last { |x| x < 0 } # => nil ``` There are several possible options for find-any mode. (1) `bsearch_last` does not support find-any mode. A block for `bsearch_last` must return `true`, `false` or `nil`. ``` [1, 2, 3].bsearch_last { 0 } # => TypeError ``` My pull request tentatively includes this implementation. (2) `bsearch_last` supports find-any mode and it behaves like `bsearch`. `bsearch` with find-any mode returns an element, for which the block returns zero. If multiple elements satisfy the condition, it is not determined which of them will be returned. It is conceivable that `bsearch_last` behaves in the same way as `bsearch`. ``` # current behavior # It is not specified whether `:b`, `:c`, or `:d` is returned. [[1,:a], [2, :b], [2, :c], [2, :d], [3, :e]].bsearch { |a, b| 2 <=> a } # => [2, :c] ``` (3) `bsearch_last` supports find-any mode and returns the last element. Make `bsearch` return the first element. Change the behavior of `bsearch` to return the first element for which the block returns zero. `bsearch_last` returns the last element for which the block returns zero. ``` # Change it like this: [[1,:a], [2, :b], [2, :c], [2, :d], [3, :e]].bsearch { |a, b| 2 <=> a } # => [2, :b] [[1,:a], [2, :b], [2, :c], [2, :d], [3, :e]].bsearch_last { |a, b| 2 <=> a } # => [2, :d] ``` (If this option is adopted, the name "find-any mode" should be renamed.) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111400] [Ruby master Bug#19254] Enabling YJIT configuration option breaks rspec-core test suite
by vo.x (Vit Ondruch) 11 Jan '23

11 Jan '23

Issue #19254 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Bug #19254: Enabling YJIT configuration option breaks rspec-core test suite https://bugs.ruby-lang.org/issues/19254 * Author: vo.x (Vit Ondruch) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.0dev (2022-12-23 master c5eefb7f37) [x86_64-linux] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- In preparation for Ruby 3.2, we have enabled YJIT in Fedora: https://src.fedoraproject.org/rpms/ruby/c/3c1be9f9c2c1d8679eebb9a185fefa15b… Since that moment, rspec-core test suite started to fail (see the attached log for all details): ~~~ ... snip ... 1) RSpec::Core::Example#run memory leaks, see GH-321, GH-1921 releases references to the examples / their ivars Failure/Error: expect(get_all.call).to eq opts.fetch(:post_gc) expected: [] got: ["after_all", "before_all"] (compared using ==) # ./spec/rspec/core/example_spec.rb:469:in `expect_gc' # ./spec/rspec/core/example_spec.rb:492:in `block (4 levels) in <top (required)>' # ./spec/support/sandboxing.rb:16:in `block (3 levels) in <top (required)>' # ./spec/support/sandboxing.rb:7:in `block (2 levels) in <top (required)>' Finished in 8.98 seconds (files took 0.47612 seconds to load) 2209 examples, 1 failure, 4 pending ~~~ Please note that the YJIT was not enabled during runtime, just the support was enabled. Disabling the YJIT supports makes the test case pass. [1]: https://download.copr.fedorainfracloud.org/results/vondruch/ruby-3.2/fedora… [2]: https://copr.fedorainfracloud.org/coprs/vondruch/ruby-3.2/package/rubygem-r… ---Files-------------------------------- builder-live.log.gz (28.7 KB) -- https://bugs.ruby-lang.org/

5 6

[ruby-core:111783] [Ruby master Bug#19332] Thread::Queue#pop raises ArgumentError with
by schnittchen (Thomas Stratmann) 11 Jan '23

11 Jan '23

Issue #19332 has been reported by schnittchen (Thomas Stratmann). ---------------------------------------- Bug #19332: Thread::Queue#pop raises ArgumentError with https://bugs.ruby-lang.org/issues/19332 * Author: schnittchen (Thomas Stratmann) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.0 (2022-12-25 revision a528908271) [x86_64-linux] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ✓ ruby --version ruby 3.2.0 (2022-12-25 revision a528908271) [x86_64-linux] ✓ irb Ignoring debug-1.7.1 because its extensions are not built. Try: gem pristine debug --version 1.7.1 Ignoring rbs-2.8.2 because its extensions are not built. Try: gem pristine rbs --version 2.8.2 irb(main):001:0> require "thread" => false irb(main):002:0> q = Thread::Queue.new => #<Thread::Queue:0x00007f5ec57c2da8> irb(main):003:0> q.pop(non_block: true) <internal:thread_sync>:14:in `pop': unknown keyword: :non_block (ArgumentError) from (irb):3:in `<main>' from /home/thomas/.rubies/ruby-3.2.0/lib/ruby/gems/3.2.0/gems/irb-1.6.2/exe/irb:11:in `<top (required)>' from /home/thomas/.rubies/ruby-3.2.0/bin/irb:25:in `load'·· from /home/thomas/.rubies/ruby-3.2.0/bin/irb:25:in `<main>' irb(main):004:0> According to the documentation, I expected a ThreadError to be raised. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:111775] [Ruby master Bug#19330] ruby 3.2.0 parameter autosplat breaks call using (*args, &block)
by rockorequin (rocko requin) 11 Jan '23

11 Jan '23

Issue #19330 has been reported by rockorequin (rocko requin). ---------------------------------------- Bug #19330: ruby 3.2.0 parameter autosplat breaks call using (*args, &block) https://bugs.ruby-lang.org/issues/19330 * Author: rockorequin (rocko requin) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- The following code in Rails 6.1.7 activerecord relation.rb no longer works with ruby 3.2.0, because the call "instance_exec(*args, &block)" raises an ArgumentException: ``` def _exec_scope(*args, &block) # :nodoc: @delegate_to_klass = true _scoping(nil) { instance_exec(*args, &block) || self } ensure @delegate_to_klass = false end ``` I think it may be due to the bugfix https://bugs.ruby-lang.org/issues/18633 ("proc { |a, **kw| a } autosplats and treats empty kwargs specially"). There is more info at https://github.com/rails/rails/issues/46934, including this code to reproduce the issue: ``` gem 'rails', '=6.1.7' require 'active_record' class Test < ActiveRecord::Base scope :test, ->(arg: nil) {} end Test.test(arg: 1) ``` Another user in that issue report has indicated that the syntax "save(**)" in suppressor.rb raises the same exception in ruby 3.2.0: ``` def save(**) # :nodoc: SuppressorRegistry.suppressed[self.class.name] ? true : super end ``` Is this intentional, ie is the syntax "instance_exec(*args, &block)" etc no longer valid in ruby 3.2.0? If so, could a note indicating this incompatibility perhaps be added to the release notes for 3.2.0? -- https://bugs.ruby-lang.org/

2 1

[ruby-core:111772] [Ruby master Feature#18190] Split `Random::Formatter` from securerandom
by Eregon (Benoit Daloze) 10 Jan '23

10 Jan '23

Issue #18190 has been updated by Eregon (Benoit Daloze). To clarify, random/formatter is now a stdlib (not loaded by default). `Random::Formatter` is defined in core but has few methods before `require 'random/formatter'`: ``` $ ruby -e 'puts Random::Formatter.instance_methods(false)' rand random_number $ ruby -rrandom/formatter -e 'puts Random::Formatter.instance_methods(false)' random_number uuid rand alphanumeric hex random_bytes base64 urlsafe_base64 ``` ---------------------------------------- Feature #18190: Split `Random::Formatter` from securerandom https://bugs.ruby-lang.org/issues/18190#change-101184 * Author: nobu (Nobuyoshi Nakada) * Status: Closed * Priority: Normal ---------------------------------------- Now `Random::Formatter` methods are defined in `securerandom.rb`, since it was split from `SecureRandom` module historically. However this module does not need to be `SecureRandom` but just to respond to `bytes` method. I propose to move `Random::Formatter` module to another file, `random_formatter.rb` or `random/formatter.rb`. And keep only that file in ruby core and remove from securerandom library in future. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111770] [Ruby master Feature#18285] NoMethodError#message uses a lot of CPU/is really expensive to call
by Hanmac (Hans Mackowiak) 10 Jan '23

10 Jan '23

Issue #18285 has been updated by Hanmac (Hans Mackowiak). maybe we could add some conditions when the object should be printed instead of the class for NoMethodError? * if object overwrites `method_missing` and maybe `respond_to_missing` then print the object instead of the class * if the object has included or prepend modules into its singleton class, then print the object instead of real class these are the cases i can think of that could affect the methods an object can respond to that aren't related to its class ---------------------------------------- Feature #18285: NoMethodError#message uses a lot of CPU/is really expensive to call https://bugs.ruby-lang.org/issues/18285#change-101178 * Author: ivoanjo (Ivo Anjo) * Status: Open * Priority: Normal ---------------------------------------- Hello there! I'm working at Datadog on the ddtrace gem -- https://github.com/DataDog/dd-trace-rb and we ran into this issue on one of our internal testing applications. I also blogged about this issue in <https://ivoanjo.me/blog/2021/11/01/nomethoderror-ruby-cost/>. ### Background While testing an application that threw a lot of `NoMethodError`s in a Rails controller (this was used for validation), we discovered that service performance was very much impacted when we were logging these exceptions. While investigating with a profiler, the performance impact was caused by calls to `NoMethodError#message`, because this Rails controller had a quite complex `#inspect` method, that was getting called every time we tried to get the `#message` from the exception. ### How to reproduce ```ruby require 'bundler/inline' gemfile do source 'https://rubygems.org' gem 'benchmark-ips' end puts RUBY_DESCRIPTION class GemInformation # ... def get_no_method_error method_does_not_exist rescue => e e end def get_runtime_error raise 'Another Error' rescue => e e end def inspect # <-- expensive method gets called when calling NoMethodError#message Gem::Specification._all.inspect end end NO_METHOD_ERROR_INSTANCE = GemInformation.new.get_no_method_error RUNTIME_ERROR_INSTANCE = GemInformation.new.get_runtime_error Benchmark.ips do |x| x.config(:time => 5, :warmup => 2) x.report("no method error message cost") { NO_METHOD_ERROR_INSTANCE.message } x.report("runtime error message cost") { RUNTIME_ERROR_INSTANCE.message } x.compare! end ``` ### Expectation and result Getting the `#message` from a `NoMethodError` should be no costly than getting it from any other exception. In reality: ``` ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [x86_64-linux] no method error message cost 115.390 (± 1.7%) i/s - 580.000 in 5.027822s runtime error message cost 6.938M (± 0.5%) i/s - 35.334M in 5.092617s Comparison: runtime error message cost: 6938381.6 i/s no method error message cost: 115.4 i/s - 60130.02x (± 0.00) slower ``` ### Suggested solutions 1. Do not call `#inspect` on the object on which the method was not found (see <https://github.com/ruby/ruby/blob/e0915ba67964d843832148aeca29a1f8244ca7b1/…>) 2. Cache result of calling `#message` after the first call. Ideally this should be done together with suggestion 1. -- https://bugs.ruby-lang.org/

1 0