Wrong error line when using `include`

When using (include), any compile error in the included file doesn't show the line where error happened, but instead shows the line of the original file.

This affects --require-as-include.

Here's an example: in file1.fnl

(include :file2)
;; this is the corresponding line in the original file

in file2.fnl:


When I run fennel file1.fnl, the error message gives

./file2.fnl:2:0: Compile error: unknown identifier: my-cool-unknown-identifier

>>;; this is the correspondi<<ng line in the original file
* Try looking to see if there's a typo.
* Try using the _G table instead, eg. _G.my-cool-unknown-identifier if you really want a global.
* Try moving this code to somewhere that my-cool-unknown-identifier is in scope.
* Try binding my-cool-unknown-identifier as a local in the scope of this code.

where the >> and << are ANSI highlight codes.

The line with the error should be taken from file2.fnl instead of file1.fnl

Assigned to
2 months ago
a month ago

~jaawerth a month ago

Yes, include wreaking havoc on module filenames is definitely an issue - glad you filed it, we've sort of known about this class of issues for a while, and it was an oversight not to document them in a todo.


{:bork (fn [] (error :oops))}


(local f (include :mod))
(print "Testing...")

Results in

error in error handling

With AOT, it just gives the expected incorrect stacktrace; run live, that particularly unhelpful error is likely due to a debug module invocation ala traceback, since it's known to happen at the Lua/C boundary. I'm fairly certain this all comes down to being due to the include'd modules being inlined as loader functions when set on package.preload, which loses filename information.

#Most likely fix, IMO

When I originally re-implemented the very early version of include to respect module semantics via package.preload, I actually used load/loadcode with the embedded lua as a string to generate the inlined module loader. At the time, bakpakin objected to this approach because it negatively impacted readability of the emitted lua output. However, I think this is worth revisiting, since switching back to load allows embedding the original file name: I was already planning to do for --correlate (which include breaks entirely), but it's also worth discussing everywhere: running live would also be a no-brainer, since the readability of the Lua output matters even less there.

Granted, we may also be able to achieve this by doing some more funky stacktrace manipulation, but I'm somewhat skeptical - I think this approach would not only also improve the stack traces in code AOT-compiled with --correlate, but also be cleaner in general than trying to work around it by manipulating the sourcemap data.

~xerool a month ago

In this ticket I'm concerned about compile error messages. Runtime errors with live/AOT are a separate concern that deserve a new fresh ticket :)

Register here or Log in to comment, or comment via email.