ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
From: "Eregon (Benoit Daloze) via ruby-core" <ruby-core@ml.ruby-lang.org>
To: ruby-core@ml.ruby-lang.org
Cc: "Eregon (Benoit Daloze)" <noreply@ruby-lang.org>
Subject: [ruby-core:121362] [Ruby Misc#20968] `Array#fetch_values` unexpected method name in stack trace
Date: Fri, 14 Mar 2025 09:51:20 +0000 (UTC)	[thread overview]
Message-ID: <redmine.journal-112333.20250314095119.9869@ruby-lang.org> (raw)
In-Reply-To: <redmine.issue-20968.20241219054042.9869@ruby-lang.org>

Issue #20968 has been updated by Eregon (Benoit Daloze).


mame (Yusuke Endoh) wrote in #note-15:
> In any case, it was reaffirmed that matz strongly prefers that `<internal:` not be displayed.

@matz Is that because there is the word "internal" in there and so it sounds like exposing internals?
How about `<core:` or `<core-library:` then? That would make it clear those are core library methods.

As I explained in my previous reply `<internal:` has been there since many years (since `gem_prelude.rb`/`prelude.rb` exist) and has caused no real issues (just a few incorrect assumptions in gems which have been fixed since).
If it wasn't for this issue, we would probably not even discuss this, and most (all I think) people on this issue already agreed it is not a bug and not a problem in practice.

If it's about consistency of C-defined vs Ruby-defined core methods in the backtrace, we could maybe go the other way around, @jeremyevans0 said earlier in the thread:

> If we could show the file and line for C functions, that would be useful for debugging. I assume the only reason we don't is that doing so is not feasible.

It should be feasible with a C preprocessor macro using `__FILE__` and `__LINE__`.
In fact, I think it's confusing and misleading that methods defined in C report that they are defined in the caller Ruby file (which is obviously incorrect, they are not defined there).
Detailed in the 2nd part of [this comment](https://bugs.ruby-lang.org/issues/20968#note-6) after the horizontal line.

I think that illustrates clearly that people got used to this "confusing/misleading way to report the stacktrace for C-defined methods", and so they are surprised to see something else for Ruby-defined core methods.
But I believe it is just a matter of getting used to it. Passed the initial "surprise" it makes total sense because it's no different than a regular method defined in Ruby code (except the file prefix).

[This comment](https://bugs.ruby-lang.org/issues/20968#note-9) demonstrates that the current stacktrace for `Array#fetch_values` is very consistent as if the method was defined in a Ruby file in some gem or so.
And on the contrary, changing stacktraces as proposed would introduce a 3rd kind of entry in the backtrace, which I think is evident it will cause more confusion, due to hiding crucial information in at least some cases.

---

BTW `<internal:` is used for filtering in `Kernel#warn` and in https://github.com/rubygems/rubygems/blob/7ab9c82b1b01614b052a57ccb49370cea9be17e9/lib/rubygems.rb#L1404-L1407
It's also intentional that `Kernel#warn` filters out core methods, since those should definitely not emit warnings (or if they do the cause is probably the caller, if not then it's a CRuby bug).
So `<internal:` is a useful concept besides just the core library.
In fact a [quick search](https://github.com/search?q=%3Cinternal+language%3ARuby+&type=code) shows it's used in various gem, a well-known example is [Sinatra](https://github.com/sinatra/sinatra/blob/c235249abaafa2780b540aca1813dfcf3d17c2dd/lib/sinatra/base.rb#L1297).
So removing `<internal:` in CRuby would likely cause some incompatibility.

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

* 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  9:52 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 ` [ruby-core:121360] [Ruby " mame (Yusuke Endoh) via ruby-core
2025-03-14  9:51 ` Eregon (Benoit Daloze) via ruby-core [this message]
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-112333.20250314095119.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).