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

[ruby-core:116198] [Ruby master Feature#19057] Hide implementation of `rb_io_t`.
by ioquatix (Samuel Williams) 14 Jan '24

14 Jan '24

Issue #19057 has been updated by ioquatix (Samuel Williams). Update from 5 months ago: - unicorn has merged a fix but it is not released: https://yhbt.net/unicorn.git/63c85c4282d15e22bd32a905883d2d0e149619d1/s/ - kgio has merged a fix but it is not released: https://yhbt.net/kgio.git/dbf5290cf9f89174f6b35a597af9a4226633d79b/s/ - raindrops merged a fix but it is not released: https://yhbt.net/raindrops.git/b3212417cc3e7cc44aa9e1ffe89b0d62ef3fdab5/s/ ---------------------------------------- Feature #19057: Hide implementation of `rb_io_t`. https://bugs.ruby-lang.org/issues/19057#change-106214 * Author: ioquatix (Samuel Williams) * Status: Assigned * Priority: Normal * Assignee: ioquatix (Samuel Williams) * Target version: 3.4 ---------------------------------------- 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/

2 1

[ruby-core:116206] [Ruby master Bug#18805] IO::Buffer is inconsistent when returning a string from an empty buffer
by ioquatix (Samuel Williams) 14 Jan '24

14 Jan '24

Issue #18805 has been updated by ioquatix (Samuel Williams). Status changed from Open to Closed Fixed in https://github.com/ruby/ruby/commit/c5cf4d4e129f64cb69aaf0a829aed068ef1943c4 ---------------------------------------- Bug #18805: IO::Buffer is inconsistent when returning a string from an empty buffer https://bugs.ruby-lang.org/issues/18805#change-106225 * Author: procmarco (Marco Concetto Rudilosso) * Status: Closed * Priority: Normal * Assignee: ioquatix (Samuel Williams) * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- I’ve been using `IO::Buffer` and I found it to be slightly inconsistent when it comes to returning empty string for empty buffers. for example, a slice of an allocated buffer with `size = 0`, returns `""` with `get_string`, as an example: ```ruby buffer = IO::Buffer.new(5) empty_buffer = buffer.slice(0,0) puts empty_buffer.size # this prints 0 empty_buffer.get_string # this returns "" ``` but, if you create a buffer with IO::Buffer.new(0) then it stops working ```ruby empty_buffer = IO::Buffer.new(0) puts empty_buffer.size # this prints 0 empty_buffer.get_string # this raises The buffer is not allocated! (IO::Buffer::AllocationError) ``` Is this working as intended? It would be good I think to have a consistent experience where the base case (buffer with size 0) always returns an empty string. I have a prototype of a possible patch I could send upstream to fix it, which would check the size of the buffer and if 0 it would always return an empty string. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116199] [Ruby master Feature#18035] Introduce general model/semantic for immutability.
by ioquatix (Samuel Williams) 13 Jan '24

13 Jan '24

Issue #18035 has been updated by ioquatix (Samuel Williams). > If this is accepted, should Data classes all be immutable? To quote the docs: By default, it does not look like Data is considered immutable as nested values can mutate. However, this proposal would allow for immutable Data instances, e.g. ```ruby irb(main):001> Person = Data.define(:name, :age, :hobbies) => Person irb(main):002> bob = Person.new("Bob", 20, ["Ruby"]) => #<data Person name="Bob", age=20, hobbies=["Ruby"]> irb(main):003> bob.hobbies << "Fishing" => ["Ruby", "Fishing"] irb(main):004> bob => #<data Person name="Bob", age=20, hobbies=["Ruby", "Fishing"]> irb(main):005> Immutable bob => #<data Person name="Bob", age=20, hobbies=["Ruby", "Fishing"]> irb(main):006> bob.hobbies << "Biking" (irb):6:in `<main>': can't modify frozen Array: ["Ruby", "Fishing"] (FrozenError) from <internal:kernel>:187:in `loop' from -e:1:in `<main>' ``` ---------------------------------------- Feature #18035: Introduce general model/semantic for immutability. https://bugs.ruby-lang.org/issues/18035#change-106215 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal ---------------------------------------- It would be good to establish some rules around mutability, immutability, frozen, and deep frozen in Ruby. I see time and time again, incorrect assumptions about how this works in production code. Constants that aren't really constant, people using `#freeze` incorrectly, etc. I don't have any particular preference but: - We should establish consistent patterns where possible, e.g. - Objects created by `new` are mutable. - Objects created by literal are immutable. We have problems with how `freeze` works on composite data types, e.g. `Hash#freeze` does not impact children keys/values, same for Array. Do we need to introduce `freeze(true)` or `#deep_freeze` or some other method? Because of this, frozen does not necessarily correspond to immutable. This is an issue which causes real world problems. I also propose to codify this where possible, in terms of "this class of object is immutable" should be enforced by the language/runtime, e.g. ```ruby module Immutable def new(...) super.freeze end end class MyImmutableObject extend Immutable def initialize(x) @x = x end def freeze return self if frozen? @x.freeze super end end o = MyImmutableObject.new([1, 2, 3]) puts o.frozen? ``` Finally, this area has an impact to thread and fiber safe programming, so it is becoming more relevant and I believe that the current approach which is rather adhoc is insufficient. I know that it's non-trivial to retrofit existing code, but maybe it can be done via magic comment, etc, which we already did for frozen string literals. Proposed PR: https://github.com/ruby/ruby/pull/4879 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116197] [Ruby master Feature#19057] Hide implementation of `rb_io_t`.
by ioquatix (Samuel Williams) 13 Jan '24

13 Jan '24

Issue #19057 has been updated by ioquatix (Samuel Williams). Related PR: https://github.com/ruby/ruby/pull/9530 ---------------------------------------- Feature #19057: Hide implementation of `rb_io_t`. https://bugs.ruby-lang.org/issues/19057#change-106213 * Author: ioquatix (Samuel Williams) * Status: Assigned * Priority: Normal * Assignee: ioquatix (Samuel Williams) * Target version: 3.4 ---------------------------------------- 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:116196] [Ruby master Feature#18035] Introduce general model/semantic for immutability.
by ioquatix (Samuel Williams) 13 Jan '24

13 Jan '24

Issue #18035 has been updated by ioquatix (Samuel Williams). It's not just about performance, it's about providing strong interface guarantees and making sure users don't violate those guarantees accidentally. e.g. ```ruby THINGS = [1, 2, 3] def things return THINGS end # user code: my_things = things my_things << 4 # whoops - modified constant. ``` ---------------------------------------- Feature #18035: Introduce general model/semantic for immutability. https://bugs.ruby-lang.org/issues/18035#change-106212 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal ---------------------------------------- It would be good to establish some rules around mutability, immutability, frozen, and deep frozen in Ruby. I see time and time again, incorrect assumptions about how this works in production code. Constants that aren't really constant, people using `#freeze` incorrectly, etc. I don't have any particular preference but: - We should establish consistent patterns where possible, e.g. - Objects created by `new` are mutable. - Objects created by literal are immutable. We have problems with how `freeze` works on composite data types, e.g. `Hash#freeze` does not impact children keys/values, same for Array. Do we need to introduce `freeze(true)` or `#deep_freeze` or some other method? Because of this, frozen does not necessarily correspond to immutable. This is an issue which causes real world problems. I also propose to codify this where possible, in terms of "this class of object is immutable" should be enforced by the language/runtime, e.g. ```ruby module Immutable def new(...) super.freeze end end class MyImmutableObject extend Immutable def initialize(x) @x = x end def freeze return self if frozen? @x.freeze super end end o = MyImmutableObject.new([1, 2, 3]) puts o.frozen? ``` Finally, this area has an impact to thread and fiber safe programming, so it is becoming more relevant and I believe that the current approach which is rather adhoc is insufficient. I know that it's non-trivial to retrofit existing code, but maybe it can be done via magic comment, etc, which we already did for frozen string literals. Proposed PR: https://github.com/ruby/ruby/pull/4879 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116195] [Ruby master Bug#18805] IO::Buffer is inconsistent when returning a string from an empty buffer
by ioquatix (Samuel Williams) 13 Jan '24

13 Jan '24

Issue #18805 has been updated by ioquatix (Samuel Williams). As a 2nd issue was created about the similar issue, I think it's worth improving. See https://github.com/ruby/ruby/pull/9532 for the proposed changes. ---------------------------------------- Bug #18805: IO::Buffer is inconsistent when returning a string from an empty buffer https://bugs.ruby-lang.org/issues/18805#change-106211 * Author: procmarco (Marco Concetto Rudilosso) * Status: Open * Priority: Normal * Assignee: ioquatix (Samuel Williams) * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- I’ve been using `IO::Buffer` and I found it to be slightly inconsistent when it comes to returning empty string for empty buffers. for example, a slice of an allocated buffer with `size = 0`, returns `""` with `get_string`, as an example: ```ruby buffer = IO::Buffer.new(5) empty_buffer = buffer.slice(0,0) puts empty_buffer.size # this prints 0 empty_buffer.get_string # this returns "" ``` but, if you create a buffer with IO::Buffer.new(0) then it stops working ```ruby empty_buffer = IO::Buffer.new(0) puts empty_buffer.size # this prints 0 empty_buffer.get_string # this raises The buffer is not allocated! (IO::Buffer::AllocationError) ``` Is this working as intended? It would be good I think to have a consistent experience where the base case (buffer with size 0) always returns an empty string. I have a prototype of a possible patch I could send upstream to fix it, which would check the size of the buffer and if 0 it would always return an empty string. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116183] [Ruby master Bug#20181] Process.wait(-1) doesn't report exited child processes if WAITPID_USE_SIGCHLD is enabled
by stanhu (Stan Hu) 12 Jan '24

12 Jan '24

Issue #20181 has been reported by stanhu (Stan Hu). ---------------------------------------- Bug #20181: Process.wait(-1) doesn't report exited child processes if WAITPID_USE_SIGCHLD is enabled https://bugs.ruby-lang.org/issues/20181 * Author: stanhu (Stan Hu) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [aarch64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- From Ruby 2.6 to 3.2, `Process.wait(-1)` doesn't return in a timely manner if a spawned, detached process is still running. The following script exits immediately with Ruby 3.3, but hangs for 10 minutes (the length of the `sleep`) in Ruby 2.6 to 3.2: ```ruby #!/bin/env ruby Process.spawn({}, "sh -c 'sleep 600'").tap do |pid| puts "detaching PID #{pid}" Process.detach(pid) end forked_pid = fork do loop { sleep 1 } end child_waiter = Thread.new do puts "Waiting for child process to die..." # This works # puts Process.wait2(forked_pid) # The spawned process has to exit before this returns in Ruby 3.1 and 3.2 pid, status = Process.wait2(-1) puts "Exited PID: #{pid}, status: #{status}" end process_killer = Thread.new do puts "Killing #{forked_pid}" system("kill #{forked_pid}") end child_waiter.join process_killer.join ``` In Ruby 3.2, we see: ``` detaching PID 8 Waiting for child process to die... Killing 11 <process hangs here> ``` In Ruby 3.3, this exits immediately: ``` detaching PID 9 Waiting for child process to die... Killing 11 Exited PID: 11, status: pid 11 SIGTERM (signal 15) ``` However, if I switch the `Process.wait(-1)` to `Process.wait(forked_pid)`, Ruby 3.2 works fine. I've validated that this problem goes away if I disable `WAITPID_USE_SIGCHLD`: ```diff diff --git a/vm_core.h b/vm_core.h index 1cc0659700..0e7d1643fe 100644 --- a/vm_core.h +++ b/vm_core.h @@ -126,7 +126,7 @@ #endif /* define to 0 to test old code path */ -#define WAITPID_USE_SIGCHLD (RUBY_SIGCHLD || SIGCHLD_LOSSY) +#define WAITPID_USE_SIGCHLD 0 #if defined(SIGSEGV) && defined(HAVE_SIGALTSTACK) && defined(SA_SIGINFO) && !defined(__NetBSD__) # define USE_SIGALTSTACK ``` This was first reported in the Puma issue tracker (https://github.com/puma/puma/issues/3313) and another contributor documented long-standing issues with `Process.wait` in the past: https://github.com/dentarg/gists/tree/master/gists/ruby-bug-15499#ruby--pum… In Ruby 2.6, https://github.com/ruby/ruby/commit/054a412d540e7ed2de63d68da753f585ea6616c3 introduced a mechanism for `rb_waitpid` that uses `SIGCHLD` for blocking `wait` calls, and this might have introduced this bug. Ruby 2.5 doesn't appear to have this problem. In Ruby 3.3, this `SIGCHLD` implementation was dropped in https://github.com/ruby/ruby/pull/7476 and https://github.com/ruby/ruby/pull/7527, so Ruby 3.3 no longer appears affected. -- https://bugs.ruby-lang.org/

2 3

[ruby-core:115181] [Ruby master Bug#19975] ISeq#to_binary loses hidden local variable indices
by kddnewton (Kevin Newton) 12 Jan '24

12 Jan '24

Issue #19975 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #19975: ISeq#to_binary loses hidden local variable indices https://bugs.ruby-lang.org/issues/19975 * Author: kddnewton (Kevin Newton) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- When you call `RubyVM::InstructionSequence#to_a`, you get hidden local variables as the index in the stack from the top: ``` c if (rb_id2str(lid)) { rb_ary_push(locals, ID2SYM(lid)); } else { /* hidden variable from id_internal() */ rb_ary_push(locals, ULONG2NUM(iseq_body->local_table_size-i+1)); } ``` ``` rb RubyVM::InstructionSequence.compile("for foo in bar; end").to_a[13][4][2][10] # => [2] ``` When you call `RubyVM::InstructionSequence#to_binary`, it dumps hidden local variables as 0: ``` c if (id == 0 || rb_id2name(id) == NULL) { return 0; } return ibf_dump_object(dump, rb_id2sym(id)); ``` When it reads that back in and then you call `to_a`, you get `:#arg_rest`: ``` ruby RubyVM::InstructionSequence.load_from_binary(RubyVM::InstructionSequence.compile("for foo in bar; end").to_binary).to_a[13][4][2][10] # => [:"#arg_rest"] ``` This means you end up not being able to consistently look at the locals. Instead, when reading back in from binary it could replace it with the index so that it matches up with the value before it is dumped to binary. Could we do that so that `#to_a` is consistent no matter where the iseq came from? -- https://bugs.ruby-lang.org/

2 1

[ruby-core:116180] [Ruby master Bug#20179] `--with-ruby-version` configure option is not correctly applied to `rubyhdrdir`
by vo.x (Vit Ondruch) 12 Jan '24

12 Jan '24

Issue #20179 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Bug #20179: `--with-ruby-version` configure option is not correctly applied to `rubyhdrdir` https://bugs.ruby-lang.org/issues/20179 * Author: vo.x (Vit Ondruch) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I am trying to configure ruby using `--with-ruby-version=ruby3.3`. Here is the configure output: ~~~ $ /builddir/build/BUILD/ruby-3.3.0/configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --runstatedir=/run --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-compress-debug-sections=no --disable-rpath --enable-mkmf-verbose --enable-shared --with-ruby-version=ruby3.3 --enable-yjit ... snip ... --- Configuration summary for ruby version 3.3.0 * Installation prefix: /usr * exec prefix: /usr * arch: x86_64-linux * site arch: ${arch} * RUBY_BASE_NAME: ruby * enable shared: yes * ruby lib prefix: ${libdir}/${RUBY_BASE_NAME} * site libraries path: ${rubylibprefix}/${sitearch} * vendor path: ${rubylibprefix}/vendor_ruby * target OS: linux * compiler: gcc * with thread: pthread * with coroutine: amd64 * enable shared libs: yes * dynamic library ext: so * CFLAGS: ${optflags} ${debugflags} ${warnflags} * LDFLAGS: -L. -Wl,-z,relro -Wl,--as-needed \ -Wl,-z,pack-relative-relocs -Wl,-z,now \ -specs=/usr/lib/rpm/redhat/redhat-hardened-ld \ -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 \ -Wl,--build-id=sha1 -fstack-protector-strong \ -rdynamic -Wl,-export-dynamic -Wl,--no-as-needed * DLDFLAGS: -Wl,-z,relro -Wl,--as-needed \ -Wl,-z,pack-relative-relocs -Wl,-z,now \ -specs=/usr/lib/rpm/redhat/redhat-hardened-ld \ -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 \ -Wl,--build-id=sha1 * optflags: -O3 -fno-fast-math * debugflags: -ggdb3 * warnflags: -Wall -Wextra -Wdeprecated-declarations \ -Wdiv-by-zero -Wduplicated-cond \ -Wimplicit-function-declaration -Wimplicit-int \ -Wpointer-arith -Wwrite-strings \ -Wold-style-definition -Wimplicit-fallthrough=0 \ -Wmissing-noreturn -Wno-cast-function-type \ -Wno-constant-logical-operand -Wno-long-long \ -Wno-missing-field-initializers \ -Wno-overlength-strings \ -Wno-packed-bitfield-compat \ -Wno-parentheses-equality -Wno-self-assign \ -Wno-tautological-compare -Wno-unused-parameter \ -Wno-unused-value -Wsuggest-attribute=format \ -Wsuggest-attribute=noreturn -Wunused-variable \ -Wmisleading-indentation -Wundef * strip command: strip -S -x * install doc: rdoc * YJIT support: yes * RJIT support: yes * man page type: doc --- ~~~ However, the option is not applied consistently, especially the `rubyhdrdir` stands out: ~~~ $ find . -name \*ruby3.3\* ./usr/lib64/ruby/ruby3.3 ./usr/lib64/ruby/site_ruby/ruby3.3 ./usr/lib64/ruby/vendor_ruby/ruby3.3 ./usr/lib64/ruby/gems/ruby3.3 ./usr/lib64/ruby/gems/ruby3.3/extensions/x86_64-linux/ruby3.3 ./usr/include/ruby-ruby3.3 ./usr/share/ri/ruby3.3 ~~~ The correct path should be IMHO `./usr/include/ruby3.3`. I can likely workaround it by `--with-rubyhdrdir`, but I think this should behave consistently. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115212] [Ruby master Bug#19983] Nested * seems incorrect
by Eregon (Benoit Daloze) 11 Jan '24

11 Jan '24

Issue #19983 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #19983: Nested * seems incorrect https://bugs.ruby-lang.org/issues/19983 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-10-30T09:27:06Z master 14fa5e39d7) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ``` $ ruby -v -e 'def m(*); ->(*) { p(*) }; end; m(1).call(2)' ruby 3.3.0dev (2023-10-30T09:27:06Z master 14fa5e39d7) [x86_64-linux] 1 ``` But I would expect `2`. Much like: ``` $ ruby -e 'def m(a); ->(a) { p(a) }; end; m(1).call(2)' ruby 3.3.0dev (2023-10-30T09:27:06Z master 14fa5e39d7) [x86_64-linux] 2 ``` i.e. the inner variable should win. -- https://bugs.ruby-lang.org/

4 8