Kernel#warn should ignore <internal: entries
Kernel#warn currently does not skip
<internal: entries from core library methods defined in Ruby.
This can cause rather unhelpful locations to be used for warnings.
$ ruby -v --disable=gems -e 'def deprecated; warn "use X instead", uplevel: 1; end; tap(&:deprecated)' ruby 3.0.0preview1 (2020-09-25 master 0096d2b895) [x86_64-linux] <internal:kernel>:90: warning: use X instead # expected: "-e:1: warning: use X instead"
Note that RubyGems overrides Kernel#warn since https://github.com/rubygems/rubygems/pull/2442 and https://github.com/rubygems/rubygems/blob/c1bafab1d84e0aad06e377e9db4b74cccab4b43a/lib/rubygems/core_ext/kernel_warn.rb#L42,
--disable-gems is needed to observe this behavior.
I think it is very suboptimal that RubyGems needs to monkey-patch Kernel#warn to remove RubyGems'
That is both fragile (as we've seen from various incompatible behavior and bugs in that monkey-patch) and inefficient (walking the stack multiple times).
So I would suggest to actually skip all backtraces entries starting with
BTW this is already what TruffleRuby does.
As a bonus, by filtering out
<internal:, RubyGems could define its
require in an
eval(code, nil, '<internal:rubygems-require>', line) and it would automatically be skipped, without needing to monkey-patch Kernel#warn at all!
Updated by Eregon (Benoit Daloze) 7 months ago
nobu (Nobuyoshi Nakada) wrote in #note-3:
uplevel:option is useless in some cases.
For instance, it cannot work to skip frames in the same file or directory.
Yes, some libraries might want to emit warnings and ignore their own
That however would need to make
warn somehow take some extra context, because only warnings of that library should ignore
my_gem/lib/, other calls to
warn should not.
warn(message, uplevel: n, ignore: [path1, path2]).
That would not work for RubyGems' require, where warning are not emitted by RubyGems but by anything else.
In practice, I think gems should be able to know if they call themselves directly or not, so there should be no need to skip
I might be wrong about that.
OTOH for core library methods and RubyGems'
require, it seems clear it would never be useful to show their location for
So I think ignoring
<internal: is a useful step on its own, and such entries should be ignored by default.
It also keeps compatibility with older Rubies which had less core methods defined in Ruby, which should be a transparent implementation detail, at least for