29256, "jabraham17", "Feature Enhancement: use non-inlined line numbers for error stack traces", "2026-08-13T15:55:16Z"
In Add stacktraces for thrown Errors by jabraham17 · Pull Request #28856 · chapel-lang/chapel · GitHub, I implemented stack traces for Chapel errors. While this is can be a useful feature by itself, many error chains end up looking like this
...
file.chpl:2
file.chpl:2
file.chpl:2
file.chpl:2
...
This occurs when functions are inlined. Today, when inlining functions we do not preserve the original source information. This has several consequences (especially for debug information), but for stack traces it can make the stack trace less useful. This is especially true for many calls into the standard library where liberal inlining is done.
There is a flag, --preserve-inlined-line-numbers, which does preserve the original source information. Naively, it could just be turned on by default. However, as noted in the commit it was added, doing this can result in some adverse behavior. For example, with --preserve-inlined-line-numbers an out-of-bounds halt on an array access shows the halt in the DefaultRectangular, not the user level halt.
Ideally we should have a way to get the best of both worlds, always preserve inlined line numbers but for some halts show the user-level halt. One extreme way to handle this is to just always preserve inlined line numbers and rely on stack traces to show users where the halt occurred. I think this has a few drawbacks for users who don't have builds with halt stack traces builtin-in, but generally could be workable.