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:
;;
my-cool-unknown-identifier
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
Yes,
includewreaking 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.mod.fnl:
{:bork (fn [] (error :oops))}entry.fnl:
(local f (include :mod)) (print "Testing...") (f.bork)Results in
Testing... error in error handlingWith 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 theinclude'd modules being inlined as loader functions when set onpackage.preload, which loses filename information.#Most likely fix, IMO
When I originally re-implemented the very early version of
includeto respect module semantics viapackage.preload, I actually usedload/loadcodewith 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 toloadallows embedding the original file name: I was already planning to do for--correlate(whichincludebreaks 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.
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 :)