Location missing on literal syntax errors

[yuhan0]

• I have read the Clojure etiquette and will respect it when communicating on this platform.

version

clj-kondo v2024.03.13

platform

native

editor

NA

problem

The following syntax errors cause clj-kondo to report an null / incorrect error location and interfere with the reporting of all other linting errors in the file. (this makes it trickier than usual to pinpoint the source of the error)

repro

$ echo '\u12345' | clj-kondo --lint -
<stdin>::: error: Invalid unicode literal: \u12345.
linting took 41ms, errors: 1, warnings: 0

$ echo '\o8' | clj-kondo --lint -
<stdin>::: error: Invalid digit 8 in unicode character \o8.
linting took 66ms, errors: 1, warnings: 0

Note the missing line and column locations (this confuses the Emacs flycheck checker)
Also \o denotes an octal, not unicode escape.

$ echo '##' | clj-kondo --lint -
<stdin>:1:3: error: EOF while reading.
linting took 47ms, errors: 1, warnings: 0

$ echo '99r0' | clj-kondo --lint -
<stdin>:1:: error: Radix out of range
linting took 32ms, errors: 1, warnings: 0

$ echo "oops\n\n2r123" | clj-kondo --lint -
<stdin>:1:: error: For input string: "123"
linting took 73ms, errors: 1, warnings: 0

In these cases the line number 1 is reported regardless of where the error occurs, and other lint warnings (eg. unresolved symbol) before or after the parsing errors are not reported.
Note too the incomplete error message in the last line.

config
NA

expected behavior

clj-kondo should report the line/column location of these syntax errors, similar to what it does in other similar situations:

$ echo "oops\n1.0/3\n\\spcae" | clj-kondo --lint -
<stdin>:1:1: error: Unresolved symbol: oops
<stdin>:2:1: error: Invalid number: 1.0/3.
<stdin>:3:1: error: Unsupported character: spcae.
linting took 71ms, errors: 3, warnings: 0

[borkdude]

thanks

[yuhan0]

Here they are formatted for easier copying :)

#: #:: ##InF ## ;; invalid tokens

\u0 \u123x \u12345 \udfff ;; invalid unicode escapes

\o789  ;; invalid octal escape

1r0 37r0 ;; radix out of range (2-36)

2r012 16raaah ;; digit out of radix range

[yuhan0]

Thanks for the fix!
On the latest version the unicode and octal characters now report the error location, however the invalid numbers and symbolic dispatches are still broken.

Thanks to the above commit I was able to poke around the source and found that the ## token throws a reader error with {:ex-kind :eof} ex-data.

Adding another (= ex-kind :eof) clause here solves it:

clj-kondo/parser/clj_kondo/impl/rewrite_clj/parser/token.clj

Line 58 in 9919c2a

(or (= :reader-error ex-kind)

But a less brittle solution might be to simply remove the or expression and surface all reader exceptions? Instead of (in the else branch) throwing them to downstream handlers, which ultimately results in the location info being lost.

[borkdude]

Feel free to poke around and provide a PR with any improvements.