Some releases are about adding more features. In this release, we’ve focused on improving the existing features of the Scala plugin. These features are the bread and butter of Scala programmers, so we hope the improvements will make our day-to-day work much easier. Here goes:
- Highlighting of for-comprehensions
- Find Usages for implicits
- Decompile to Java for Scala .class files
- Customizable Scalafmt version
- Separate HOCON plugin
- Error highlighting improvements
Highlighting of for-comprehensions
For-comprehensions can sometimes be… incomprehensible. Being a syntactic sugar for composing foreach, map, flatMap, and filter / withFilter operations, for-comprehensions look very differently from the implied method calls. As a Scala programmer, you can probably desugar for-comprehensions in your mind’s eye and, as long as your code compiles, all is well.
The problem begins when there’s an error (yes, once in a while this does happen, you know). An error inside a for-comprehension is actually an error inside its desugared form. Highlighting such an error is tricky, because, in addition to the desugaring, this requires some kind of reverse transformation (“error sugaring”?).
In this release, we present a solution that makes errors in for-comprehensions more comprehensible:
We treat <- as a reference to the corresponding foreach / map / flatMap method, and we treat if as a reference to the filter / withFilter method.
This also lets you invoke GoTo, Quick Definition, and Quick Documentation actions in those spots. For example:
The binding of <- and if symbols to the method calls makes it possible to display implicit arguments:
If that looks a bit unusual, it’s due to the limitation of the language syntax – there’s no way to pass explicit arguments to implicit parameters in a for-comprehension (should we create a SIP?). However, this is consistent with the chosen schema, and is required for showing implicits-related errors:
On top of all that, we’ve improved the desugaring of for-comprehensions. So, if you’re curious about what is behind the curtain of syntactic sugar, you can press Alt + Enter and Desugar for comprehension (or you can rely on the Code | Desugar Scala code action).
Find Usages for implicits
Speaking of implicits, previously the implicits hints allowed you to see usages of implicits and go from usages to definitions, but you couldn’t do the reverse – go from definitions to usages, by invoking Find Usages. Well, now you can:
This capability relies on bytecode indices, and can also be used to locate other things that are hidden behind the syntactic sugar, and not present in the source code “as is”, including:
apply/unapplymethod calls,- Single Abstract Method (SAM) type instantiations,
foreach/map/flatMap/filter/withFiltercalls via a for-comprehension (this nicely complements the for-comprehenison highlighting).
The feature goes beyond the typical search. While you can emulate Find Usages by means of a full-text search (albeit imperfectly), you cannot rely on text to find something that is not there. Together with the View | Show Implicit Hints, this feature puts you in control of the ‘invisible’ things.
Decompile to Java for Scala .class files
Did you know that IntelliJ IDEA can decompile .class files to Java? Now this is also possible for compiled Scala files. Suppose you have a third-party class that does something, but you don’t know what – because there are no sources at hand:
That’s where the Decompile to Java may come in handy:
Customizable Scalafmt version
While we supported the scalafmt formatter last year, the Scala plugin could use only a single, bundled version of scalafmt. Now IntelliJ IDEA can automatically download and use whatever version of scalafmt you configure in .scalafmt.conf:
The feature relies on the scalafmt-dynamic module, and so needs an Internet connection. Other than that, this doesn’t require any additional action on your part – everything just works (or at least we hope it does – let us know if it doesn’t for you!).
By the way, we’re also constantly improving the build-in IntelliJ IDEA formatter too 
Separate HOCON plugin
Hocon is a “Human-Optimized Config Object Notation” format used by many ‘enterprise’ Scala frameworks such as Akka or Play. Because of that, previous versions of the plugin bundled the support of HOCON together with the support of Scala. And yet not everyone who uses Scala needs HOCON.
In this release, we’ve extracted the HOCON support into a separate repository and a separate plugin:
If you do need HOCON, you don’t have to do anything – the HOCON plugin will be automatically installed with the Scala plugin update (and, subsequently, updated). But now you have more flexibility – if you don’t use HOCON, you can easily disable or remove the HOCON plugin in Settings | Plugins.
(Kudos to Roman Janusz for developing the HOCON plugin!)
Error highlighting improvements
While we’re constantly working to make error highlighting even better, sometimes we improve it a lot… like this time! Here are a few highlights:
- Partial unification and type variable unification in general.
- Constructor highlighting, and calls to private constructors.
better-monadic-forcompiler plugin:implicit0feature.kind-projector: value level polymorphic lambdas.simulacrum: higher-arity type constructors.
Here’s an example to inspire you:
We’re also refactoring our code to make it cleaner and clearer, so if you’ve ever wanted to contribute to the Scala plugin, now is a better time than ever.
While we’ve tried hard to prevent and avoid bugs, absolute perfection is impossible to attain. We’re planning a bugfix release, so please report any issues to YouTrack so that we can fix them as soon as possible.
By the way, the IntelliJ Scala plugin now has an official Twitter account: @IntelliJScala – feel free to follow us for more news and updates.
Develop with Pleasure! No, Drive to Develop! Oh… never mind. Just enjoy!
(and, your feedback is welcome)
Sincerely,
The IntelliJ Scala plugin team
