From: "Eregon (Benoit Daloze) via ruby-core" <ruby-core@...>
Date: 2025-03-14T09:51:20+00:00
Subject: [ruby-core:121362] [Ruby Misc#20968] `Array#fetch_values` unexpected method name in stack trace

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/