Just wonder what the status is and if there is any roadmap to release it. Also how does it differ from Wartremover and others in terms of goals?
Thx, Chris
(our prior most recent statement on this (in November 2016) was https://github.com/scala/scala-abide/issues/69#issuecomment-261976673)
At the time Abide started, way back in 2014, the Scala Center didn’t exist yet, Scalafix didn’t exist yet, and Scala.meta didn’t have a semantic API yet. Eugene Burmako wasn’t even born yet! (That’s not true, he just didn’t have his Ph.D.)
The situation now is very different. Scalafix exists and is moving full steam ahead at the Scala Center. Recent versions of Scalafix use Scala.meta’s new semantic API to support rewrites that take types into account, not just syntax.
Scalafix was originally conceived as a Scala 2 -> Dotty rewrite tool, but at Lightbend we think it will be also be useful and important as a tool for rewriting Scala 2.11/2.12 code for Scala 2.13 and beyond. (At the last Scala Center advisory board meeting, I got the impression that this was sinking in, though Scalafix’s readme and docs don’t reflect it yet.)
But what do Scalafix and Abide have to do with each other? Well, a Scalafix rule identifies problematic pieces of code and rewrites them. A linter like Abide identifies problematic pieces of code and… stops. Doesn’t rewrite them, just complains about them.
So it seems to me that we can discard Abide now, and that Scalafix ought to take its place as our next-generation linter. A linter rule can just be a rewrite rule without the rewrite part.
After all, why Abide started, what distinguished Abide from other linters, was that it used scalac’s actual parser and type-checker. But thanks to Scala.meta’s semantic API, Scalafix now uses them too, and makes it nicer for rule authors to interact with them.
I’m suggesting this in public for the first time. In particular, I haven’t run the idea by Olafur (author of Scalafix) yet. Oh wait, I guess just did. Hey Olafur, hey Scala Center, what do you think? Do you see any reason why Scalafix shouldn’t be our new linter too?
Seth
6 Likes
And spinning off this topic: I was in a discussion the other day about “semantic merge” – the possibility of building smarter and more correct diff/merge tools (for checkins and such) by using semantic information about the code. It occurred to me that scalafix and its underlying APIs probably make this much more practical than it is for most languages, if anybody wants a juicy project to tackle…
2 Likes
Do you see any reason why Scalafix shouldn’t be our new linter too?
Time/resources? 
We might also want to package it with a different name (scalalint?), since linters don’t “fix” code by definition.
It is definitely possible to build a linter with scala.meta now that the semantic api is taking shape. We could probably also reuse a good bit of the scalafix integration infrastructure, in particular sbt plugin + command line interface.
It will still require some work to port the linting rules from abide to scala.meta. My current focus is on rewrites. If someone is interested in building a linter with scala.meta/scalafix, talk to me! I am happy to discuss more details and provide guidance.
1 Like
The upcoming scalafix v0.5.0 release will add support to implement linters https://github.com/scalacenter/scalafix/pull/291 There will be at least one milestone release before 0.5.0 to try it out. Feedback on the lint API is very welcome. The only known quirk at the moment is that linters extend Rewrite. Please pitch in https://github.com/scalacenter/scalafix/issues/293 if you have suggestions for a better name that captures both linters and rewrites.
1 Like
recent blog post (by Olafur) with more on Scalafix’s growing capability as a linter: http://scala-lang.org/blog/2017/09/11/scalafix-v0.5.html