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/7ab9c82b1b01614b052a57ccb49370cea9... 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/c235249abaafa2780b540aca1813dfcf3d17...). 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/