Fork me on GitHub
#clj-kondo
<
2021-02-07
>
ericdallo04:02:21

Hey @borkdude I would like to hear your opinion on this clojure-lsp "bug" after the keyword analysis

ericdallo04:02:59

Bug: As of now, if there is anyone with a keyword on the project/deps that starts with a number, it'll will not be able to read from cache(sqlite) when starting the project. So, I noticed that every time I start clojure-lsp on clojure-lsp project, it's not being able to read the edn persisted on sqlite, because there is a simple keyword analysis with name :2s from https://github.com/ptaoussanis/encore/blob/645dc120380ab75648cd449c17f24b381055977d/src/taoensso/encore.cljc#L2268. We save the analysis with transforming it to string with pr-string and when load it, we read with edn/read-string . When parsing the edn {:name 2s} , clojrue just throw a NumberFormatException , I tested it on REPL and indeed when you type '2s it just blow up. So i'm not sure what is the issue here, should clojure.data.edn/read-string be able to parse a symbol that starts with a number? otherwise how should we proceed? should clj-kondo save the :name of a keywords bucket with the : ?

borkdude09:02:16

@UKFSJSM38 Storing the name of the keyword as a string would help here. Alternatively clj-kondo could report the keyword as invalid and not output it in the analysis.

borkdude09:02:12

EDN should not be able to read symbols starting with a number. The spec already says these keywords aren't valid.

ericdallo12:02:20

Yeah, I see, not reporting probably would be better

ericdallo12:02:50

Since we are parsing a giant analysis from the sqlite and have no way to know which analysis is wrong

ericdallo12:02:06

So what does that PR merged do?

borkdude12:02:11

but if clj-kondo offered the name as a string, then it would be ok I think?

ericdallo12:02:41

Yes, we 'd persist as a string

borkdude12:02:48

I reverted the merge, so let's just look at the problem from first principle

👍 1
ericdallo12:02:00

Just tested and a string value would be parsed correctly from db so probably the best approach for keywords buckets (or all buckets to keep the standard?)

borkdude12:02:42

We're already exposing the other buckets as documented features. I kept the keyword analysis undocumented to give it a trial run first

borkdude12:02:22

Maybe changing all the names to strings won't be a major break though, since (keyword ..) etc take symbols and strings?

ericdallo12:02:30

Yes, it takes, looks valid to me

ericdallo13:02:59

Something like that works great for me

(edn/read-string "{:name :2s}")

borkdude13:02:39

This would then be :name "2s"

ericdallo13:02:50

oh, yeah, you are right

ericdallo13:02:14

we'd need only the paces that use :name, to parse the string on clojure-lsp, not hard though

borkdude13:02:31

how are you using :name rigth now?

ericdallo13:02:54

One place builds the full keyword from a analysis (`:foo/bar` from :alias and :name) and all the others use to compare one keyword analysis with another keyword analysis

ericdallo13:02:01

so, looks changeable

borkdude13:02:22

yeah, we can change the keyword analysis surely, because no-one else is using that. but I meant the :name fields in the other analysis

ericdallo13:02:06

oh got it, let me check

borkdude13:02:29

we can just change it for the keyword analysis though, PR welcome

borkdude13:02:37

can do it now

ericdallo13:02:47

yeah, most places we get the string with (name ...) and others we compare with other fields. like :to :from :alias etc, I think would work, but some refacotr/check in all features

borkdude13:02:39

Maybe strings would have been better to start with. For people using JSON they won't notice the difference but I think there's clojure tooling which might break if we changed that

ericdallo13:02:41

Ok, I can do it soon for keywords

ericdallo13:02:07

yeah, for sure, for other analysis we need to be safe

ericdallo14:02:45

Just for reference: https://github.com/clj-kondo/clj-kondo/pull/1162 will make the proper changes on clojure-lsp. thanks

borkdude14:02:58

merged

👍 1
ericdallo14:02:23

Tested with clojure-lsp and it worked great!