TIC-80: Janet compilation errors don't show line numbers

When I tried to run my Janet code, I got the following error in TIC-80 console:

compile error in main: unexpected type in destruction, got 0

This was a compilation error in my code but there was no line number printed so it was not trivial for me to find the source of the error.

For runtime errors, the line and column numbers are printed correctly.

About this issue

  • Original URL
  • State: closed
  • Created 10 months ago
  • Reactions: 1
  • Comments: 31 (7 by maintainers)

Most upvoted comments

@sogaiu ya I totally can, I’ll create it now so I dont forget

@sogaiu I rebuilt tic80 with the version of the janet that included your changes over the weekend… then totally forgot to respond here 🤦

Everything has been working just as intended for me! I didn’t realize how many times I had been missing the compile error line number until I tried using an older build.

I agree upgrading Janet here is the thing to do… reading through the release notes for both 1.30 and 1.31 (tic80 is on 1.29), it looks like there are a lot of other great changes as well!

There’s now a PR to janet.

By the way, what does strict: true mean in Janet files? Is there a documentation for this?

There is no documentation for this in the wiki (the github search bar has a “Wikis” filter). I found https://github.com/nesbox/TIC-80/pull/1653 about strict: true for fennel and the only mention of it in the code except demo carts is in fennel.c so I think it has been added by mistake to the janet demo cart. I suppose the janet demo cart was created by modifying the fennel one.

Thanks for the code. I was able to reproduce and did some investigation.

The short summary is that it may take some work to get line and column information for this situation.

A longer explanation follows for any parties interested in undertaking the work 😃

I’m not the author of any of the Janet integration code, but IIUC, the lines here:

    if (janet_dostring(core->currentVM, code, "main", &result)) {
        reportError(core, result);

look to be part of the code path responsible for the output you reported.

janet_dostring is defined here and it calls janet_dobytes which is defined here.

Within janet_dobytes are these lines:

                    janet_eprintf("compile error in %s: %s\n", sourcePath,
                                  (const char *)cres.error);

which appear to be what constructs the error string beginning “compile error in”. (I didn’t see any obvious usable line and column information near these lines.)

I think in standalone janet, code execution is arranged for in a different way and the location information is available for use in constructing the message. My guess is that the relevant code for constructing the error message is here. That code appears to be passed line and column information which might be made available around here. Note that all of that code is in pure Janet and not C [1].

(As a remark in favor of the above guess, comparing the error messages closely, one can see that the TIC-80 integrated code starts with “compile error in”, whereas the standalone janet error has the string “compile error:” following the location information.)

@AlecTroemel What do you think of the explanation above?


By the way, what does strict: true mean in Janet files? Is there a documentation for this?

I don’t know. May be someone else does though.


[1] janet_dobytes basically wraps janet_compile using the janet_parser_* functions for parsing.

boot.janet’s cli-main uses run-context which in turn uses compile, which wraps janet_compile_lint.

Both janet_compile_lint and janet_compile (itself a wrapper of the former) return a JanetCompileResult which has an error_mapping field (this is of type JanetSourceMapping and has error location IIUC). Perhaps error information IS accessible in janet_dobytes via janet_compile’s return value and consequently, may be upstream would consider accepting (or making) changes so that this location information is used in the compilation error messages…