Using <internal: for core library methods defined in Ruby #6430
Comments
|
I am reluctant to use something as meaningless as "internal" since it can't be resolved to a real path by any code. The path we provide with "uri:classloader:" is actually the path that gets required; it indicates clearly where the source is located (as a classloader resource) and the full path to that file within the classloader. We will consider an appropriate way to add the "internal" identifier without losing the actual classloader path information. |
|
What about something like: It doesn't seem good to ask 3rd-party libraries which sometimes need to filter out core methods (e.g. for warnings, or for more relevant backtraces for test frameworks) to have various different regexps to skip those, and External processes can't understand |
|
Linking with #5764 since that rewrites most of the load logic. |
|
For more context, see
|
This allows tools to omit any of our internal Ruby-based kernel sources when processing backtraces and source_locations. The filtering here is only done in source_location and backtrace generation currently, with some extra logic during backtrace mining to skip internal frames for e.g. Kernel#warn. I only did this filtering at the highest levels, when the filename is actually about to be used and returned to a Ruby consumer, to avoid any internal usage of these filenames breaking due to the new prefix. Fixes jruby#6430
The Java version did little more than yield to the given block, and the new specs provided for Kernel#warn skipping internal files expects that Kernel#tap will come from an internal file. See jruby#6430
The Java version did little more than yield to the given block, and the new specs provided for Kernel#warn skipping internal files expects that Kernel#tap will come from an internal file. There's a workaround here for behavior that changed in CRuby, whereby yielding to a lambda should trigger arity errors rather than bypassing arity checks. See https://bugs.ruby-lang.org/issues/12705 See jruby#6430 for the "internal" source issue that led to moving this into Ruby.
The Java version did little more than yield to the given block, and the new specs provided for Kernel#warn skipping internal files expects that Kernel#tap will come from an internal file. There's a workaround here for behavior that changed in CRuby, whereby yielding to a lambda should trigger arity errors rather than bypassing arity checks. See https://bugs.ruby-lang.org/issues/12705 See jruby#6430 for the "internal" source issue that led to moving this into Ruby.
This allows tools to omit any of our internal Ruby-based kernel sources when processing backtraces and source_locations. The filtering here is only done in source_location and backtrace generation currently, with some extra logic during backtrace mining to skip internal frames for e.g. Kernel#warn. I only did this filtering at the highest levels, when the filename is actually about to be used and returned to a Ruby consumer, to avoid any internal usage of these filenames breaking due to the new prefix. Fixes jruby#6430
The Java version did little more than yield to the given block, and the new specs provided for Kernel#warn skipping internal files expects that Kernel#tap will come from an internal file. There's a workaround here for behavior that changed in CRuby, whereby yielding to a lambda should trigger arity errors rather than bypassing arity checks. See https://bugs.ruby-lang.org/issues/12705 See jruby#6430 for the "internal" source issue that led to moving this into Ruby.
Core library methods'
source_locationand in backtraces defined with Ruby code look like this:<internal:kernel>:89on CRuby<internal:core> core/kernel.rb:533on TruffleRubyuri:classloader:/jruby/kernel/enumerator.rb:243on JRubyI would suggest to use a
<internal:prefix since this is becoming the de facto standard.That will also provide a consistent way to filter out core library methods defined in Ruby when desirable.
Also note that both CRuby 3 and TruffleRuby ignore entries starting with
<internal:forKernel#warn(msg, uplevel: n)(details in rubygems/rubygems#3987 (comment)).The text was updated successfully, but these errors were encountered: