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

[ruby-core:113096] [Ruby master Feature#19572] Proposal: New TracePoint event for rescued exceptions
by st0012 (Stan Lo) 02 Aug '23

02 Aug '23

Issue #19572 has been reported by st0012 (Stan Lo). ---------------------------------------- Feature #19572: Proposal: New TracePoint event for rescued exceptions https://bugs.ruby-lang.org/issues/19572 * Author: st0012 (Stan Lo) * Status: Open * Priority: Normal ---------------------------------------- **Summary** Support a new `rescue` event type in TracePoint. When the event is triggered, `TracePoint#rescued_exception` can be used to access the exception. **Reason** Currently, TracePoint supports `raise` events, which can be helpful for debugging by showing which exception occurs at which location. By adding a `rescue` event type, we can improve the developer's debugging experience by making it easier to check where an exception is rescued. Currently, the most effective way to check where an exception is rescued involves setting a breakpoint at the exception's raised location and stepping through the code to see whether the debugger stops inside a rescue block. However, this can be a tedious process, especially in large applications with deep call stacks. By using a TracePoint event for rescue, developers can easily track exceptions as they are rescued by adding a few lines of code: ``` TracePoint.trace(:rescue) do |tp| puts "Exception rescued: #{tp.rescued_exception} at #{tp.path}:#{tp.lineno}" end ``` This new TracePoint event will also improve the `ruby/debug`'s [`ExceptionTracer`](https://github.com/ruby/debug/blob/master/lib/debug/tracer.rb#L150-L166) and provide users with a better debugging experience. -- https://bugs.ruby-lang.org/

4 4

[ruby-core:114295] [Ruby master Bug#19786] Data::define() does not work as documented
by thyresias (Thierry Lambert) 29 Jul '23

29 Jul '23

Issue #19786 has been reported by thyresias (Thierry Lambert). ---------------------------------------- Bug #19786: Data::define() does not work as documented https://bugs.ruby-lang.org/issues/19786 * Author: thyresias (Thierry Lambert) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x64-mingw-ucrt] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Not sure if this is a bug or a feature. RDoc documentation for Data::define: > define(name, *symbols) → class > define(*symbols) → class > > Defines a new Data class. > If the first argument is a string, the class is stored in Data::<name> constant. ```ruby M1 = Data.define('Measure', :amount, :unit) p M1 #=> M1 p M1.members #=> [:Measure, :amount, :unit] S1 = Struct.new('Measure', :amount, :unit) p S1 #=> Struct::Measure p S1.members #=> [:amount, :unit] ``` Unlike `Struct.new`, `Data.define` does not accept a name as first argument: it converts it to a symbol, and therefore a member. There is no trace of `Data::Measure` in the example above, while we do have `Struct::Measure`. -- https://bugs.ruby-lang.org/

4 4

[ruby-core:114298] [Ruby master Feature#19057] Hide implementation of `rb_io_t`.
by k0kubun (Takashi Kokubun) 26 Jul '23

26 Jul '23

Issue #19057 has been updated by k0kubun (Takashi Kokubun). `cool.io` is another gem broken by this feature. FYI, I filed a pull request here https://github.com/tarcieri/cool.io/pull/79. ---------------------------------------- Feature #19057: Hide implementation of `rb_io_t`. https://bugs.ruby-lang.org/issues/19057#change-103996 * Author: ioquatix (Samuel Williams) * Status: Assigned * Priority: Normal * Assignee: ioquatix (Samuel Williams) * Target version: 3.3 ---------------------------------------- In order to make improvements to the IO implementation like <https://bugs.ruby-lang.org/issues/18455>, we need to add new fields to `struct rb_io_t`. By the way, ending types in `_t` is not recommended by POSIX, so I'm also trying to rename the internal implementation to drop `_t` where possible during this conversion. Anyway, we should try to hide the implementation of `struct rb_io`. Ideally, we don't expose any of it, but the problem is backwards compatibility. So, in order to remain backwards compatibility, we should expose some fields of `struct rb_io`, the most commonly used one is `fd` and `mode`, but several others are commonly used. There are many fields which should not be exposed because they are implementation details. ## Current proposal The current proposed change <https://github.com/ruby/ruby/pull/6511> creates two structs: ```c // include/ruby/io.h #ifndef RB_IO_T struct rb_io { int fd; // ... public fields ... }; #else struct rb_io; #endif // internal/io.h #define RB_IO_T struct rb_io { int fd; // ... public fields ... // ... private fields ... }; ``` However, we are not 100% confident this is safe according to the C specification. My experience is not sufficiently wide to say this is safe in practice, but it does look okay to both myself, and @Eregon + @tenderlovemaking have both given some kind of approval. That being said, maybe it's not safe. There are two alternatives: ## Hide all details We can make public `struct rb_io` completely invisible. ```c // include/ruby/io.h #define RB_IO_HIDDEN struct rb_io; int rb_ioptr_descriptor(struct rb_io *ioptr); // accessor for previously visible state. // internal/io.h struct rb_io { // ... all fields ... }; ``` This would only be forwards compatible, and code would need to feature detect like this: ```c #ifdef RB_IO_HIDDEN #define RB_IOPTR_DESCRIPTOR rb_ioptr_descriptor #else #define RB_IOPTR_DESCRIPTOR(ioptr) rb_ioptr_descriptor(ioptr) #endif ``` ## Nested public interface Alternatively, we can nest the public fields into the private struct: ```c // include/ruby/io.h struct rb_io_public { int fd; // ... public fields ... }; // internal/io.h #define RB_IO_T struct rb_io { struct rb_io_public public; // ... private fields ... }; ``` ## Considerations I personally think the "Hide all details" implementation is the best, but it's also the lest compatible. This is also what we are ultimately aiming for, whether we decide to take an intermediate "compatibility step" is up to us. I think "Nested public interface" is messy and introduces more complexity, but it might be slightly better defined than the "Current proposal" which might create undefined behaviour. That being said, all the tests are passing. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114293] [Ruby master Bug#11064] #singleton_methods for objects with special singleton_class returns an empty array
by matz (Yukihiro Matsumoto) 26 Jul '23

26 Jul '23

Issue #11064 has been updated by matz (Yukihiro Matsumoto). Sorry for being late. I accept the behavior of the [pul-request](https://github.com/ruby/ruby/pull/7973). Matz. ---------------------------------------- Bug #11064: #singleton_methods for objects with special singleton_class returns an empty array https://bugs.ruby-lang.org/issues/11064#change-103991 * Author: rbjl (Jan Lelis) * Status: Open * Priority: Normal * ruby -v: ruby 2.2.1p85 (2015-02-26 revision 49769) [x86_64-linux] * Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN ---------------------------------------- ~~~ def nil.bla 42 end # works nil.bla #=> 42 nil.singleton_method(:bla) #=> #<Method: NilClass#bla> NilClass.instance_methods.include? :bla #=> true # does not work nil.singleton_methods #=> [] ~~~ -- https://bugs.ruby-lang.org/

1 0

[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