Fork me on GitHub

I've merged the final thing I wanted to get in for the next release. If you can give it one more try later today, then I'll make a release if there are no other problems. @mynomoto: Linux:

tatut11:10:34 <- this may be very tricky because core.match looks like a quite complicated macro


added an issue to track it, couldn’t find previous issues about core.match


OK. For now you can use the config to turn linting off inside that macro.


well maybe a 1st approximation would be to just consider all non-quoted symbols in the pattern part to be available in the consequent part


Right. It is possible to implement, no doubt, but just pointing at a workaround for now.


Thanks for posting the issue.


I will def. consider it as it's a common thing in the ecosystem.


If you want you can also start working on a PR.


But if I don't notice any activity, I will probably do it at some point.


ok, maybe… I’ve been thinking about trying my hand at implementing something to clj-kondo


I think you can draw some analogies from linting the let macro.




what aliases should I use with cider-jack-in, having trouble running clj-kondo.main-test from cider


@tatut I start it like clj -A:test:cider-nrepl from the command line. I never use cider-jack-in because I'm old fashioned. I connect with cider-connect.


I got it running and made a new corpus/core_match/match.clj with the failing case and added a test to main_test.clj which now fails


then the harder part of implementing


If I understand this correctly, I would add to the (case [resolved-as-namespace resolved-as-name] case in analyzer.clj


ok, I’ll see what I can do


as I've already mentioned, the let linting is probably similar. maybe also the core.async alt macro


(I can never remember if that should be plural and with or without exclamation marks and how many)


I’m unclear what I should return, but I’ll fire up the cider debugger and inspect things


and look at what let and others are doing


what you should do to prevent false positives: extract the bindings from the form that introduces them, add them to the ctx under :bindings and then lint the children nodes using that ctx


cider debugger ❤️ is good for this sort of “exploring an unfamiliar codebase” thing


just eval some existing linter impl in debug mode, run the test and see the values flowing


great. if you're implementing this like the other macros, then you should also get "unused bindings" in your match macro


when you don't use those of course


oh yes, so if you introduce a binding in pattern but don’t use it… I’ll make a test case for that as well


@borkdude got lost doing some fixes for a project, all good on my tests.


alright. I'll make a release either tonight or tomorrow

🎉 4

the :bindings is a map in ctx, from symbol to ?


symbol to map with row and col. this is typically produced by the function extract-bindings


ok, I’ll look into that


but got to go and continue later, thanks for the advice so far


no problem, take your time


hi.. i'm trying to get clj-kondo working on Windows.. found this .. is there anything to do to help with this or is it basically that GraalVM folks need to sort something out?


@sammikko The issue is like this. You need to install a C++ redistributable on the system where the binary is compiled. Also you need to install from the command prompt that comes with this, so certain dlls are in scope (if I understand correctly). But these dlls are not statically linked (afaik that's not possible yet with GraalVM on Windows). So when you copy the resulting binary to a different system, then it will crash because of a missing dll.


Also there is an appveyor Windows build that runs along each commit.


If you can find out a solution for Windows users, this is welcome. You might also be able to find out of you can just run the linux binary with WSL2.


There is an issue on Graal for the dll stuff, but there hasn't been any news there for a while.


right ok.. I managed to build the exe using the instructions.. but there is no output.. also tried to copy msvcr100.dll in the same dir as exe, but no luck.. it starts but there is no output.. without --lint it does display the usage instructions tho


ok, ill try to look into it.. new to GraalVM too..


FWIW you can always run clj-kondo on the JVM as a lib or uberjar, but that won't be pleasant in an editor.


yeah.. ive tried it on osx.. its nice that its so fast.. good work 🙂


Might also be worth looking into GraalVM documentation around Windows. Maybe things have changed meanwhile.


It would be easiest from a maintenance standpoint if WSL2 was an option.


Not sure about this. I'm not using Windows frequently and don't know a lot about the OS internals.


What could also work is writing an nREPL integration for clj-kondo, so you run it as a lib inside your editor REPL.


This would be editor specific and up to contributors to step in.


right.. do you mean like starting up the clj-kondo on JVM but keeping the process alive and feeding it the "files" with some protocol ?


like cider-nrepl which is also a development-time library which lives in your REPL process


maybe you don't even need nREPL, haven't thought this through a lot


well its good to have options 🙂 ill need to do some reading on GraalVM etc.. thanks for the help!


I started doing clj-kondo because I wanted additional linters to joker. But in time I think it caught up with joker pretty well.


I have a hard time coming up with a feature that's not already in clj-kondo.


that's for unresolved symbols I guess


clj-kondo has a slightly different take on macros: you can teach it to lint custom macros as clojure.core macros. for example: lint manifold.deferred/let-flow as clojure.core/let


I would say: spend 20 minutes watching my talk at ClojuTRE to learn what it can do and then decide if you want to install it.


It also helps you with getting rid of refer :alls.


I have only done one recorded talk on it, so yes 🙂


I explain about the difference with other linters in the talk as well


I'm seeing a false positive being caused by clj-kondo not ignoring a defn that I have tucked away in a (comment) block. I took a look through the issues on github but didn't spot anything similar, is this a known issue? Would you like me to create an issue?


it's a design choice: comments often contain example code that I still want to have linted


if you want to ignore comments there's an option for that. but you can also choose to use uneval to comment out the defn.


That makes sense, though in this specific case of defning a function, it seems like the linter picking up the commented out function signature could cause other false positives in non-commented code


true. personally I don't put defns in comments though, just calls (like a REPL session that could become a unit test)


yeah, my next comment would be that I probably should be leaving this in here like this. It's an unfinished bit of code that I want to record but come back to later


I'll just prefix the fn name with _ for now


thanks 🙂


@sammikko fwiw, my last understanding of the situation was that one significant issue was this: i'm not as confident as others regarding whether there isn't something one can do about the dll as i got some private assembly clj-kondo working to deal with the dll part. also, i think there's a chance at an ugly work-around: > using an additional program that can handle stdin / stdout communications properly to have it act as an intermediary / wrapper around Windows native-image programs generated from Clojure source. (see the additional program would write what it receives from the invoker to disk and clj-kondo would read from disk -- after processing, clj-kondo would write the results to disk and the additional program would read them back and send them back to the invoker appropriately. the additional program could be written in rust, go, nim, etc. i got wiped out working on this before and have not seen any activity on oracle's side. i also think it would all-around be better to not be using dlls when you don't have to (see: for details)


good work digging into this.. I tried your patch where in was changed to System/in and out to System/out... It seems to work different if I have .clj-kondo directory in effect with config.edn... even with the patched version, it crashes if I lint my project directory having .clj-kondo. If I try the same dir without .clj-kondo, it works and outputs the same warnings as in OSX..


I'm trying to "debug" it using Sysinternals Process Monitor tool.. it seems that it processes all the files, but then in the end it tries to call QueryAllInformationFile for .clj-kondo\.cache\2019.09.23-alpha-SNAPSHOT\lock resulting in BUFFER OVERFLOW


I didn't find any difference with msvcr100.dll, tried putting in same dir as .exe (dir is in PATH), current directory etc..


I'm not really familiar with windows internals... know the basics..


it just crashes in the end, probably when trying to output something...


how did you get the stack trace for the crash? maybe i can try the same..


it may take me a bit to recreate the context due to various factors including an aging brain 🙂 if you didn't see it already, here's a repository documenting what i think is a native-image issue: -- it should have instructions on ending up with a stacktrace. for the dll side of things, i don't have anything written up, but i can dig up the sxs private assembly stuff that seemed to work if you think that might help. let's see if i can attach it here -- the version of clj-kondo is from a bit back, but iirc, the important bits are the specific manifest files along with things being consistent with what's described within them.


ok, that seemed to work...


if you do build your own clj-kondo.exe on windows successfully, you may find that it works better when launched from within the special console "Windows SDK 7.1 Command Prompt" setup provided by windows 7 sdk. i think we found that the built executable tended to work better on the machine / environment where it was built. i got hard-to-explain varying behavior depending on which shell the executable was launched from. the 4 shells i tested among are mentioned at the constdin repository linked above. regarding the build process, i had a lot of difficulty getting the build environment set up appropriately -- a straight-forward install of the windows 7.1 sdk just would not work. fwiw, here are my notes: -- but may be you have this all working already 🙂


i'm not really familiar with windows internals either. regarding "buffer overflow", i reached a similar conclusion that in this case what process monitor is telling us is not what security-conscious folks usually are concerned with.