November 2023 - ruby-core - ml.ruby-lang.org

[ruby-core:115537] [Ruby master Bug#16145] regexp match error if mixing /i, character classes, and utf8
by zenspider (Ryan Davis) 30 Nov '23

30 Nov '23

Issue #16145 has been updated by zenspider (Ryan Davis). @duerst I don't think your intuition about the character classes is correct: ``` ruby "CAFÉ" =~ /[a]/i # => 1 ``` ---------------------------------------- Bug #16145: regexp match error if mixing /i, character classes, and utf8 https://bugs.ruby-lang.org/issues/16145#change-105473 * Author: zenspider (Ryan Davis) * Status: Open * Priority: Normal * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN ---------------------------------------- (reported on behalf of mage(a)mage.gold -- there appears to be an error in registration or login): See: ruby-talk @ X-Mail-Count: 440336 2.6.3 :049 > 'SHOP' =~ /[xo]/i => 2 2.6.3 :050 > 'CAFÉ' =~ /[é]/i => 3 2.6.3 :051 > 'CAFÉ' =~ /[xé]/i => nil 2.6.3 :052 > 'CAFÉ' =~ /[xÉ]/i => 3 Expected result: 2.6.3 :051 > 'CAFÉ' =~ /[xé]/i => 3 I tested it on random regex online pages. It does not match on https://regex101.com/ It matches on: https://regexr.com/ https://www.regextester.com/ https://www.freeformatter.com/regex-tester.html (Ignore case turned on). The reason I suppose it’s more like a bug than a feature is the fact that /[é]/i matches 'CAFÉ'. If the //i didn’t work for UTF-8 characters then the /[é]/i wouldn’t match it either. For example, [é] does not match 'CAFÉ' on https://regex101.com/ I could not find a page or a system that behaves the same way as Ruby does. For example, it matches in PostgreSQL 10 (under FreeBSD 12) too: # select 'CAFÉ'~ '[xé]'; ?column? ---------- f (1 row) # select 'CAFÉ' ~* '[xé]'; ?column? ---------- t (1 row) Tested it in IRB on macOS and FreeBSD. $ uname -a && ruby -v && locale Darwin xxx 18.7.0 Darwin Kernel Version 18.7.0: Thu Jun 20 18:42:21 PDT 2019; root:xnu-4903.270.47~4/RELEASE_X86_64 x86_64 ruby 2.6.3p62 (2019-04-16 revision 67580) [x86_64-darwin18] LANG="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_CTYPE="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_ALL="en_US.UTF-8" $ uname -a && ruby -v && locale FreeBSD xxx 12.0-RELEASE-p9 FreeBSD 12.0-RELEASE-p9 GENERIC amd64 ruby 2.6.3p62 (2019-04-16 revision 67580) [x86_64-freebsd12.0] LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_ALL=en_US.UTF-8 I installed Ruby with RVM. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115446] [Ruby master Misc#20015] Privacy policy for ruby-lang.org
by hsbt (Hiroshi SHIBATA) 30 Nov '23

30 Nov '23

Issue #20015 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Misc #20015: Privacy policy for ruby-lang.org https://bugs.ruby-lang.org/issues/20015 * Author: hsbt (Hiroshi SHIBATA) * Status: Assigned * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- We got the request to add privacy policy page on ruby-lang.org at https://github.com/ruby/www.ruby-lang.org/issues/3134 I put a draft page: https://github.com/ruby/www.ruby-lang.org/pull/3144 We will discuss about this in dev meeting with Matz before deploy that. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:113180] [Ruby master Feature#19588] Allow Comparable#clamp(min, max) to accept nil as a specification
by kyanagi (Kouhei Yanagita) 30 Nov '23

30 Nov '23

Issue #19588 has been reported by kyanagi (Kouhei Yanagita). ---------------------------------------- Feature #19588: Allow Comparable#clamp(min, max) to accept nil as a specification https://bugs.ruby-lang.org/issues/19588 * Author: kyanagi (Kouhei Yanagita) * Status: Open * Priority: Normal ---------------------------------------- `Comparable#clamp(min, max)` (with two arguments) accepts `nil`. This behaves the same as beginless/endless Range. ~~~ruby 5.clamp(nil, 0) # => 0 5.clamp(10, nil) # => 10 5.clamp(..0) # => 0 5.clamp(10..) # => 10 ~~~ This behavior is not documented. Presumably, this was not introduced intentionally. The old Rubies did not accept accept a `Range` argument. In Ruby 2.7, accepting `Range` as an argument was introduced. At that time, the approach of passing `nil` as a two-argument method was also discussed but not adopted, and using Range was chosen instead. https://bugs.ruby-lang.org/issues/14784 However, in Ruby 3.0, the behavior of `clamp` has changed to accept `nil`. This change is not documented in the NEWS or the documentation for `clamp`, and I believe that it was not an intentional change. ~~~ % docker run -it --rm rubylang/all-ruby env ALL_RUBY_SINCE=ruby-2.4.0 ./all-ruby -e "p 5.clamp(0, nil)" ruby-2.4.0 -e:1:in `clamp': comparison of Integer with nil failed (ArgumentError) from -e:1:in `<main>' exit 1 ... ruby-2.7.8 -e:1:in `clamp': comparison of Integer with nil failed (ArgumentError) from -e:1:in `<main>' exit 1 ruby-3.0.0-preview1 5 ... ruby-3.2.2 5 ~~~ It seems that https://github.com/ruby/ruby/commit/a93da4970be44a473b7b42e7516eb2663dece2c3 brought about this change. How about making the current behavior a specification? It has been three years since the behavior changed, and I don't see much point in prohibiting `nil` now. -- https://bugs.ruby-lang.org/

5 6

[ruby-core:115071] [Ruby master Misc#19931] to_int is not for implicit conversion?
by Dan0042 (Daniel DeLorme) 29 Nov '23

29 Nov '23

Issue #19931 has been reported by Dan0042 (Daniel DeLorme). ---------------------------------------- Misc #19931: to_int is not for implicit conversion? https://bugs.ruby-lang.org/issues/19931 * Author: Dan0042 (Daniel DeLorme) * Status: Open * Priority: Normal ---------------------------------------- While reviewing some implicit vs explicit conversion concepts, I discovered that arithmetic operations do not perform the implicit conversion I expected from #to_int ```ruby o = Object.new def o.to_int; 1; end 1 + o #TypeError ``` I understand there's the whole #coerce thing for numbers, but I had expected #to_int to fit neatly into this and cause the object to be implicitly coerced to Integer. So basically I thought that #to_i was for explicit conversion and #to_int for implicit conversion; is that not the case? Most of the internet seems to think that (to_int : to_i) relationship is like (to_str : to_s). But I can't seems to find authoritative documentation on the topic. -- https://bugs.ruby-lang.org/

9 15

[ruby-core:115517] [Ruby master Bug#20026] Ruby doesn't throw a syntax error when rescuing with ||
by arian (Arian Faurtosh) 29 Nov '23

29 Nov '23

Issue #20026 has been reported by arian (Arian Faurtosh). ---------------------------------------- Bug #20026: Ruby doesn't throw a syntax error when rescuing with || https://bugs.ruby-lang.org/issues/20026 * Author: arian (Arian Faurtosh) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.0 (2022-12-25 revision a528908271) [arm64-darwin23] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- We had a coworker new to ruby try an interesting syntax for rescue that doesn't result in a syntax error, and works partially. Why does ruby allow the logical OR || operator, is there a purpose for this? If not this feels like it should be a syntax error, instead of resulting in partially working code. ``` ruby class FooError < StandardError; end class BarError < StandardError; end # works begin raise FooError rescue FooError || BarError => e puts "rescued #{e.class}" end # doesn't work begin raise FooError rescue FooError || BarError => e puts "rescued #{e.class}" end ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:115519] [Ruby master Bug#18886] Struct aref and aset don't trigger any tracepoints.
by jeremyevans0 (Jeremy Evans) 28 Nov '23

28 Nov '23

Issue #18886 has been updated by jeremyevans0 (Jeremy Evans). mame (Yusuke Endoh) wrote in #note-7: > @jeremyevans0 Could you measure the overhead? Using the benchmark in the pull request, the pull request seems reliably ~5% faster in my testing for the member reader method, but mixed for other cases (sometimes up to 3% faster/slower depending on run). I don't have any explanation as to why it would be faster, so I'm going to assume that the difference is still within the margin of error. I don't think this will affect performance unless TracePoint is used, because the same method caching is done in both cases. ---------------------------------------- Bug #18886: Struct aref and aset don't trigger any tracepoints. https://bugs.ruby-lang.org/issues/18886#change-105448 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Assignee: ko1 (Koichi Sasada) * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Given the following program, `thing.name` and `thing.shape` don't trigger `c_call` trace points (or any trace points actually). ```ruby pp RUBY_VERSION trace_point = TracePoint.new(:line, :call, :c_call, :a_call) do |trace| puts trace.event if trace.event == :call # Ruby doesn't always mark call-sites in sub-expressions, so we use this approach to compute a call site and mark it: if location = caller_locations(2, 1).first and path = location.path puts "> #{path}:#{location.lineno}:#{trace.event}" end end if path = trace.path puts "= #{path}:#{trace.lineno}:#{trace.event}" end end trace_point.enable # This will trigger call trace points class Thing def name :cat end def shape :square end end thing = Thing.new # Thing = Struct.new(:name, :shape) # thing = Thing.new(:cat, :rectangle) [ name: thing.name, shape: thing.shape, ] ``` ## Current HEAD ``` = ../test.rb:30:line: = ../test.rb:30:c_call:new = ../test.rb:30:c_call:inherited = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:const_added = ../test.rb:31:line: = ../test.rb:31:c_call:new = ../test.rb:31:c_call:initialize = ../test.rb:34:line: ``` ## Proposed PR ``` = ../test.rb:30:line: = ../test.rb:30:c_call:new = ../test.rb:30:c_call:inherited = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:const_added = ../test.rb:31:line: = ../test.rb:31:c_call:new = ../test.rb:31:c_call:initialize = ../test.rb:34:line: = ../test.rb:34:c_call:name = ../test.rb:35:c_call:shape ``` The reason is the internal implementation of struct doesn't have trace point instrumentation in `vm_call_opt_struct_aset` or `vm_call_opt_struct_aref`. Proposed fix: https://github.com/ruby/ruby/pull/6071 but this would need a review, maybe @jeremyevans0 and @ko1 can help. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115502] [Ruby master Bug#8299] Minor error in float parsing
by naruse (Yui NARUSE) 28 Nov '23

28 Nov '23

Issue #8299 has been updated by naruse (Yui NARUSE). Status changed from Assigned to Closed hdtoa has the rounding logic, but it doesn't work well on x87, but no one use x87 now. This issue is resolved. ---------------------------------------- Bug #8299: Minor error in float parsing https://bugs.ruby-lang.org/issues/8299#change-105431 * Author: bobjalex (Bob Alexander) * Status: Closed * Priority: Normal * Assignee: nobu (Nobuyoshi Nakada) * ruby -v: trunk ---------------------------------------- I encountered a float that either parses [slightly] differently (or converts to string differently) in Ruby than it does in Python or Java. This looks like a Ruby bug since the result "looks" incorrect. It is easily reproduced by entering the magic number (-1.1505945E-5) into irb. It behaves the same in 2.0 and 1.9. I'm using Windows. Below is an irb session that demonstrates. Also included are JRuby and Python trials that show better behavior. This issue is not causing me any problems, but just in case someone there is interested in looking into it... Bob >ruby -v ruby 2.0.0p0 (2013-02-24) [i386-mingw32] >irb irb(main):001:0> RUBY_VERSION => "2.0.0" irb(main):002:0> -1.1505945E-5 => -1.1505945000000001e-05 >ruby19 -v ruby 1.9.3p392 (2013-02-22) [i386-mingw32] >irb19 irb(main):001:0> RUBY_VERSION => "1.9.3" irb(main):002:0> -1.1505945E-5 => -1.1505945000000001e-05 irb(main):002:0> >jirb irb(main):001:0> -1.1505945E-5 => -1.1505945e-05 >python Python 2.7.4rc1 (default, Mar 24 2013, 14:34:32) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> -1.1505945E-5 -1.1505945e-05 >>> repr(-1.1505945E-5) '-1.1505945e-05' -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115355] [Ruby master Bug#20003] Array#rassoc does not preform implicit conversion
by temabolshakov (Tema Bolshakov) 28 Nov '23

28 Nov '23

Issue #20003 has been reported by temabolshakov (Tema Bolshakov). ---------------------------------------- Bug #20003: Array#rassoc does not preform implicit conversion https://bugs.ruby-lang.org/issues/20003 * Author: temabolshakov (Tema Bolshakov) * Status: Open * Priority: Normal * ruby -v: 3.2.2 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- There is a difference between behaviour of Array#assoc and Array#rassoc. The first one performs implicit conversion (calls #to_ary) while the former does not. ``` ruby class ArrayConvertible def initialize(*values) @values = values; end def to_ary @values end end s1 = [1, 2] s2 = ArrayConvertible.new(2, 3) a = [s1, s2] ``` The `a.assoc(2)` call returns `[2, 3]` as expected. However, `a.rassoc(3)` returns `nil` **Expected behaviour**: `a.rassoc(3)` returns `[2, 3]` in such cases. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:115499] [Ruby master Bug#9189] Build failure on Windows in case of nonascii TEMP environment.
by nobu (Nobuyoshi Nakada) 28 Nov '23

28 Nov '23

Issue #9189 has been updated by nobu (Nobuyoshi Nakada). Backport changed from 1.9.3: DONTNEED, 2.0.0: REQUIRED to 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN pcai (Peter Cai) wrote in #note-13: > I'm unable to reproduce. Windows presents an ascii-safe alias of the TEMP folder for me so I can't seem to test the handling: Thank you for testing. Does it work after `set TEMP=C:\Users\희섭\tmp`? ---------------------------------------- Bug #9189: Build failure on Windows in case of nonascii TEMP environment. https://bugs.ruby-lang.org/issues/9189#change-105428 * Author: phasis68 (Heesob Park) * Status: Assigned * Priority: Normal * ruby -v: ruby 2.1.0dev (2013-11-30 trunk 43936) [i386-mingw32] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I experienced a build failure during build extension library with trunk on Windows. make[2]: Entering directory `/c/work/ruby-2.1.0-r43936/ext/bigdecimal' generating bigdecimal-i386-mingw32.def compiling bigdecimal.c In file included from bigdecimal.c:20:0: bigdecimal.h:62:1: error: static declaration of 'labs' follows non-static declar ation make[2]: *** [bigdecimal.o] Error 1 make[2]: Leaving directory `/c/work/ruby-2.1.0-r43936/ext/bigdecimal' make[1]: *** [ext/bigdecimal/all] Error 2 make[1]: Leaving directory `/c/work/ruby-2.1.0-r43936' make: *** [build-ext] Error 2 I found the cause of this error is mkmk failure. Here is a part of mkmf.log have_func: checking for labs() in stdlib.h... -------------------- no "i686-w64-mingw32-gcc -o conftest.exe -I../../.ext/include/i386-mingw32 -I../.././include -I../.././ext/bigdecimal -D_WIN32_WINNT=0x0501 -D_FILE_OFFSET_BITS=64 -O3 -fno-omit-frame-pointer -fno-fast-math -ggdb3 -Wall -Wextra -Wno-unused-parameter -Wno-parentheses -Wno-long-long -Wno-missing-field-initializers -Wunused-variable -Wpointer-arith -Wwrite-strings -Wdeclaration-after-statement -Wimplicit-function-declaration conftest.c -L. -L../.. -L. -lmsvcrt-ruby210-static -lshell32 -lws2_32 -liphlpapi -limagehlp -lshlwapi " This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. Cannot create temporary file in C:\Users\??苑?AppData\Local\Temp\: Invalid argument The TEMP environment varable is C:\work\ruby-2.1.0-r43936>set TEMP TEMP=C:\Users\희섭\AppData\Local\Temp It seems that miniruby cannot handle encoding properly. C:\work\ruby-2.1.0-r43936>miniruby -ve "p ENV['TEMP']" ruby 2.1.0dev (2013-11-30 trunk 43936) [i386-mingw32] "C:\\Users\\\xED\x9D\xAC\xEC\x84\xAD\\AppData\\Local\\Temp" C:\work\ruby-2.1.0-r43936>miniruby.exe -ve "p ENV['TEMP'].encoding" ruby 2.1.0dev (2013-11-30 trunk 43936) [i386-mingw32] #<Encoding:ASCII-8BIT> Whereas, the final ruby can handle encoding properly. C:\work>ruby -ve "p ENV['TEMP']" ruby 2.1.0dev (2013-11-30 trunk 43923) [i386-mingw32] "C:\\Users\\희섭\\AppData\\Local\\Temp" C:\work>ruby -ve "p ENV['TEMP'].encoding" ruby 2.1.0dev (2013-11-30 trunk 43923) [i386-mingw32] #<Encoding:CP949> -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115498] [Ruby master Feature#18551] Make `Range#reverse_each` to raise an exception if endless
by mame (Yusuke Endoh) 28 Nov '23

28 Nov '23

Issue #18551 has been updated by mame (Yusuke Endoh). In the previous dev meething, matz accepted this. I will merge the PR ---------------------------------------- Feature #18551: Make `Range#reverse_each` to raise an exception if endless https://bugs.ruby-lang.org/issues/18551#change-105427 * Author: kyanagi (Kouhei Yanagita) * Status: Open * Priority: Normal ---------------------------------------- https://github.com/ruby/ruby/pull/5498 Currently, `Range#reverse_each` for an endless range never returns. ``` % ruby -e '(1..).reverse_each { }' # never return ... ``` (This is because `Enumerable#reverse_each` tries `#to_a` and `#to_a` for an endless range comes into an infinite loop.) I think `Range#reverse_each` for an endless range should raise an exception, similar to `Range#each` for a beginless range. ``` % ruby -e '(..1).each { }' -e:1:in `each': can't iterate from NilClass (TypeError) from -e:1:in `<main>' ``` -- https://bugs.ruby-lang.org/

1 0