I was more thinking in terms of a single run of the linter. Say ns A calls B/foo, will the analyzer, when analyzing A also have to look into B, and if so, when time comes to analyze B, could we reuse the result from analyzing A?
The analyzing code in eastwood is basically
(doseq [ns namespaces] (lint-ns ns))
so, if you want to analyze namespace A, namespace B needs to be at least loaded, doesn’t have to be analysed
FWIW @ambrosebs was looking into speeding up t.a by using Compiler.java as a backend, I don’t know where he’s at with it but you may want to talk to him
The analyzing code in eastwood is basically as you mentioned, but there is code before that to optionally generate a list of namespaces from the files in one or more directories (e.g. "src" "test"), and then to sort those namespaces in an order consistent with require/use between them, so that anything being required/used is analyzed earlier than a namespace that requires/uses it.
If a namespace is not in that list, any require/use's done by the namespaces on the list will still be performed, when that namespace's ns form is analyzed then eval'd.
Hello, How do I take a command line config like this
lein eastwood "{:namespaces [foo.bar.baz] :exclude-linters [:redefd-vars :bad-arglists]}"
and convert it so it works when invoked on the command line just as
lein with-profile +eastwood eastwood
, where the relevant section in
project.clj
is:
:eastwood {:plugins [[jonase/eastwood "0.2.5"]]
:eastwood {:config-files ["eastwood.clj"]}}
I’ve tried the following, but I’m still getting the warnings
(disable-warning
{:linter :redefd-vars ;;:bad-arglist
:if-inside-macroexpansion-of #{'clojure.core/try}
:within-depth 1})
(disable-warning
{:linter :bad-arglist
:if-inside-macroexpansion-of #{'clojure.core/try}
:within-depth 1})
ThanksTry this command line, to verify whether it is finding and loading your "config.clj" file: lein with-profile +eastwood eastwood '{:debug [:config]}'
I mean your "eastwood.clj" file
Just tried it @andy.fingerhut and this is the output that I’m getting:
Loading config file: eastwood.clj
It looks like the config file is getting picked up.@dotemacs That suggests that the disable-warning expressions are being read and evaluated, but aren't enough to disable the warnings you are seeing. The :within-depth argument is kind of fiddly -- I could have made it always "arbitrary nesting depth of thing X inside macroexpansion of Z", but wanted to give some limit there because otherwise it might disable unrelated things. Oh, also, clojure.core/try is not a macro, but a built-in primitive. I don't see any other examples of disable-warning that use :if-inside-of-macroexpansion-of #{clojure.core/try}, so that might be why it is not disabling any warnings here.
ah, i see
So is there a way to say: in this namespace, disable warnings for :redefd-vars, in a configuration file ?
The only way I can think of is to do a separate Eastwood run on that namespace, disabling warnings completely for the namespace.
Then for your run on "most of your namespaces", exclude that namespace.
So 2 separate Eastwood runs.
Sorry, I know Eastwood could really use a facility for fine-grained disabling of individual warnings, like other lint tools have (e.g. via comments you add to the code with a special linter-recognized syntax), but never got around to implementing that.
Ah I see
@dotemacs: I’ve done something similar for deprecations
Where I’ve made it possible to disable deprecations of certain vars.
via regexes.
(disable-warning
{:linter :deprecations
:symbol-matches #{#"^#'ardoq\..*"}})
I was thinking that this is just my fault that I don’t know how to configure eastwood
…
@slipset if you don’t mind sharing that setup, that would be great
Thing is that this is not supported for other linters than deprecations atm.
There is an issue in Eastwood already for the generic case
@slipset ok, so I’ve tried something similar for deprecations: Instance method 'public final void java.lang.Thread.stop()' is deprecated.
@dotemacs: what I showed you is brand-spanking new in 0.2.6
ah, ok
https://github.com/jonase/eastwood/commit/4945225bd5e2ab10980771b2f5e74fd44abb94b4
that might help as I was on 0.2.5… thanks for the heads up
I really needed this at work, since we have quite a bit of code that should be marked as deprecated, but we still want our code to pass CI.
So in this case, it was quite simple to add a regex-matcher to the var, since a var is deprecated.
I guess one could do something similar with bad-arglist, since that’s also bound to a var
and for redefd vars
What is it one usually say? issue/PR welcome?
if you at least make me an issue, I’ll have a new version out shortly.
So I upgraded to 0.2.6 and when I run it, it loads up 0.2.5… or am I reading it wrong:
$ lein with-profile +eastwood eastwood '{:debug [:config]}'
Retrieving jonase/eastwood/0.2.6/eastwood-0.2.6.pom from clojars
Retrieving jonase/eastwood/0.2.6/eastwood-0.2.6.jar from clojars
Loading config file: jar:file:/Users/alex/.m2/repository/jonase/eastwood/0.2.5/eastwood-0.2.5.jar!/eastwood/config/clojure.clj
Loading config file: jar:file:/Users/alex/.m2/repository/jonase/eastwood/0.2.5/eastwood-0.2.5.jar!/eastwood/config/clojure-contrib.clj
Loading config file: jar:file:/Users/alex/.m2/repository/jonase/eastwood/0.2.5/eastwood-0.2.5.jar!/eastwood/config/third-party-libs.clj
Loading config file: eastwood.clj
Exception in thread "main" java.lang.IllegalArgumentException: No matching clause: :deprecations, compiling:(/private/var/folders/k0/sgs2df8d0vq289q40rctw8p80000gn/T/form-init5659309845804878336.clj:1:125)
you most probably have two occurences of eastwood in your profiles.clj/project.clj
we have one in plugins and one in dependencies
seems like you only updated the one in dependencies?
yes, my ~/.lein/profiles.clj was the culprit, my bad…
As long as it’s not my bad, I’m happy 🙂
🙂
I’m off for a while…
ah, damn, I was just going to ask this:
(disable-warning
{:linter :deprecations
;;:symbol-matches #{#"^#'public\ final\ void\ java\.lang\.Thread\.stop*"}
:symbol-matches #{#"^#'public\ final\ void\ java\.lang\.Thread\.stop\(\)"}
;;:symbol-matches #{#"^#public*"}
;;:symbol-matches #{#"^#'java\.lang\.*"}
;;:symbol-matches #{#"^#'java\.lang\.Thread\.stop\(\)"}
;;:symbol-matches #{#"^#.*\.Thread\.*"}
})
none of the above work on avoiding the deprecation warning
the commented out and uncommented lines
the warning is this:
deprecations: Instance method 'public final void java.lang.Thread.stop()' is deprecated.
Not sure how to handle that
Hmm, interesting. Haven’t had the problem with deprecated java stuff.
Ah, I see it
Don’t escape the dot
As in, in the code or in my config above ?
oh, ok
#{#”.Thread.”} should work, although a bit greedy
#“\.*” is a regex marching zero or more dots.
let me try that
On phone so, all formatting is messed up.
#”.*” is a regex that matches anything.
Just tried all these:
(disable-warning
{:linter :deprecations
;;:symbol-matches #{#"^#'public\ final\ void\ java.lang.Thread.stop()"}
;;:symbol-matches #{#"^#'public\ final\ void\ java.lang.Thread.stop*"}
:symbol-matches #{#"^#.*Thread."}})
one sec, i see what you’re saying about the phone formatting…
even this
:symbol-matches #{#"^#.*Thread.*"}}
didn’t workOk. File an issue and I’ll see if I can figure it out later tonight.
ok, cool
Could I ask you to make a nominal repro-project on Github for me?
sure
Eh, minimal :)
Thanks!
sure
@slipset as promised the minimal example created and added as an issue: https://github.com/jonase/eastwood/issues/264 The real reason I’m dealing with this is because nREPL just had eastwood added to it. And I’m fighting all the warnings and trying to suppress them and this issue is one of them: https://github.com/clojure-emacs/nREPL/pull/23
Nice,
your eastwood.clj
was a bit messed up
(disable-warning
{:linter :deprecations
:symbol-matches #{#"public final void java.lang.Thread.stop\(\)"}})
works.
Just saw that, thanks