See this:
https://github.com/rakudo/rakudo/blob/6c76ed0abe352316eb58283fa6ce6b8150fc6830/src/core/Backtrace.pm#L144
It goes like this:
# now *that's* an evil hack
next if $file.ends-with('BOOTSTRAP.nqp')
|| $file.ends-with('QRegex.nqp')
|| $file.ends-with('Perl6/Ops.nqp');
I think the whole concept of defining what's "interesting" in a
backtrace by looking at the file name is pretty evil:
1) It cannot handle non-runtime code that one might want to filter.
2) It hardcodes the definition of what's interesting.
3) You cannot have runtime code that you *want* to be included in the
backtrace.
4) It adds a design constraint about what can go into which module of
the runtime.
5) The design constraint is nonobvious.
6) If somebody writes his own module in a different location but with a
matching name (e.g. they might be writing a wrapper, or an emulator),
then these files will be filtered as well.
Maybe it's smarter to have a function annotation (i.e. a trait, I
believe) for "don't include this in backtraces"; this would deal with
all problems except (2).
To address (2), the runtime could offer a setting that defines what
traits cause backtracking exclusion.
If a trait is not the way to go, one could deal at least with (5) by
adding a comment at the top of the filtered files:
# Functions in this file will not show up in backtraces.
# See the filename filtering logic in Backtrace::AT-POS
# of rakudo/src/core/Backtrace.pm.
I think line 148 has the same kind of evilness (decide what to do
depending on the name of the source file), I just couldn't determine
what the body of the "if" statement is actually doing:
> if $file.ends-with('NQPHLL.nqp') || $file.ends-with('NQPHLL.moarvm') {
