> 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') {