Issue #18894 has been updated by AMomchilov (Alexander Momchilov).
`#make_shareable` sounds like it's an alias for `Ractor.make_shareable`. Callbacks tend to be past tense, how about `#made_shareable`?
----------------------------------------
Feature #18894: Object#make_shareable
https://bugs.ruby-lang.org/issues/18894#change-103394
* Author: chucke (Tiago Cardoso)
* Status: Open
* Priority: Normal
----------------------------------------
I'm proposing a callback method for when one calls `Ractor.make_shareable(obj)`, the same way `Marshal.dump(obj)` calls `obj.marshal_dump`.
A lot of use cases in the wild involve a quick initialization of an object, only for some more heavy initializattion to be lazily called the first time an operation is called. An example in stdlib is `Resolv::Hosts`, which calls `lazy_initialize` on certains calls to resolve a name. Given that `Resolv` has a default resolver, this is unusable in ractors, due this "lazy" thing. Having a callback would allow to eager-load such an object, thereby making the default resolver usable with ractors.
--
https://bugs.ruby-lang.org/
Issue #19197 has been reported by AMomchilov (Alexander Momchilov).
----------------------------------------
Feature #19197: Add Exception#root_cause
https://bugs.ruby-lang.org/issues/19197
* Author: AMomchilov (Alexander Momchilov)
* Status: Open
* Priority: Normal
----------------------------------------
## Description
I would like to add a `#root_cause` method to `Exception`.
It returns the last exception in linked-list of causality chain, that is, the original exception (whose own `cause` is `nil`).
## Example
```ruby
e = begin
raise 'a' # This is the root cause
rescue => a
begin
raise 'b'
rescue => b
begin
raise 'c' # This is the outermost cause assigned to `e`
rescue => c
c
end
end
end
p(e) # => #<RuntimeError: c>
p(e.cause) # => #<RuntimeError: b>
p(e.cause.cause) # => #<RuntimeError: a>
p(e.cause.cause.cause) # => nil
p(e.root_cause) # => #<RuntimeError: a>
p(e.root_cause.cause) # => nil
```
# Motivation
There are some kinds of exceptions that can occur all over the place (and might be wrapped by arbitrarily many middlemen), but are attributable to a singular global cause. For example, a database outage could raise exceptions in almost every line of business logic of an app that uses ActiveRecord models.
Fundamentally, you wouldn't want an error report for every one of these lines. You'd want to look at the root cause, and bucket all SQL-connection issues into a single report, regardless of where they surface.
### Implementation
Draft PR: https://github.com/ruby/ruby/pull/6913
--
https://bugs.ruby-lang.org/
Issue #19706 has been reported by tatzyr (Tatsuya Otsuka).
----------------------------------------
Feature #19706: Make JSON.[] support ARGF object
https://bugs.ruby-lang.org/issues/19706
* Author: tatzyr (Tatsuya Otsuka)
* Status: Open
* Priority: Normal
----------------------------------------
**Abstract**
I propose to extend the `JSON.[]` method in the `json` standard library to support `ARGF` object directly.
**Background**
Currently, the `JSON.[]` method supports parsing from a string or generating a string from an object. However, it does not directly support `ARGF`, which is often used to handle command-line input. With this extension, `ARGF` object can be effectively used with the `JSON.[]` method to parse JSON from command-line input.
**Proposal**
This proposal aims to provide a more concise way to handle JSON input than the current method, `JSON.parse(ARGF.read)`. An example usage would be: `echo '{"foo": "bar"}' | ruby -rjson -e 'puts JSON[ARGF]["foo"]'`. This will enable developers to parse JSON in a similar way to how the `jq` utility works.
**Implementation**
Here's the proposed change to `JSON.[]`:
```diff
### ext/json/lib/json/common.rb
module JSON
class << self
def [](object, opts = {})
if object.respond_to? :to_str
JSON.parse(object.to_str, opts)
+ elsif object.is_a?(ARGF.class)
+ JSON.parse(object.read, opts)
else
JSON.generate(object, opts)
end
end
end
end
```
This change checks whether the given `object` is an instance of `ARGF.class` and, if so, reads from it and parses the result as JSON. Other options like `object.respond_to? :read` or `object.is_a?(IO)` were considered, but were not chosen due to significant implications for backward compatibility.
**Evaluation & Discussion**
While this enhancement does not alter the existing behavior of `JSON.[]` for types of objects it currently handles, it would change the behavior when `ARGF` is used. This change may not be fully backward-compatible. However, it significantly simplifies the code required to parse JSON from the command line, which is a common use case.
One crucial aspect to note is that the result of `JSON[ARGF]` will change due to this modification. Currently, it returns the string `"\"ARGF\""`, but with this proposed change, it would parse the JSON content read from `ARGF` and return a Hash.
**Summary**
By extending `JSON.[]` method to directly support `ARGF`, developers will be able to more concisely handle JSON input from command line. This change, while not fully backward-compatible, will make `JSON.[]` more suitable for use cases involving command line input, thereby simplifying the required code.
I look forward to hearing your thoughts on this proposal.
--
https://bugs.ruby-lang.org/
Issue #19705 has been reported by farhan.memon(a)getsimpl.com (Md. Farhan Memon).
----------------------------------------
Bug #19705: Ruby IPAddr class accepting wrong IPv6 address string
https://bugs.ruby-lang.org/issues/19705
* Author: farhan.memon(a)getsimpl.com (Md. Farhan Memon)
* Status: Open
* Priority: Normal
* ruby -v: 3.1.3
* Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
We are middle of upgrading ruby versions v2.7.3 -> v3.1.3
One of our test cases are failing related to valid ipv6 address string, check the following
````
# ruby 2.7.3
IPAddr.new('fe80::85e:7530:69ec:9074%en0').ipv6?
=> IPAddr::InvalidAddressError (invalid address: fe80::85e:7530:69ec:9074%en0)
# ruby 3.1.3
IPAddr.new('fe80::85e:7530:69ec:9074%en0').ipv6?
=> true
````
Is it really a bug or am I missing something? Please help.
P.S. Stackoverflow link: https://stackoverflow.com/q/76380777/6548745
--
https://bugs.ruby-lang.org/
Issue #19057 has been updated by ioquatix (Samuel Williams).
I'm in favour of eventually deprecating `rb_io_t` and I think that means anything related to it.
I think deprecations can make things a little easier but I'm not against breaking things that are out of our control.
I'm happy to fix things as they come up. Today we fixed nio4r, and polyphony, along with `readline-ext` and the other `io-*` gems.
I agree, once we stop exposing `rb_io_t`, even CRuby can take the same approach (just return the `IO` value). Whether we want to or not is another question, but I imagine only a few `VALLUE io` functions are missing now.
----------------------------------------
Feature #19057: Hide implementation of `rb_io_t`.
https://bugs.ruby-lang.org/issues/19057#change-103381
* Author: ioquatix (Samuel Williams)
* Status: Assigned
* Priority: Normal
* Assignee: ioquatix (Samuel Williams)
----------------------------------------
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/
Issue #19616 has been reported by hsbt (Hiroshi SHIBATA).
----------------------------------------
Bug #19616: Remove ext/readline from Ruby 3.3
https://bugs.ruby-lang.org/issues/19616
* Author: hsbt (Hiroshi SHIBATA)
* Status: Open
* Priority: Normal
* Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
We still bundled ext/readline that is GNU Readline wrapper. But we already have reline written by pure Ruby. It's time to remove it from Ruby releases.
Motivation:
* We can skip to install readline or libedit for testing ruby language.
* I hope to reduce external dependencies from the perspective of ruby-build maintainer.
If users hope to use ext/readline, they can install it with `gem install readline-ext`.
--
https://bugs.ruby-lang.org/
Issue #19057 has been updated by Eregon (Benoit Daloze).
I am not sure there is an easier path here, IMO it's OK for some extensions to break while they test against ruby-head, and to adapt to it (and we are not close to December).
It would be nicer to deprecate first, but I am not sure how feasible is that.
It seems maybe GCC & Clang might support deprecating struct members: https://stackoverflow.com/questions/22823477/c-portable-way-to-deprecate-st…
Then we could deprecate every member of `rb_io_t`.
That seems useful, even if the warning only works on those compilers, most people would see it.
That said, even with deprecations for one release I'm pretty sure not all extensions using rb_io_t members will have migrated, so there will be some breakage anyway, just like for every deprecated thing.
But if extensions didn't migrate for more than a year, then it's really on them if they did not address it in time.
Another way could be to deprecate `GetOpenFile` (or the whole struct type if that's possible).
But that seems difficult because many `rb_io_*` functions take a rb_io_t*, e.g., `FILE *rb_io_stdio_file(rb_io_t *fptr);`, so we would then need to add a variant taking `VALUE io` for all of these (with another name).
There is less value in that, because if `rb_io_t` is opaque these functions are not really problematic, e.g. TruffleRuby could just return and cast the `io` for `GetOpenFile(io)`, and it would require larger efforts to migrate.
The last paragraph of https://bugs.ruby-lang.org/issues/19057#note-2 was mentioning similar ideas about deprecation.
----------------------------------------
Feature #19057: Hide implementation of `rb_io_t`.
https://bugs.ruby-lang.org/issues/19057#change-103379
* Author: ioquatix (Samuel Williams)
* Status: Assigned
* Priority: Normal
* Assignee: ioquatix (Samuel Williams)
----------------------------------------
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/
Issue #19057 has been updated by ioquatix (Samuel Williams).
Unfortunately this was reverted due to some extensions no longer compiling.
- https://bugs.ruby-lang.org/issues/19704
I think it's expected that some dependencies using internal details of `rb_io_t` should be fixed.
----------------------------------------
Feature #19057: Hide implementation of `rb_io_t`.
https://bugs.ruby-lang.org/issues/19057#change-103373
* Author: ioquatix (Samuel Williams)
* Status: Closed
* Priority: Normal
* Assignee: ioquatix (Samuel Williams)
----------------------------------------
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/
Issue #19704 has been reported by yahonda (Yasuo Honda).
----------------------------------------
Bug #19704: Unable to install readline-ext since 18e55fc1e1ec20e8f3166e3059e76c885fc9f8f2
https://bugs.ruby-lang.org/issues/19704
* Author: yahonda (Yasuo Honda)
* Status: Open
* Priority: Normal
* ruby -v: ruby 3.3.0dev (2023-05-30T01:02:40Z master 18e55fc1e1) [x86_64-linux]
* Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
Rails CI against Ruby 3.3.0dev fails to install readline-ext recenty.
https://buildkite.com/rails/rails/builds/96780#01886e3f-eaef-405c-b58a-e90c…
According to git bisect, it is triggered by 18e55fc1e1ec20e8f3166e3059e76c885fc9f8f2
### Steps to reproduce
Install ruby 3.3.0dev
gem install readline-ext
### Expected behavior
It should install readline-ext as the previous commit of Ruby 7ddcd0622f does.
```
$ ruby -v
ruby 3.3.0dev (2023-05-29T21:24:22Z master 7ddcd0622f) [x86_64-linux]
$ gem install readline-ext
Building native extensions. This could take a while...
Successfully installed readline-ext-0.1.5
Ignoring rbs-3.0.4 because its extensions are not built. Try: gem pristine rbs --version 3.0.4
Parsing documentation for readline-ext-0.1.5
Installing ri documentation for readline-ext-0.1.5
Done installing documentation for readline-ext after 0 seconds
1 gem installed
$
```
### Actual result
```ruby
$ ruby -v
ruby 3.3.0dev (2023-05-30T01:02:40Z master 18e55fc1e1) [x86_64-linux]
$ gem install readline-ext
Building native extensions. This could take a while...
ERROR: Error installing readline-ext:
ERROR: Failed to build gem native extension.
current directory: /home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.3.0+0/gems/readline-ext-0.1.5/ext/readline
/home/yahonda/.rbenv/versions/trunk/bin/ruby extconf.rb
checking for tgetnum() in -lncurses... yes
checking for readline/readline.h... yes
checking for readline/history.h... yes
checking for readline() in -lreadline... yes
checking for rl_getc() in stdio.h,readline/readline.h,readline/history.h... yes
checking for rl_getc_function() in stdio.h,readline/readline.h,readline/history.h... yes
checking for rl_filename_completion_function() in stdio.h,readline/readline.h,readline/history.h... yes
checking for rl_username_completion_function() in stdio.h,readline/readline.h,readline/history.h... yes
checking for rl_completion_matches() in stdio.h,readline/readline.h,readline/history.h... yes
checking for rl_refresh_line() in stdio.h,readline/readline.h,readline/history.h... yes
checking for rl_deprep_term_function in stdio.h,readline/readline.h,readline/history.h... yes
checking for rl_completion_append_character in stdio.h,readline/readline.h,readline/history.h... yes
checking for rl_completion_quote_character in stdio.h,readline/readline.h,readline/history.h... yes
checking for rl_basic_word_break_characters in stdio.h,readline/readline.h,readline/history.h... yes
checking for rl_completer_word_break_characters in stdio.h,readline/readline.h,readline/history.h... yes
checking for rl_basic_quote_characters in stdio.h,readline/readline.h,readline/history.h... yes
checking for rl_completer_quote_characters in stdio.h,readline/readline.h,readline/history.h... yes
checking for rl_filename_quote_characters in stdio.h,readline/readline.h,readline/history.h... yes
checking for rl_attempted_completion_over in stdio.h,readline/readline.h,readline/history.h... yes
checking for rl_library_version in stdio.h,readline/readline.h,readline/history.h... yes
checking for rl_editing_mode in stdio.h,readline/readline.h,readline/history.h... yes
checking for rl_line_buffer in stdio.h,readline/readline.h,readline/history.h... yes
checking for rl_point in stdio.h,readline/readline.h,readline/history.h... yes
checking for rl_char_is_quoted_p in stdio.h,readline/readline.h,readline/history.h... yes
checking for rl_event_hook in stdio.h,readline/readline.h,readline/history.h... yes
checking for rl_catch_sigwinch in stdio.h,readline/readline.h,readline/history.h... yes
checking for rl_catch_signals in stdio.h,readline/readline.h,readline/history.h... yes
checking for rl_pre_input_hook in stdio.h,readline/readline.h,readline/history.h... yes
checking for rl_special_prefixes in stdio.h,readline/readline.h,readline/history.h... yes
checking for rl_cleanup_after_signal() in stdio.h,readline/readline.h,readline/history.h... yes
checking for rl_free_line_state() in stdio.h,readline/readline.h,readline/history.h... yes
checking for rl_clear_signals() in stdio.h,readline/readline.h,readline/history.h... yes
checking for rl_set_screen_size() in stdio.h,readline/readline.h,readline/history.h... yes
checking for rl_get_screen_size() in stdio.h,readline/readline.h,readline/history.h... yes
checking for rl_vi_editing_mode() in stdio.h,readline/readline.h,readline/history.h... yes
checking for rl_emacs_editing_mode() in stdio.h,readline/readline.h,readline/history.h... yes
checking for replace_history_entry() in stdio.h,readline/readline.h,readline/history.h... yes
checking for remove_history() in stdio.h,readline/readline.h,readline/history.h... yes
checking for clear_history() in stdio.h,readline/readline.h,readline/history.h... yes
checking for rl_redisplay() in stdio.h,readline/readline.h,readline/history.h... yes
checking for rl_insert_text() in stdio.h,readline/readline.h,readline/history.h... yes
checking for rl_delete_text() in stdio.h,readline/readline.h,readline/history.h... yes
checking for rl_hook_func_t* in stdio.h,readline/readline.h,readline/history.h... yes
creating Makefile
current directory: /home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.3.0+0/gems/readline-ext-0.1.5/ext/readline
make DESTDIR\= sitearchdir\=./.gem.20230601-64629-eyixt9 sitelibdir\=./.gem.20230601-64629-eyixt9 clean
current directory: /home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.3.0+0/gems/readline-ext-0.1.5/ext/readline
make DESTDIR\= sitearchdir\=./.gem.20230601-64629-eyixt9 sitelibdir\=./.gem.20230601-64629-eyixt9
compiling readline.c
readline.c: In function ‘prepare_readline’:
readline.c:386:16: error: invalid use of incomplete typedef ‘rb_io_t’ {aka ‘struct rb_io’}
386 | if (ifp->fd < 0) {
| ^~
readline.c:395:16: error: invalid use of incomplete typedef ‘rb_io_t’ {aka ‘struct rb_io’}
395 | if (ofp->fd < 0) {
| ^~
readline.c: In function ‘readline_s_set_input’:
readline.c:565:32: error: invalid use of incomplete typedef ‘rb_io_t’ {aka ‘struct rb_io’}
565 | fd = rb_cloexec_dup(ifp->fd);
| ^~
readline.c: In function ‘readline_s_set_output’:
readline.c:601:32: error: invalid use of incomplete typedef ‘rb_io_t’ {aka ‘struct rb_io’}
601 | fd = rb_cloexec_dup(ofp->fd);
| ^~
readline.c: At top level:
cc1: note: unrecognized command-line option ‘-Wno-self-assign’ may have been intended to silence earlier diagnostics
cc1: note: unrecognized command-line option ‘-Wno-parentheses-equality’ may have been intended to silence earlier diagnostics
cc1: note: unrecognized command-line option ‘-Wno-constant-logical-operand’ may have been intended to silence earlier diagnostics
make: *** [Makefile:248: readline.o] Error 1
make failed, exit code 2
Gem files will remain installed in /home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.3.0+0/gems/readline-ext-0.1.5 for inspection.
Results logged to /home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.3.0+0/extensions/x86_64-linux/3.3.0+0-static/readline-ext-0.1.5/gem_make.out
```
--
https://bugs.ruby-lang.org/