ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
From: "mame (Yusuke Endoh) via ruby-core" <ruby-core@ml.ruby-lang.org>
To: ruby-core@ml.ruby-lang.org
Cc: "mame (Yusuke Endoh)" <noreply@ruby-lang.org>
Subject: [ruby-core:121360] [Ruby Misc#20968] `Array#fetch_values` unexpected method name in stack trace
Date: Fri, 14 Mar 2025 07:12:28 +0000 (UTC)	[thread overview]
Message-ID: <redmine.journal-112331.20250314071228.9869@ruby-lang.org> (raw)
In-Reply-To: <redmine.issue-20968.20241219054042.9869@ruby-lang.org>

Issue #20968 has been updated by mame (Yusuke Endoh).


So now Method#call can directly invoke a block?
No, it's just the stack trace deceiving you by hiding crucial details.

At the dev meeting, @ko1 also raised this issue. He suggested that, for this reason, we should stop writing in Ruby and revert to C. However, I expect @k0kubun to oppose this change due to YJIT’s performance benefits.

The root of the problem lies in the distinction between different types of function calls: standard C function calls do not appear in the Ruby backtrace, whereas calls made via `rb_funcall`, etc., do.

I proposed that the Ruby method should maintain this distinction: normal method calls should not appear in the backtrace, and if a Ruby method is invoked explicitly using `Primitive.rb_funcall` or something, it should be included in the backtrace.
However, a decision on my proposal was postponed until we could confirm whether there are sufficient real-world cases where naive hiding would cause issues.

In any case, it was reaffirmed that matz strongly prefers that `<internal:` not be displayed. Given this, implementation costs and some runtime overhead are considered acceptable. If no one else takes it on, I will implement it myself (probably after RubyKaigi).

----------------------------------------
Misc #20968: `Array#fetch_values` unexpected method name in stack trace
https://bugs.ruby-lang.org/issues/20968#change-112331

* Author: koic (Koichi ITO)
* Status: Open
----------------------------------------

It seems that the current Ruby implementation is displaying unexpected method name in stack trace.

## Expected

Similar to `Hash#fetch_values`, the method name `Array#fetch_values` is expected to be displayed in the stack trace.

```console
$ ruby -e '{k: 42}.fetch_values(:unknown)'
-e:1:in 'Hash#fetch_values': key not found: :unknown (KeyError)
        from -e:1:in '<main>'

$ ruby -e '[1].fetch_values(42)'
-e:1:in 'Array#fetch_values': index 42 outside of array bounds: -1...1 (IndexError)
        from -e:1:in '<main>'
```


## Actual

The stack trace displays the `Array#fetch` method, which user is not aware of, along with the `<internal.array>` stack trace.

```console
$ ruby -e '[1].fetch_values(42)'
<internal:array>:211:in 'Array#fetch': index 42 outside of array bounds: -1...1 (IndexError)
        from <internal:array>:211:in 'block in Array#fetch_values'
        from <internal:array>:211:in 'Array#map!'
        from <internal:array>:211:in 'Array#fetch_values'
        from -e:1:in '<main>'
```


It likely requires an approach such as implementing it in C, as suggested in https://github.com/ruby/ruby/pull/11555.



-- 
https://bugs.ruby-lang.org/
 ______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/

  parent reply	other threads:[~2025-03-14  7:12 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-19  5:40 [ruby-core:120315] [Ruby master Bug#20968] " koic (Koichi ITO) via ruby-core
2024-12-19  6:20 ` [ruby-core:120316] " jeremyevans0 (Jeremy Evans) via ruby-core
2024-12-19  7:53 ` [ruby-core:120320] " byroot (Jean Boussier) via ruby-core
2024-12-19  8:37 ` [ruby-core:120324] " koic (Koichi ITO) via ruby-core
2025-02-18 10:59 ` [ruby-core:121100] " Eregon (Benoit Daloze) via ruby-core
2025-02-18 18:40 ` [ruby-core:121107] " mame (Yusuke Endoh) via ruby-core
2025-02-18 23:19 ` [ruby-core:121116] " Eregon (Benoit Daloze) via ruby-core
2025-02-19  1:47 ` [ruby-core:121119] [Ruby master Misc#20968] " jeremyevans0 (Jeremy Evans) via ruby-core
2025-02-19  9:58 ` [ruby-core:121122] " Eregon (Benoit Daloze) via ruby-core
2025-03-02 22:18 ` [ruby-core:121216] " ioquatix (Samuel Williams) via ruby-core
2025-03-13 11:06 ` [ruby-core:121325] " mame (Yusuke Endoh) via ruby-core
2025-03-13 11:09 ` [ruby-core:121326] " byroot (Jean Boussier) via ruby-core
2025-03-13 12:07 ` [ruby-core:121337] " matz (Yukihiro Matsumoto) via ruby-core
2025-03-13 14:25 ` [ruby-core:121348] " Eregon (Benoit Daloze) via ruby-core
2025-03-14  7:12 ` mame (Yusuke Endoh) via ruby-core [this message]
2025-03-14  9:51 ` [ruby-core:121362] [Ruby " Eregon (Benoit Daloze) via ruby-core
2025-04-08  3:22 ` [ruby-core:121569] " hsbt (Hiroshi SHIBATA) via ruby-core
2025-04-08 17:34 ` [ruby-core:121593] " Dan0042 (Daniel DeLorme) via ruby-core
2025-04-15  8:01 ` [ruby-core:121665] " akr (Akira Tanaka) via ruby-core

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=redmine.journal-112331.20250314071228.9869@ruby-lang.org \
    --to=ruby-core@ml.ruby-lang.org \
    --cc=noreply@ruby-lang.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).