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

[ruby-core:111075] [Ruby master Bug#19161] Cannot compile 3.0.5 or 3.1.3 on Red Hat 7
by werebus (Matt Moretti) 25 Mar '24

25 Mar '24

Issue #19161 has been reported by werebus (Matt Moretti). ---------------------------------------- Bug #19161: Cannot compile 3.0.5 or 3.1.3 on Red Hat 7 https://bugs.ruby-lang.org/issues/19161 * Author: werebus (Matt Moretti) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- When attempting to run `make` on either the 3.0.5 or 3.1.3 release, I get the following error (I included the whole output as it's pretty short): ``` BASERUBY = /opt/ruby/bin/ruby --disable=gems CC = gcc -std=gnu11 LD = ld LDSHARED = gcc -std=gnu11 -shared CFLAGS = -O3 -fno-fast-math -ggdb3 -Wall -Wextra -Wdeprecated-declarations -Wimplicit-function-declaration -Wimplicit-int -Wpointer-arith -Wwrite-strings -Wold-style-definition -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 XCFLAGS = -D_FORTIFY_SOURCE=2 -fstack-protector-strong -fno-strict-overflow -fvisibility=hidden -fexcess-precision=standard -DRUBY_EXPORT -fPIE -I. -I.ext/include/x86_64-linux -I./include -I. -I./enc/unicode/13.0.0 CPPFLAGS = DLDFLAGS = -Wl,--compress-debug-sections=zlib -fstack-protector-strong -pie SOLIBS = -lz -lpthread -lrt -lrt -ldl -lcrypt -lm LANG = en_US.UTF-8 LC_ALL = LC_CTYPE = MFLAGS = gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44) Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. compiling ./main.c compiling dmydln.c compiling miniinit.c In file included from vm_core.h:83:0, from iseq.h:14, from mini_builtin.c:3, from miniinit.c:51: thread_pthread.h:108:43: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘struct’ RUBY_EXTERN RB_THREAD_LOCAL_SPECIFIER struct rb_execution_context_struct *ruby_current_ec; ^ In file included from iseq.h:14:0, from mini_builtin.c:3, from miniinit.c:51: vm_core.h: In function ‘rb_current_execution_context’: vm_core.h:1870:34: error: ‘ruby_current_ec’ undeclared (first use in this function) rb_execution_context_t *ec = ruby_current_ec; ^ vm_core.h:1870:34: note: each undeclared identifier is reported only once for each function it appears in miniinit.c: At top level: cc1: warning: unrecognized command line option "-Wno-tautological-compare" [enabled by default] cc1: warning: unrecognized command line option "-Wno-self-assign" [enabled by default] cc1: warning: unrecognized command line option "-Wno-parentheses-equality" [enabled by default] cc1: warning: unrecognized command line option "-Wno-constant-logical-operand" [enabled by default] cc1: warning: unrecognized command line option "-Wno-cast-function-type" [enabled by default] make: *** [miniinit.o] Error 1 ``` Both Ruby 3.0.4 and 3.1.2 build without error and pass (all but one of) the `make check` tests. I know RHEL 7 is getting to be pretty old; I suspect a factor here are the ancient build tools available to me. But... EOL for Ruby 2.7 comes before the one for RHEL 7, so I'm trying to prioritize. -- https://bugs.ruby-lang.org/

10 14

[ruby-core:117308] [Ruby master Bug#18455] `IO#close` has poor performance and difficult to understand semantics.
by ioquatix (Samuel Williams) 25 Mar '24

25 Mar '24

Issue #18455 has been updated by ioquatix (Samuel Williams). After reviewing `async-io`, it looks like `wait_readable` and `wait_writable` might not be interrupted by `close`, leading to some odd behaviour. ---------------------------------------- Bug #18455: `IO#close` has poor performance and difficult to understand semantics. https://bugs.ruby-lang.org/issues/18455#change-107449 * Author: ioquatix (Samuel Williams) * Status: Open * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- `IO#close` should be responsible for closing the file descriptor referred to by the IO instance. When dealing with buffered IO, one can also expect this to flush the internal buffers if possible. Currently, all blocking IO operations release the GVL and perform the blocking system call using `rb_thread_io_blocking_region`. The current implementation takes a file descriptor and adds an entry to the VM global `waiting_fds` list. When the operation is completed, the entry is removed from `waiting_fds`. When calling `IO#close`, this list is traversed and any threads performing blocking operations with a matching file descriptor are interrupted. The performance of this is O(number of blocking IO operations) which in practice the performance of `IO#close` can take milliseconds with 10,000 threads performing blocking IO. This performance is unacceptable. ``` ruby #!/usr/bin/env ruby require 'benchmark' class Reading def initialize @r, @w = IO.pipe @thread = Thread.new do @r.read rescue IOError # Ignore. end end attr :r attr :w attr :thread def join @thread.join end end def measure(count = 10) readings = count.times.map do Reading.new end sleep 10 duration = Benchmark.measure do readings.each do |reading| reading.r.close reading.w.close end end average = (duration.total / count) * 1000.0 pp count: count, average: sprintf("%0.2fms", average) readings.each(&:join) end measure( 10) measure( 100) measure( 1000) measure(10000) ``` In addition, the semantics of this operation are confusing at best. While Ruby programs are dealing with IO instances, the VM is dealing with file descriptors, in effect performing some internal de-duplication of IO state. In practice, this leads to strange behaviour: ``` ruby #!/usr/bin/env ruby r, w = IO.pipe r2 = IO.for_fd(r.to_i) pp r: r, r2: r2 t = Thread.new do r2.read rescue nil r2.read # EBADF end sleep 0.5 r.close t.join rescue nil pp r: r, r2: r2 # r is closed, r2 is valid but will raise EBADF on any operation. ``` In addition, this confusing behaviour extends to Ractor and state is leaked between the two: ``` ruby r, w = IO.pipe ractor = Ractor.new(r.to_i) do |fd| r2 = IO.for_fd(fd) r2.read # r2.read # EBADF end sleep 0.5 r.close pp take: ractor.take ``` I propose the following changes to simplify the semantics and improve performance: - Move the semantics of `waiting_fds` from per-fd to per-IO. This means that `IO#close` only interrupts blocking operations performed on the same IO instance rather than ANY IO which refers to the same file descriptor. I think this behaviour is easier to understand and still protects against the vast majority of incorrect usage. - Move the details of `struct rb_io_t` to `internal/io.h` so that the implementation details are not part of the public interface. ## Benchmarks Before: ``` {:count=>10, :average=>"0.19ms"} {:count=>100, :average=>"0.11ms"} {:count=>1000, :average=>"0.18ms"} {:count=>10000, :average=>"1.16ms"} ``` After: ``` {:count=>10, :average=>"0.20ms"} {:count=>100, :average=>"0.11ms"} {:count=>1000, :average=>"0.15ms"} {:count=>10000, :average=>"0.68ms"} ``` After investigating this further I found that the `rb_thread_io_blocking_region` using `ubf_select` can be incredibly slow, proportional to the number of threads. I don't know whether it's advisable but: ``` c BLOCKING_REGION(blocking_node.thread, { val = func(data1); saved_errno = errno; }, NULL /* ubf_select */, blocking_node.thread, FALSE); ``` Disabling the UBF function and relying on `read(fd, ...)`/`write(fd, ...)` blocking operations to fail when `close(fd)` is invoked might be sufficient? This needs more investigation but after making this change, we have constant-time IO#close. ``` {:count=>10, :average=>"0.13ms"} {:count=>100, :average=>"0.06ms"} {:count=>1000, :average=>"0.04ms"} {:count=>10000, :average=>"0.09ms"} ``` Which is ideally what we want. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:117305] [Ruby master Bug#20390] Issue with StringIO and chilled strings
by mdalessio (Mike Dalessio) 24 Mar '24

24 Mar '24

Issue #20390 has been reported by mdalessio (Mike Dalessio). ---------------------------------------- Bug #20390: Issue with StringIO and chilled strings https://bugs.ruby-lang.org/issues/20390 * Author: mdalessio (Mike Dalessio) * Status: Open * ruby -v: ruby 3.4.0dev (2024-03-23T16:40:17Z master 8265a7531f) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- StringIO doesn't appear to handle chilled strings in a backwards-compatible way after 12be40ae ```ruby require "stringio" sio = StringIO.new("") sio.write("hello") ``` When not specifying a value for `frozen-string-literal`, the empty string is chilled so I would expect to get a warning but also expect the write to complete. Instead, the write fails as if the string is frozen: ``` ruby 3.4.0dev (2024-03-23T16:40:17Z master 8265a7531f) [x86_64-linux] ./issue-stringio-frozen.rb:8:in 'StringIO#write': not opened for writing (IOError) from ./issue-stringio-frozen.rb:8:in '<main>' ``` cc @byroot @etienne -- https://bugs.ruby-lang.org/

2 2

[ruby-core:117301] [Ruby master Feature#19057] Hide implementation of `rb_io_t`.
by mame (Yusuke Endoh) 24 Mar '24

24 Mar '24

Issue #19057 has been updated by mame (Yusuke Endoh). Eric, thanks for your comment. I understand your concern about Ruby's incompatibility. Sometimes it is inevitable to introduce incompatibilities to improve a language specification (you may not agree with me here), but I believe that we shoud make reasonable efforts to avoid other incompatibilities. I am not familiar with the situation of Rack, but I have heard a rumor that the incompatibilities in Rack 3 are so large that the migration has not progressed. That's unfortunate. Also, `frozen_string_literal` change was unfortunately approved, which I personally still believe that is the wrong direction. It is really a shame to have an inconvenient and inconsistent language specification for a performance reason. I am also sorry about RubyGems MFA. I think the policy like Eric's is not very uncommon in the OSS world. I can do nothing because I am not involved in the RubyGems operation, but I hope the RubyGems team will give some consideration to a policy like yours. ---------------------------------------- Feature #19057: Hide implementation of `rb_io_t`. https://bugs.ruby-lang.org/issues/19057#change-107443 * Author: ioquatix (Samuel Williams) * Status: Assigned * 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:117220] [Ruby master Feature#19057] Hide implementation of `rb_io_t`.
by mame (Yusuke Endoh) 23 Mar '24

23 Mar '24

Issue #19057 has been updated by mame (Yusuke Endoh). Why don't you reconsider the "nested public interface" approach? From the reaction to this ticket, it is clear that forcing the "hide all the details" approach could destroy the Ruby ecosystem. And there is no need to force it because you have a more moderate alternative approach. ---------------------------------------- Feature #19057: Hide implementation of `rb_io_t`. https://bugs.ruby-lang.org/issues/19057#change-107306 * Author: ioquatix (Samuel Williams) * Status: Assigned * 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:117291] [Ruby master Bug#20388] super + ruby2_keywords isn't working
by tenderlovemaking (Aaron Patterson) 22 Mar '24

22 Mar '24

Issue #20388 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Bug #20388: super + ruby2_keywords isn't working https://bugs.ruby-lang.org/issues/20388 * Author: tenderlovemaking (Aaron Patterson) * Status: Open * Assignee: jeremyevans0 (Jeremy Evans) * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- ```ruby class A def process action, ... end end class B < A def process method_name, *args args.freeze super end ruby2_keywords(:process) end p B.new.process(:foo, bar: :baz) ``` The above code started breaking at revision 4f77d8d3 -- https://bugs.ruby-lang.org/

2 4

[ruby-core:117290] [Ruby master Feature#19057] Hide implementation of `rb_io_t`.
by k0kubun (Takashi Kokubun) 22 Mar '24

22 Mar '24

Issue #19057 has been updated by k0kubun (Takashi Kokubun). > I don't see any other realistic option. I wish there was another way. FWIW, @byroot built a fork https://github.com/shopify/pitchfork, which has a reforking feature Unicorn doesn't have, and Shopify uses that for our largest application in production. > The reliance on these gems by a significant segment of our community increases the potential impact of any unresolved issues. I'd say it's unrealistic to expect all existing users to switch to something else before the Ruby 3.4 release. For example, Sprockets v3 is much more popular than v4 ([source](https://bestgems.org/gems/sprockets)) while it was released 6 years ago and is way past its EOL. Since that version depends on the legacy interface of ERB (which I maintain), the gem's legacy interface (deprecated 6 years ago) is very much stuck, like `rb_io_t`. But I'd rather not break existing Rails applications unless it's absolutely necessary. I don't think it's more important to hide implementation details than to keep existing applications running. Since the author himself [strongly discourages the use of Unicorn](https://yhbt.net/kgio-public/20230905092243.M939104@dcvr/), users should, however, _eventually_ stop using Unicorn. For those who are looking for Unicorn alternatives, you may use Pitchfork, or Puma with 1 thread per process (for Unicorn compatibility). ---------------------------------------- Feature #19057: Hide implementation of `rb_io_t`. https://bugs.ruby-lang.org/issues/19057#change-107430 * Author: ioquatix (Samuel Williams) * Status: Assigned * 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:117289] [Ruby master Feature#19057] Hide implementation of `rb_io_t`.
by ioquatix (Samuel Williams) 22 Mar '24

22 Mar '24

Issue #19057 has been updated by ioquatix (Samuel Williams). At @mame's request, I've reverted this change. The reversion itself was straightforward, yet it does not mitigate the underlying concerns that have come to light through this work. My attempt to enhance Ruby's `IO` implementation has highlighted a vulnerability within our ecosystem: the infrequency of updates and the ambiguity surrounding future releases from the maintainers of essential gems, such as `unicorn`. This predicament places the Ruby community in a precarious position, not just in terms of adopting improvements but more importantly, in our ability to respond to security vulnerabilities. The reliance on these gems by a significant segment of our community intensifies the potential impact of any unresolved issues. @mame if you truly believe a malfunctioning `unicorn` can "destroy the Ruby ecosystem", then I fear we have bigger problems that need to be discussed - it would only take a security issue or two to put us all companies that depend on `unicorn` in a very difficult position. Because I care about the future of Ruby, I made the decision to make a community fork of `unicorn` as I don't see any other realistic option. ---------------------------------------- Feature #19057: Hide implementation of `rb_io_t`. https://bugs.ruby-lang.org/issues/19057#change-107429 * Author: ioquatix (Samuel Williams) * Status: Assigned * 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:116819] [Ruby master Feature#20275] Avoid extra backtrace entries for rescue and ensure
by Eregon (Benoit Daloze) 21 Mar '24

21 Mar '24

Issue #20275 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Feature #20275: Avoid extra backtrace entries for rescue and ensure https://bugs.ruby-lang.org/issues/20275 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal ---------------------------------------- From https://bugs.ruby-lang.org/issues/19117#note-48: ```ruby def raise_nested_exceptions raise "First error" rescue begin raise "Second error" rescue raise "Third error" end end raise_nested_exceptions ``` Current: ``` -:7:in 'Object#raise_nested_exceptions': Third error (RuntimeError) from -:4:in 'Object#raise_nested_exceptions' from -:1:in 'Object#raise_nested_exceptions' from -:11:in '<main>' -:5:in 'Object#raise_nested_exceptions': Second error (RuntimeError) from -:1:in 'Object#raise_nested_exceptions' from -:11:in '<main>' -:2:in 'Object#raise_nested_exceptions': First error (RuntimeError) from -:11:in '<main>' ``` The above repeated backtrace entries for `Object#raise_nested_exceptions` are because of CRuby implementation details. It seems best to hide them because they do not help understanding the program, and semantically there is no (method or proc) call on line 1 or 4. Proposed: ``` -:7:in 'Object#raise_nested_exceptions': Third error (RuntimeError) from -:11:in '<main>' -:5:in 'Object#raise_nested_exceptions': Second error (RuntimeError) from -:11:in '<main>' -:2:in 'Object#raise_nested_exceptions': First error (RuntimeError) from -:11:in '<main>' ``` We can see TruffleRuby already behave this way, most likely because they do not use an extra frame for `rescue`. It is definitely useful to have the same backtrace on different Ruby implementations as lots of tests rely on this. TruffleRuby 23.1.2: ``` -:7:in `raise_nested_exceptions': Third error (RuntimeError) from -:11:in `<main>' -:5:in `raise_nested_exceptions': Second error (RuntimeError) from -:11:in `<main>' -:2:in `raise_nested_exceptions': First error (RuntimeError) from -:11:in `<main>' ``` JRuby 9.4.5.0: ``` RuntimeError: Third error raise_nested_exceptions at -:7 <main> at -:11 RuntimeError: Second error raise_nested_exceptions at -:5 <main> at -:11 RuntimeError: First error raise_nested_exceptions at -:2 <main> at -:11 ``` -- https://bugs.ruby-lang.org/

5 7

[ruby-core:117286] [Ruby master Feature#19117] Include the method owner in backtraces, not just the method name
by Eregon (Benoit Daloze) 21 Mar '24

21 Mar '24

Issue #19117 has been updated by Eregon (Benoit Daloze). Assignee changed from Eregon (Benoit Daloze) to mame (Yusuke Endoh) ---------------------------------------- Feature #19117: Include the method owner in backtraces, not just the method name https://bugs.ruby-lang.org/issues/19117#change-107412 * Author: byroot (Jean Boussier) * Status: Closed * Assignee: mame (Yusuke Endoh) * Target version: 3.4 ---------------------------------------- ``` module Foo class Bar def inspect 1 + '1' end end end p Foo::Bar.new ``` This code produce the following backtrace: ``` /tmp/foo.rb:4:in `+': String can't be coerced into Integer (TypeError) from /tmp/foo.rb:4:in `inspect' from /tmp/foo.rb:9:in `p' from /tmp/foo.rb:9:in `<main>' ``` This works, but on large codebases and large backtraces the method name isn't always all that revealing, most of the time you need to open many of the locations listed in the backtrace to really understand what is going on. I propose that we also include the owner name: ``` /tmp/foo.rb:4:in `Integer#+': String can't be coerced into Integer (TypeError) from /tmp/foo.rb:4:in `Foo::Bar#inspect' from /tmp/foo.rb:9:in `Kernel#p' from /tmp/foo.rb:9:in `<main>' ``` I believe that in many case it would allow to much better understand the backtrace without having to jump back and forth between it and the source code. This is inspired by @ivoanjo 's `backtracie` gem: https://github.com/ivoanjo/backtracie -- https://bugs.ruby-lang.org/

1 0