Issue #20018 has been reported by shioimm (Misaki Shioi).
----------------------------------------
Feature #20018: Get the error codes as Socket::EAI_XXX when getaddrinfo and getnameinfo fail
https://bugs.ruby-lang.org/issues/20018
* Author: shioimm (Misaki Shioi)
* Status: Open
* Priority: Normal
----------------------------------------
Feature for implementing Happy Eyeballs version 2 (RFC 8305) in `Socket.tcp`.
### Probrem
I would like to implement Happy Eyeballs version 2 (RFC 8305) in `Socket.tcp`.
In HEv2, `EAI_ADDRFAMILY` and `EAI_AGAIN` should be ignored when `getaddrinfoo` returns them in hostname resolution. However, there is currently no way to ask `SocketError` for errors returned by `getaddrinfo`
### Proposal
I opened a PR to get errors when `getaddrinfo` and `getnameinfo` returns them.
https://github.com/ruby/ruby/pull/9018
Todo this,
- I added `Socket::ResolutionError` as a subclass of `SocketError`
- I added an attribute of `Socket::ResolutionError` to get error code via `#error_code
- I replaced `SocketError` (`rb_eSocket`) with `Socket::ResolutionError (`rb_eResolutionError`) in `rsock_raise_socket_error` because this function is only called when `getaddrinfo` and `getnameinfo` fail
- I renamed `rsock_raise_socket_error` to `rock_raise_resolution_error` for the same reason
In addition, `Socket::ResolutionError` is a subclass of `SocketError`, so it does not affect `rescue SocketError` in source codes.
--
https://bugs.ruby-lang.org/
Issue #18368 has been updated by zverok (Victor Shepelev).
@naruse Is there a chance for this change to be included in 3.3?
----------------------------------------
Feature #18368: Range#step semantics for non-Numeric ranges
https://bugs.ruby-lang.org/issues/18368#change-105569
* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
----------------------------------------
I am sorry if the question had already been discussed, can't find the relevant topic.
"Intuitively", this looks (for me) like a meaningful statement:
```ruby
(Time.parse('2021-12-01')..Time.parse('2021-12-24')).step(1.day).to_a
# ^^^^^ or just 24*60*60
```
Unfortunately, it doesn't work with "TypeError (can't iterate from Time)".
Initially it looked like a bug for me, but after digging a bit into code/docs, I understood that `Range#step` has an odd semantics of "advance the begin N times with `#succ`, and yield the result", with N being always integer:
```ruby
('a'..'z').step(3).first(5)
# => ["a", "d", "g", "j", "m"]
```
The fact that semantic is "odd" is confirmed by the fact that for Float it is redefined to do what I "intuitively" expected:
```ruby
(1.0..7.0).step(0.3).first(5)
# => [1.0, 1.3, 1.6, 1.9, 2.2]
```
(Like with [`Range#===` some time ago](https://bugs.ruby-lang.org/issues/14575), I believe that to be a strong proof of the wrong generic semantics, if for numbers the semantics needed to be redefined completely.)
Another thing to note is that "skip N elements" seem to be rather "generically Enumerable-related" yet it isn't defined on `Enumerable` (because nobody needs this semantics, typically!)
Hence, two questions:
* Can we redefine generic `Range#step` to new semantics (of using `begin + step` iteratively)? It is hard to imagine the amount of actual usage of the old behavior (with String?.. to what end?) in the wild
* If the answer is "no", can we define a new method with new semantics, like, IDK, `Range#over(span)`?
**UPD:** More examples of useful behavior (it is NOT only about core `Time` class):
```ruby
require 'active_support/all'
(1.minute..20.minutes).step(2.minutes).to_a
#=> [1 minute, 3 minutes, 5 minutes, 7 minutes, 9 minutes, 11 minutes, 13 minutes, 15 minutes, 17 minutes, 19 minutes]
require 'tod'
(Tod::TimeOfDay.parse("8am")..Tod::TimeOfDay.parse("10am")).step(30.minutes).to_a
#=> [#<Tod::TimeOfDay 08:00:00>, #<Tod::TimeOfDay 08:30:00>, #<Tod::TimeOfDay 09:00:00>, #<Tod::TimeOfDay 09:30:00>, #<Tod::TimeOfDay 10:00:00>]
require 'matrix'
(Vector[1, 2, 3]..).step(Vector[1, 1, 1]).take(3)
#=> [Vector[1, 2, 3], Vector[2, 3, 4], Vector[3, 4, 5]]
require 'unitwise'
(Unitwise(0, 'km')..Unitwise(1, 'km')).step(Unitwise(100, 'm')).map(&:to_s)
#=> ["0 km", "1/10 km", "1/5 km", "3/10 km", "2/5 km", "0.5 km", "3/5 km", "7/10 km", "4/5 km", "9/10 km", "1 km"]
```
**UPD:** Responding to discussion points:
**Q:** Matz is concerned that the proposed simple definition will be confusing with the classes where `+` is redefined as concatenation.
**A:** I believe that simplicity of semantics and ease of explaining ("it just uses `+` underneath, whatever `+` does, will be performed") will make the confusion minimal.
**Q:** Why not introduce new API requirement (like "class of range's `begin` should implement `increment` method, and then it will be used in `step`)
**A:** require *every* gem author to change *every* of their objects' behavior. For that, they should be aware of the change, consider it important enough to care, clearly understand the necessary semantics of implementation, have a resource to release a new version... Then all users of all such gems would be required to upgrade. The feature would be DOA (dead-on-arrival).
The two alternative ways I am suggesting: change the behavior of `#step` or introduce a new method with desired behavior:
1. Easy to explain and announce
2. Require no other code changes to immediately become useful
3. With something like [backports](https://github.com/marcandre/backports) or [ruby-next](https://github.com/ruby-next/ruby-next) easy to start using even in older Ruby version, making the code more expressive even before it would be possible for some particular app/compny to upgrade to (say) 3.2
All examples of behavior from the code above are real `irb` output with monkey-patched `Range#step`, demonstrating how little change will be needed to code outside of the `Range`.
--
https://bugs.ruby-lang.org/
Issue #11322 has been updated by tbsprs (Tobias Preuss).
Thanks for following up.
----------------------------------------
Feature #11322: OpenUri: RuntimeError: HTTP redirection loop
https://bugs.ruby-lang.org/issues/11322#change-105566
* Author: tbsprs (Tobias Preuss)
* Status: Closed
* Priority: Normal
* Assignee: akr (Akira Tanaka)
----------------------------------------
Trying to download [this file](http://apps.london.ca/OpenData/ShapeFiles_Zipped/2010_skateboard_parks_shp.zip) from [this website](http://www.london.ca/city-hall/open-data/Pages/Open-Data-Data-Catalogue.aspx) with [`OpenUri`](http://ruby-doc.org/stdlib-2.2.2/libdoc/open-uri/rdoc/OpenURI.html) fails with the runtime error "HTTP redirection loop".
Here is how I can reproduce the error:
~~~
> require 'open-uri'
=> true
> open('http://apps.london.ca/OpenData/ShapeFiles_Zipped/2010_skateboard_parks_shp.…')
RuntimeError: HTTP redirection loop: http://apps.london.ca/uniquesig87fdc01fb86ce6f0fd235c713015d7d7/uniquesig0/…
from /home/john/.rvm/rubies/ruby-2.2.2/lib/ruby/2.2.0/open-uri.rb:232:in `open_loop'
from /home/john/.rvm/rubies/ruby-2.2.2/lib/ruby/2.2.0/open-uri.rb:150:in `open_uri'
from /home/john/.rvm/rubies/ruby-2.2.2/lib/ruby/2.2.0/open-uri.rb:716:in `open'
from /home/john/.rvm/rubies/ruby-2.2.2/lib/ruby/2.2.0/open-uri.rb:34:in `open'
from (irb):2
from /home/john/.rvm/rubies/ruby-2.2.2/bin/irb:11:in `<main>'
~~~
---Files--------------------------------
open_uri-redirect-cookie-11322.patch (2.3 KB)
--
https://bugs.ruby-lang.org/
Issue #18980 has been updated by k0kubun (Takashi Kokubun).
Description updated
Status changed from Open to Assigned
Assignee set to k0kubun (Takashi Kokubun)
Target version set to 3.4
In today's Developers Meeting, @matz accepted to warn `it` in Ruby 3.3 and add `it` in Ruby 3.4. Quote from the meeting notes:
> * matz: accept `it` on Ruby 3.4.
> * ruby 3.3 will warn and ruby 3.4 will use the new semantics
I also copied the discussed specification to the ticket description. In Ruby 3.3, `it` should be warned only when `it` will behave like `_1` in Ruby 3.4.
----------------------------------------
Feature #18980: Re-reconsider numbered parameters: `it` as a default block parameter
https://bugs.ruby-lang.org/issues/18980#change-105563
* Author: k0kubun (Takashi Kokubun)
* Status: Assigned
* Priority: Normal
* Assignee: k0kubun (Takashi Kokubun)
* Target version: 3.4
----------------------------------------
## Problem
Numbered parameters (`_1`, `_2`, ...) look like unused local variables and I don't feel motivated to use them, even though I need this feature very often and always come up with `_1`.
```rb
[1, 2, 3].each { puts _1 }
```
I have barely used it in the last 2~3 years because it looks like a compromised syntax. I even hesitate to use it on IRB.
<details>
<summary>Why I don't use <code>_1</code></summary>
I'm not clever enough to remember the order of parameters. Therefore, when a block has multiple parameters, I'd always want to name those parameters because which is `_1` or `_2` is not immediately obvious. Thus I would use this feature only when a block takes a single argument, which is actually pretty common.
If I use `_1`, it feels like there might be a second argument, and you might waste time to think about `_2`, even if `_2` doesn't exist, which is a cognitive overhead. If you use `it`, it kinda implies there's only a single argument, so you don't need to spend time remembering whether `_2` exists or not. It is important for me that there's no number in `it`.
</details>
## Proposal
* Ruby 3.3: Warn `it` method calls without a receiver, arguments, or a block.
* Ruby 3.4: Introduce `it` as follows.
### Specification
```rb
[1, 2, 3].each { puts it }
```
`it`s behavior should be as close to `_1` as possible. `it` should treat array arguments in the same way as `_1`. `it` doesn't work in a block when an ordinary parameter is defined. `it` is implemented as a special case of `getlocal` insn, not a method. `it` without an argument is considered `_1` or a normal local variable if defined. `it` is considered a method call only when it has any positional/keyword/block arguments.
<details>
<summary>Full specification</summary>
```ruby
# Ruby 3.4
def foo
it #=> method call
_1 #=> method call
1.times do
p it #=> 0
it = "foo"
p it #=> "foo"
p _1 #=> 0
_1 = "foo" # Syntax Error
p _1 #=> N/A
p foo #=> method call
foo = 1
p foo #=> local var
it "foo" do # method call (rspec)
end
end
1.times do ||
p _1 # Syntax Error
it # method call
end
1.times do
["Foo"].any? {|| it } # method call
end
yield_1_and_2 do # yield 1, 2
p _1 #=> 1
p it #=> 1
end
yield_ary do # yield [1, 2]
p _1 #=> [1, 2]
p it #=> [1, 2]
end
1.times do
p [_1, it] # Syntax Error
p [_2, it] # Syntax Error
end
end
```
</details>
## Past discussions
* [Feature #4475] default variable name for parameter: Proposed `it`, and merged as `@1`.
* 2019/03/13: [DevelopersMeeting20190311Japan](https://docs.google.com/document/d/e/2PACX-…
* 2019/04/17: [DevelopersMeeting20190417Japan](https://docs.google.com/document/d/1hw6Xca8…
* 2019/04/20: [Ruby Committers vs the World](https://youtu.be/5eAXAUTtNYU?t=3118)
* [Feature #15723] Reconsider numbered parameters: Renamed `@1` to `_1`.
* 2019/08/29: [DevelopersMeeting20190829Japan](https://docs.google.com/document/d/1XypDO1c…
* [Feature #15897] `it` as a default block parameter: Proposed `it`, and got closed because `_1` was merged.
* [Feature #18980] Re-reconsider numbered parameters: (this ticket)
* 2022/09/08: [Ruby Committers vs the World](https://youtu.be/ajm3lr6Y9yE?si=yyWGiZHoUWqZiTaS&t=2920)
### Compatibility
`it` has not necessarily been rejected by Matz; he just said [it's difficult to keep compatibility](https://bugs.ruby-lang.org/issues/4475#note-6) and [`it` or `this` _could_ break existing code](https://bugs.ruby-lang.org/issues/15723#note-2). It feels like everybody thinks `it` is the most beautiful option but is not sure if `it` breaks compatibility. But, in reality, does `it`?
The following cases have been discussed:
* `it` method, most famously in RSpec: You almost always pass a positional and/or block argument to RSpec's `it`, so the conflict is avoided with my proposal. You virtually never use a completely naked `it` ([comment](https://bugs.ruby-lang.org/issues/15897#note-29)).
* `it` local variable: With the specification in my proposal, the existing code can continue to work if we consider `it` as a local variable when defined.
With the specification in my proposal, existing code seems to break if and only if you call a method `#it` without an argument. But it seems pretty rare (reminder: a block given to an RSpec test case is also an argument). It almost feels like people are too afraid of compatibility problems that barely exist or have not really thought about options to address them.
Also, you could always experiment with just showing warnings, which doesn't break any compatibility. Even if it takes 2~3 years of a warning period, I'd be happy to use that in 3 years.
### Confusion
We should separately discuss incompatible cases and "works but confusing" cases. Potential confusion points:
* RSpec's `it "tests something" do ... end` vs `it` inside the `do ... end`
* `it` could be a local variable or `_1`, depending on the situation
My two cents: You'd rarely need to write `it` directly under RSpec's `it` block, and you would just name a block argument for that case. In a nested block under a test case, I don't think you'd feel `it` is RSpec's. When you use a local variable `it = 1`, you'd use the local variable in a very small scope or few lines because otherwise, it'd be very hard to figure out what the local variable has anyway. So you'd likely see the assignment `it = 1` near the use of the local variable and you could easily notice `it` is not `_1`. If not, such code would be confusing and fragile even without this feature. The same applies when `it` is a method/block argument.
I believe it wouldn't be as confusing as some people think, and you can always choose to not use `it` in places where `it` is confusing.
--
https://bugs.ruby-lang.org/
Issue #11322 has been updated by hsbt (Hiroshi SHIBATA).
Status changed from Assigned to Closed
I merged https://github.com/ruby/open-uri/pull/18. Thanks all.
----------------------------------------
Feature #11322: OpenUri: RuntimeError: HTTP redirection loop
https://bugs.ruby-lang.org/issues/11322#change-105562
* Author: tbsprs (Tobias Preuss)
* Status: Closed
* Priority: Normal
* Assignee: akr (Akira Tanaka)
----------------------------------------
Trying to download [this file](http://apps.london.ca/OpenData/ShapeFiles_Zipped/2010_skateboard_parks_shp.zip) from [this website](http://www.london.ca/city-hall/open-data/Pages/Open-Data-Data-Catalogue.aspx) with [`OpenUri`](http://ruby-doc.org/stdlib-2.2.2/libdoc/open-uri/rdoc/OpenURI.html) fails with the runtime error "HTTP redirection loop".
Here is how I can reproduce the error:
~~~
> require 'open-uri'
=> true
> open('http://apps.london.ca/OpenData/ShapeFiles_Zipped/2010_skateboard_parks_shp.…')
RuntimeError: HTTP redirection loop: http://apps.london.ca/uniquesig87fdc01fb86ce6f0fd235c713015d7d7/uniquesig0/…
from /home/john/.rvm/rubies/ruby-2.2.2/lib/ruby/2.2.0/open-uri.rb:232:in `open_loop'
from /home/john/.rvm/rubies/ruby-2.2.2/lib/ruby/2.2.0/open-uri.rb:150:in `open_uri'
from /home/john/.rvm/rubies/ruby-2.2.2/lib/ruby/2.2.0/open-uri.rb:716:in `open'
from /home/john/.rvm/rubies/ruby-2.2.2/lib/ruby/2.2.0/open-uri.rb:34:in `open'
from (irb):2
from /home/john/.rvm/rubies/ruby-2.2.2/bin/irb:11:in `<main>'
~~~
---Files--------------------------------
open_uri-redirect-cookie-11322.patch (2.3 KB)
--
https://bugs.ruby-lang.org/
Issue #11322 has been updated by akr (Akira Tanaka).
I agree with `max_redirects` option.
----------------------------------------
Feature #11322: OpenUri: RuntimeError: HTTP redirection loop
https://bugs.ruby-lang.org/issues/11322#change-105561
* Author: tbsprs (Tobias Preuss)
* Status: Assigned
* Priority: Normal
* Assignee: akr (Akira Tanaka)
----------------------------------------
Trying to download [this file](http://apps.london.ca/OpenData/ShapeFiles_Zipped/2010_skateboard_parks_shp.zip) from [this website](http://www.london.ca/city-hall/open-data/Pages/Open-Data-Data-Catalogue.aspx) with [`OpenUri`](http://ruby-doc.org/stdlib-2.2.2/libdoc/open-uri/rdoc/OpenURI.html) fails with the runtime error "HTTP redirection loop".
Here is how I can reproduce the error:
~~~
> require 'open-uri'
=> true
> open('http://apps.london.ca/OpenData/ShapeFiles_Zipped/2010_skateboard_parks_shp.…')
RuntimeError: HTTP redirection loop: http://apps.london.ca/uniquesig87fdc01fb86ce6f0fd235c713015d7d7/uniquesig0/…
from /home/john/.rvm/rubies/ruby-2.2.2/lib/ruby/2.2.0/open-uri.rb:232:in `open_loop'
from /home/john/.rvm/rubies/ruby-2.2.2/lib/ruby/2.2.0/open-uri.rb:150:in `open_uri'
from /home/john/.rvm/rubies/ruby-2.2.2/lib/ruby/2.2.0/open-uri.rb:716:in `open'
from /home/john/.rvm/rubies/ruby-2.2.2/lib/ruby/2.2.0/open-uri.rb:34:in `open'
from (irb):2
from /home/john/.rvm/rubies/ruby-2.2.2/bin/irb:11:in `<main>'
~~~
---Files--------------------------------
open_uri-redirect-cookie-11322.patch (2.3 KB)
--
https://bugs.ruby-lang.org/
Issue #20011 has been reported by jeremyevans0 (Jeremy Evans).
----------------------------------------
Feature #20011: Reduce implicit array allocations on caller side of method calling
https://bugs.ruby-lang.org/issues/20011
* Author: jeremyevans0 (Jeremy Evans)
* Status: Open
* Priority: Normal
----------------------------------------
I would like to use the peephole optimizer to eliminate caller-side array allocations for the following cases, by switching `splatarray true` to `splatarray false`:
```ruby
f(1, *a)
f(1, *a, &lvar)
f(1, *a, &@ivar)
f(*a, **lvar)
f(*a, **@ivar)
f(*a, **lvar, &lvar)
f(*a, **@ivar, &@ivar)
f(*a, kw: 1)
f(*a, kw:1, &lvar)
f(*a, kw:1, &@ivar)
```
In terms of safety, currently, `f(*a, &lvar)` and `f(*a, &@ivar)` both avoid array allocations (`splatarray false`), and all of the above are as safe as those in terms of safety. Note that since at least Ruby 1.8, in pathlogical cases, `lvar.to_proc` can modify `a`, which results in behavior contrary to expected evaluation order:
```ruby
ary = [1,2]
kwd = Object.new
kwd.define_singleton_method(:to_proc) {ary << 4; lambda{}}
p(*ary, &kwd)
# 4 included in output
```
I think that for both the current `f(*a, &lvar)` and `f(*a, &@ivar)` cases and all of the above cases, the benefit of avoiding the allocation is higher than the costs, considering that only pathologic cases fail. If we do not want the above optimization, for consistency, we should remove the optimization of `f(*a, &lvar)` and `f(*a, &@ivar)` (or update the optimization so that it is only used if `lvar` or `@ivar` is already a proc), which will slow Ruby down.
I have submitted a pull request for these changes: https://github.com/ruby/ruby/pull/8853
To make sure these cases are worth optimizing, I did some analysis:
For ruby -e '' (just loads rubygems):
```
5 : f(1, *a)
2 : f(1, *a, &lvar) | f(1, *a, &@ivar)
```
Current stdlib:
```
139 : f(1, *a)
3 : f(1, *a, &lvar) | f(1, *a, &@ivar)
4 : f(*a, **lvar) | f(*a, **@ivar)
```
Rails master:
```
77 : f(1, *a)
5 : f(1, *a, &lvar) | f(1, *a, &@ivar)
26 : f(*a, **lvar) | f(*a, **@ivar)
5 : f(*a, kw: 1)
```
minitest 5.20 (bundled gem):
```
4 : f(1, *a)
1 : f(1, *a, &lvar) | f(1, *a, &@ivar)
2 : f(*a, **lvar) | f(*a, **@ivar)
2 : f(*a, **lvar, &lvar) | f(*a, **@ivar, &@ivar)
```
capybara 3.39.2:
```
15 : f(1, *a)
2 : f(1, *a, &lvar) | f(1, *a, &@ivar)
19 : f(*a, **lvar) | f(*a, **@ivar)
4 : f(*a, **lvar, &lvar) | f(*a, **@ivar, &@ivar)
```
This shows that all cases optimized except `f(*a, kw:1, &lvar)` and `f(*a, kw:1, &@ivar)` are used in common gems. Those cases could be removed if people think they are not worth optimizing.
Code backing the above analysis can be found at https://github.com/ruby/ruby/pull/8853#issuecomment-1817656139
--
https://bugs.ruby-lang.org/
Issue #18886 has been updated by ko1 (Koichi Sasada).
Please merge it.
> I don't think this will affect performance unless TracePoint is used, because the same method caching is done in both cases.
Showing benchmarking result will help IMO to confirm there is no penalty.
----------------------------------------
Bug #18886: Struct aref and aset don't trigger any tracepoints.
https://bugs.ruby-lang.org/issues/18886#change-105557
* Author: ioquatix (Samuel Williams)
* Status: Open
* Priority: Normal
* Assignee: ko1 (Koichi Sasada)
* Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN
----------------------------------------
Given the following program, `thing.name` and `thing.shape` don't trigger `c_call` trace points (or any trace points actually).
```ruby
pp RUBY_VERSION
trace_point = TracePoint.new(:line, :call, :c_call, :a_call) do |trace|
puts trace.event
if trace.event == :call
# Ruby doesn't always mark call-sites in sub-expressions, so we use this approach to compute a call site and mark it:
if location = caller_locations(2, 1).first and path = location.path
puts "> #{path}:#{location.lineno}:#{trace.event}"
end
end
if path = trace.path
puts "= #{path}:#{trace.lineno}:#{trace.event}"
end
end
trace_point.enable
# This will trigger call trace points
class Thing
def name
:cat
end
def shape
:square
end
end
thing = Thing.new
# Thing = Struct.new(:name, :shape)
# thing = Thing.new(:cat, :rectangle)
[
name: thing.name,
shape: thing.shape,
]
```
## Current HEAD
```
= ../test.rb:30:line:
= ../test.rb:30:c_call:new
= ../test.rb:30:c_call:inherited
= ../test.rb:30:c_call:singleton_method_added
= ../test.rb:30:c_call:singleton_method_added
= ../test.rb:30:c_call:singleton_method_added
= ../test.rb:30:c_call:singleton_method_added
= ../test.rb:30:c_call:singleton_method_added
= ../test.rb:30:c_call:method_added
= ../test.rb:30:c_call:method_added
= ../test.rb:30:c_call:method_added
= ../test.rb:30:c_call:method_added
= ../test.rb:30:c_call:const_added
= ../test.rb:31:line:
= ../test.rb:31:c_call:new
= ../test.rb:31:c_call:initialize
= ../test.rb:34:line:
```
## Proposed PR
```
= ../test.rb:30:line:
= ../test.rb:30:c_call:new
= ../test.rb:30:c_call:inherited
= ../test.rb:30:c_call:singleton_method_added
= ../test.rb:30:c_call:singleton_method_added
= ../test.rb:30:c_call:singleton_method_added
= ../test.rb:30:c_call:singleton_method_added
= ../test.rb:30:c_call:singleton_method_added
= ../test.rb:30:c_call:method_added
= ../test.rb:30:c_call:method_added
= ../test.rb:30:c_call:method_added
= ../test.rb:30:c_call:method_added
= ../test.rb:30:c_call:const_added
= ../test.rb:31:line:
= ../test.rb:31:c_call:new
= ../test.rb:31:c_call:initialize
= ../test.rb:34:line:
= ../test.rb:34:c_call:name
= ../test.rb:35:c_call:shape
```
The reason is the internal implementation of struct doesn't have trace point instrumentation in `vm_call_opt_struct_aset` or `vm_call_opt_struct_aref`.
Proposed fix: https://github.com/ruby/ruby/pull/6071 but this would need a review, maybe @jeremyevans0 and @ko1 can help.
--
https://bugs.ruby-lang.org/
Issue #20005 has been reported by tagomoris (Satoshi Tagomori).
----------------------------------------
Feature #20005: Add C API to return symbols of native extensions resolved from features
https://bugs.ruby-lang.org/issues/20005
* Author: tagomoris (Satoshi Tagomori)
* Status: Open
* Priority: Normal
----------------------------------------
I want an API to resolve symbols of other native extensions by a feature name and a symbol name (just like `dlsym`).
(`rb_dln_resolve_symbol` is an example function name of this feature in the example below)
```c
// "a_client_open" is a function defined in "/..../a_client.so", that should be loaded in Ruby beforehand.
// in the extension to be "a.so"
VALUE (*a_client_open)(VALUE);
void Init_a(void)
{
a_client_open = (VALUE(*)(VALUE))rb_dln_resolve_symbol("a_client", "a_client_open");
// the return value may be NULL if the symbols is not found
}
```
This API is to replace direct reference of external symbols.
Currently, native extensions have to just call the function of other extensions directly on the assumption of:
* The dependency native extension is already loaded
* The symbol is defined correctly in the dependency (the version of dependency is correct&expected)
Otherwise, it crashes.
This API provides a way for developers to raise exceptions if the resolved symbol is `NULL`, and these exceptions can display meaningful messages and instructions to the users of extensions.
--
https://bugs.ruby-lang.org/