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

[ruby-core:114292] [Ruby master Bug#19025] Ripper cannot parse syntax ok code that has numbered parameters
by usa (Usaku NAKAMURA) 26 Jul '23

26 Jul '23

Issue #19025 has been updated by usa (Usaku NAKAMURA). Backport changed from 3.0: REQUIRED, 3.1: DONE, 3.2: DONE to 3.0: REQUIRED, 3.1: REQUIRED, 3.2: DONE reverted on ruby_3_1 because the test is not passed... ---------------------------------------- Bug #19025: Ripper cannot parse syntax ok code that has numbered parameters https://bugs.ruby-lang.org/issues/19025#change-103990 * Author: tompng (tomoya ishida) * Status: Closed * Priority: Normal * ruby -v: ruby 3.2.0dev (2022-09-22T02:42:57Z :detached: 830b2e217b) [x86_64-linux] * Backport: 3.0: REQUIRED, 3.1: REQUIRED, 3.2: DONE ---------------------------------------- Ruby says `p { a = 0; [_1, _1 **2] }` is syntax ok, Ripper says syntax error ~~~ruby code = 'p { a = 0; [_1, _1 **2] }' eval(code) #=> nil (Syntax OK) Ripper.sexp(code) #=> nil (Syntax Error) ~~~ Other similar codes. maybe not a bug ~~~ruby p { a = 0; [a **2] } # Syntax OK p { a = 0; [_1 **2] } # Syntax Error p { a = 0; [a, _1 **2] } # Syntax Error p { a = 0; [_1, _1 **2] } # Syntax OK, Ripper.sexp says Syntax Error ~~~ -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114288] [Ruby master Bug#19025] Ripper cannot parse syntax ok code that has numbered parameters
by usa (Usaku NAKAMURA) 25 Jul '23

25 Jul '23

Issue #19025 has been updated by usa (Usaku NAKAMURA). Backport changed from 3.0: REQUIRED, 3.1: REQUIRED, 3.2: DONE to 3.0: REQUIRED, 3.1: DONE, 3.2: DONE ruby_3_1 e55dde3bdddbc595be12e7184a23e729647eb989 merged revision(s) 91c004885fc75a93cadf0094fa86ec3bd0ec25f5. ---------------------------------------- Bug #19025: Ripper cannot parse syntax ok code that has numbered parameters https://bugs.ruby-lang.org/issues/19025#change-103984 * Author: tompng (tomoya ishida) * Status: Closed * Priority: Normal * ruby -v: ruby 3.2.0dev (2022-09-22T02:42:57Z :detached: 830b2e217b) [x86_64-linux] * Backport: 3.0: REQUIRED, 3.1: DONE, 3.2: DONE ---------------------------------------- Ruby says `p { a = 0; [_1, _1 **2] }` is syntax ok, Ripper says syntax error ~~~ruby code = 'p { a = 0; [_1, _1 **2] }' eval(code) #=> nil (Syntax OK) Ripper.sexp(code) #=> nil (Syntax Error) ~~~ Other similar codes. maybe not a bug ~~~ruby p { a = 0; [a **2] } # Syntax OK p { a = 0; [_1 **2] } # Syntax Error p { a = 0; [a, _1 **2] } # Syntax Error p { a = 0; [_1, _1 **2] } # Syntax OK, Ripper.sexp says Syntax Error ~~~ -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113266] [Ruby master Bug#19602] `PLATFORM_GET_INC` is broken unless unaligned word access is allowed
by nobu (Nobuyoshi Nakada) 25 Jul '23

25 Jul '23

Issue #19602 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #19602: `PLATFORM_GET_INC` is broken unless unaligned word access is allowed https://bugs.ruby-lang.org/issues/19602 * Author: nobu (Nobuyoshi Nakada) * Status: Closed * Priority: Normal * Backport: 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED ---------------------------------------- Please backport regint.h part of commit:git|fac814c2dc31afef272b45392a7389ef0bfa3a4f. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:114286] [Ruby master Bug#19084] Using `IO::Buffer` to change an extended String affects other Strings sharing the same buffer
by usa (Usaku NAKAMURA) 25 Jul '23

25 Jul '23

Issue #19084 has been updated by usa (Usaku NAKAMURA). Backport changed from 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: REQUIRED, 3.2: DONE to 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: DONE, 3.2: DONE ruby_3_1 3799270ec27b1267cd9923dae00bcb3955f7e061 merged revision(s) bd786e78969f9d4a8699376ceafe10934b6ad533. ---------------------------------------- Bug #19084: Using `IO::Buffer` to change an extended String affects other Strings sharing the same buffer https://bugs.ruby-lang.org/issues/19084#change-103982 * Author: jemmai (Jemma Issroff) * Status: Closed * Priority: Normal * ruby -v: master * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: DONE, 3.2: DONE ---------------------------------------- When two extended Strings share a buffer, and one String's buffer changes, it currently affects the other String's buffer. Here is a snippet to demonstrate this: ``` string = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" other_string = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" IO::Buffer.for(string) do |buffer| buffer.set_value(:U8, 0, "*".ord) end other_string[0] == "a" # => false ``` [Here is a PR which adds the above example as a test](https://github.com/ruby/ruby/pull/6630), and is currently failing CI. (cc @ioquatix) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112948] [Ruby master Bug#19543] Resizing IO::Buffer to zero bytes fails
by hanazuki (Kasumi Hanazuki) 25 Jul '23

25 Jul '23

Issue #19543 has been reported by hanazuki (Kasumi Hanazuki). ---------------------------------------- Bug #19543: Resizing IO::Buffer to zero bytes fails https://bugs.ruby-lang.org/issues/19543 * Author: hanazuki (Kasumi Hanazuki) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-03-20T04:02:21Z master 7f696b8859) [x86_64-linux] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ``` irb(main):001:0> IO::Buffer.new(1).resize(0) /home/kasumi/.local/src/github.com/ruby/ruby/-e:1: warning: IO::Buffer is experimental and both the Ruby and C interface may change in the future! /home/kasumi/.local/src/github.com/ruby/ruby/-e:1: [BUG] rb_sys_fail(rb_io_buffer_resize:realloc) - errno == 0 ruby 3.3.0dev (2023-03-20T04:02:21Z master 7f696b8859) [x86_64-linux] # full trace is attached to this ticket ``` `IO::Buffer#resize(0)` will result in calling `realloc(data->base, size)` with size = 0 in [rb_io_buffer_resize](https://bugs.ruby-lang.org/projects/ruby-master/reposi…. Zero-sized `realloc` is deprecated in C (and will be UB in C23). ---Files-------------------------------- bug.txt (40 KB) -- https://bugs.ruby-lang.org/

4 5

[ruby-core:111698] [Ruby master Bug#19318] Float#round rounds incorrectly for some cases
by Eregon (Benoit Daloze) 25 Jul '23

25 Jul '23

Issue #19318 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #19318: Float#round rounds incorrectly for some cases https://bugs.ruby-lang.org/issues/19318 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED ---------------------------------------- This was discovered by @aardvark179. The following spec in `spec/ruby/core/float/round_spec.rb` fails on CRuby: ```ruby ruby_bug "", ""..."3.3" do # These numbers are neighbouring floating point numbers round a # precise value. They test that the rounding modes work correctly # round that value and precision is not lost which might cause # incorrect results. it "does not lose precision during the rounding process" do 767573.1875850001.round(5, half: nil).should eql(767573.18759) 767573.1875850001.round(5, half: :up).should eql(767573.18759) 767573.1875850001.round(5, half: :down).should eql(767573.18759) 767573.1875850001.round(5, half: :even).should eql(767573.18759) -767573.1875850001.round(5, half: nil).should eql(-767573.18759) -767573.1875850001.round(5, half: :up).should eql(-767573.18759) -767573.1875850001.round(5, half: :down).should eql(-767573.18759) -767573.1875850001.round(5, half: :even).should eql(-767573.18759) 767573.187585.round(5, half: nil).should eql(767573.18759) 767573.187585.round(5, half: :up).should eql(767573.18759) 767573.187585.round(5, half: :down).should eql(767573.18758) 767573.187585.round(5, half: :even).should eql(767573.18758) -767573.187585.round(5, half: nil).should eql(-767573.18759) -767573.187585.round(5, half: :up).should eql(-767573.18759) -767573.187585.round(5, half: :down).should eql(-767573.18758) -767573.187585.round(5, half: :even).should eql(-767573.18758) 767573.1875849998.round(5, half: nil).should eql(767573.18758) 767573.1875849998.round(5, half: :up).should eql(767573.18758) 767573.1875849998.round(5, half: :down).should eql(767573.18758) 767573.1875849998.round(5, half: :even).should eql(767573.18758) -767573.1875849998.round(5, half: nil).should eql(-767573.18758) -767573.1875849998.round(5, half: :up).should eql(-767573.18758) -767573.1875849998.round(5, half: :down).should eql(-767573.18758) -767573.1875849998.round(5, half: :even).should eql(-767573.18758) end end ``` Yet this test to the best of our knowledge is correct. This was fixed on master by @mrkn in https://github.com/ruby/ruby/pull/7023 (thanks!). The question is should we backport this? I think yes. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:112146] [Ruby master Bug#19394] cvars in instance of cloned class point to source class's cvars even after class_variable_set on clone
by jamescdavis (James Davis) 25 Jul '23

25 Jul '23

Issue #19394 has been reported by jamescdavis (James Davis). ---------------------------------------- Bug #19394: cvars in instance of cloned class point to source class's cvars even after class_variable_set on clone https://bugs.ruby-lang.org/issues/19394 * Author: jamescdavis (James Davis) * Status: Open * Priority: Normal * ruby -v: ruby 3.1.3p185 (2022-11-24 revision 1a6b16756e) [x86_64-darwin21] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- This unexpected change in behavior happens between Ruby 3.0.x and 3.1.x. In Ruby >= 3.1, when a class with a cvar is cloned (or duped), the cvar in instances of the cloned class continues to point to the source class’s cvar after the clone has its cvar updated with `class_variable_set`. In Ruby < 3.1, the cloned class instance points to the updated cvar, as expected. It seems likely that this is a bug in the [cvar cache](https://bugs.ruby-lang.org/issues/17763) introduced in Ruby 3.1. Repro: ```rb class Foo @@bar = 'bar' def print_bar puts "#{self.class.name} (from instance): #{@@bar} #{@@bar.object_id}" end end foo_bar = Foo.class_variable_get(:@@bar) puts "Foo (class_variable_get): #{foo_bar} #{foo_bar.object_id}" Foo.new.print_bar FooClone = Foo.clone FooClone.class_variable_set(:@@bar, 'bar_clone') foo_clone_bar = FooClone.class_variable_get(:@@bar) puts "FooClone (class_variable_get): #{foo_clone_bar} #{foo_clone_bar.object_id}" FooClone.new.print_bar ``` Ruby 3.0.5: ``` Foo (class_variable_get): bar 60 Foo (from instance): bar 60 FooClone (class_variable_get): bar_clone 80 FooClone (from instance): bar_clone 80 ``` Ruby 3.1.3, 3.2.0: ``` Foo (class_variable_get): bar 60 Foo (from instance): bar 60 FooClone (class_variable_get): bar_clone 80 FooClone (from instance): bar 60 ``` Something similar happens when there are multiple clones and a cvar that the source class does not have defined is set on the clones. In this case, the cvars in instances of the clones all point to the first clone’s cvar. Repro: ```rb class Foo def print_bar puts "#{self.class.name} (from instance): #{@@bar} #{@@bar.object_id}" end end Foo1 = Foo.clone Foo2 = Foo.clone Foo3 = Foo.clone Foo1.class_variable_set(:@@bar, 'bar1') Foo2.class_variable_set(:@@bar, 'bar2') Foo3.class_variable_set(:@@bar, 'bar3') foo1_bar = Foo1.class_variable_get(:@@bar) foo2_bar = Foo2.class_variable_get(:@@bar) foo3_bar = Foo3.class_variable_get(:@@bar) puts "Foo1 (class_variable_get): #{foo1_bar} #{foo1_bar.object_id}" puts "Foo2 (class_variable_get): #{foo2_bar} #{foo2_bar.object_id}" puts "Foo3 (class_variable_get): #{foo3_bar} #{foo3_bar.object_id}" Foo1.new.print_bar Foo2.new.print_bar Foo3.new.print_bar ``` Ruby 3.0.5: ``` Foo1 (class_variable_get): bar1 60 Foo2 (class_variable_get): bar2 80 Foo3 (class_variable_get): bar3 100 Foo1 (from instance): bar1 60 Foo2 (from instance): bar2 80 Foo3 (from instance): bar3 100 ``` Ruby 3.1.3, 3.2.0: ``` Foo1 (class_variable_get): bar1 60 Foo2 (class_variable_get): bar2 80 Foo3 (class_variable_get): bar3 100 Foo1 (from instance): bar1 60 Foo2 (from instance): bar1 60 Foo3 (from instance): bar1 60 ``` -- https://bugs.ruby-lang.org/

5 7

[ruby-core:113953] [Ruby master Bug#19739] Key cannot be found in a Hash when slice! method is applied to the key
by ilya.andreyuk (Ilya Andreyuk) 25 Jul '23

25 Jul '23

Issue #19739 has been reported by ilya.andreyuk (Ilya Andreyuk). ---------------------------------------- Bug #19739: Key cannot be found in a Hash when slice! method is applied to the key https://bugs.ruby-lang.org/issues/19739 * Author: ilya.andreyuk (Ilya Andreyuk) * Status: Open * Priority: Normal * ruby -v: 3.1.4 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Hello, Key cannot be found in a Hash when slice! method is applied to the key. I cannot reproduce this behaviour with sub! or gsub! methods: ``` ruby hash = {} key = "ABC OÜ" key.slice!(/ oü$/i) # key.sub!(/ oü$/i, '') # key.gsub!(/ oü$/i, '') hash[key] = true "#{key} in #{hash}: value is #{hash[key]}" => "ABC in {\"ABC\"=>true}: value is " ``` Also it seems that ruby 2.7.6 and 3.2.2 don't have this issue. -- https://bugs.ruby-lang.org/

4 8

[ruby-core:113407] [Ruby master Feature#19630] [RFC] Deprecate `Kernel.open("|command-here")` due to frequent security issues
by postmodern (Hal Brodigan) 24 Jul '23

24 Jul '23

Issue #19630 has been reported by postmodern (Hal Brodigan). ---------------------------------------- Feature #19630: [RFC] Deprecate `Kernel.open("|command-here")` due to frequent security issues https://bugs.ruby-lang.org/issues/19630 * Author: postmodern (Hal Brodigan) * Status: Open * Priority: Normal ---------------------------------------- `Kernel.open()` is the source of numerous [1] security [2] issues [3], due to the fact that it can be used to execute commands if given a String argument of the form `"|command-here"`. However, in most uses of `Kernel.open()` the developer appears to either want to open a local file, or if 'open-uri' was explicitly required open a remote URI. We should deprecate calling `Kernel.open()` with a `"|command-here"` style arguments, with a warning message instructing the developer to use `IO.popen()` instead. Eventually, support for `Kernel.open("|command-here")` could be removed completely, in favor of having the developer explicitly call `IO.popen()` or `URI.open()`. [1]: https://45w1nkv.medium.com/ruby-code-vulnerability-analysis-confirmsnssubsc… [2]: https://bishopfox.com/blog/ruby-vulnerabilities-exploits [3]: https://blog.heroku.com/identifying-ruby-ftp-cve -- https://bugs.ruby-lang.org/

11 18

[ruby-core:114270] [Ruby master Bug#19782] Ruby operators precedence inconsistency
by hurricup (Alexandr Evstigneev) 24 Jul '23

24 Jul '23

Issue #19782 has been reported by hurricup (Alexandr Evstigneev). ---------------------------------------- Bug #19782: Ruby operators precedence inconsistency https://bugs.ruby-lang.org/issues/19782 * Author: hurricup (Alexandr Evstigneev) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Unfortunately I could not find a good documentation regarding ruby operators precedence and associativity, but according to https://ruby-doc.org/3.2.2/syntax/precedence_rdoc.html `&&` has higher precedence than assignment. Meaning that `a && b = c` would be treated as `(a && b) = c` which makes a little sense, but still. But ruby 3.2.2 shows that it works as `a && (b = c)` (if I read it right): ``` def moo(a,b,c) if a && b = c end end puts RubyVM::InstructionSequence.of(method :moo).disasm ``` Gives me ``` == disasm: #<ISeq:moo@/home/hurricup/Projects/untitled/test.rb:1 (1,0)-(5,3)> (catch: false) local table (size: 3, argc: 3 [opts: 0, rest: -1, post: 0, block: -1, kw: -1@-1, kwrest: -1]) [ 3] a@0<Arg> [ 2] b@1<Arg> [ 1] c@2<Arg> 0000 getlocal_WC_0 a@0 ( 2)[LiCa] 0002 branchunless 13 0004 getlocal_WC_0 c@2 0006 dup 0007 setlocal_WC_0 b@1 0009 branchunless 13 0011 putnil 0012 leave ( 5)[Re] 0013 putnil ( 2) 0014 leave ( 5)[Re] ``` For example, perl has well documentation and same rules regarding these two ops: https://perldoc.perl.org/perlop#Operator-Precedence-and-Associativity And if you try: ``` use v5.38; my($var1, $var2, $var3) = (1,2,3); $var1 && $var2 = $var3; say $var1, $var2, $var3; ``` You will get expected: ``` Can't modify logical and (&&) in scalar assignment at /home/hurricup/Projects/untitled/test.pl line 5, near "$var3;" Execution of /home/hurricup/Projects/untitled/test.pl aborted due to compilation errors. ``` Could you please clarify this? Also would be really nice to have documentation on how precedence work, including calls without parens, like `some.thing expr` which precedence is consumed by `expr` here? -- https://bugs.ruby-lang.org/

2 2