Although IntelliJ Scala Plugin uses Scala compiler proper to generate the actual bytecode, it seems to use its own implementation of presentation compiler to provide real-time type-aware error highlighting in the editor:
syntax highlighting feature that is implemented by Idea's Scala
plugin and it requires immediate re-processing of all the files you
change in a way similar but now exactly the same as what the real
compiler does.
This might be the reason why sometimes projects build successfully and yet IntelliJ shows false positive red underlines in the editor. This seems to be the case even if use sbt shell is selected as evident by open ticket SCL-11079
By default, the sbt compile should mark additional errors it finds in
the editor and project view. False positive errors reported by the
internal annotator should be removed if possible. There should be an
option to use sbt output as the "single source of truth" for
highlighting errors, at the cost of instant error highlighting.
or if project is imported as BSP project
sbt shell indeed won't help with error highlighting in the editor, nor
will BSP (for the time being). In-ide highlighting uses a method that
is completely separate from regular compilation
Is there anyway to configure IntelliJ to use Scala out-of-the-box presentation compiler instead of its own custom implementation such that we can decrease the chance false positive errors akin to what Metals provides?
According to show bsp diagnostics in editor SCL-16610 there exists a IntelliJ registry flag
scala.highlighting.compiler.errors.in.editor
which enables experimental feature
As error highlighting using the built-in parser and type-checker
continues to be a problem for the Scala plugin, we can experiment with
using compiler output from BSP... Potential downsides: Less rich error highlighting on type mismatch
problems: BSP and the compiler expose only raw string messages and
positions. We would lose type diffs and type error hints.
Here are the steps that made it work on my machine
Install JetBrains Toolbox which enables installation of Early Access Programs alongside releases (such that you can revert to your working system if anything goes wrong)
Install 2020.1
Make sure Nightly Builds update channel is set under Preferences | Languages & Frameworks | Scala | Updates
Remove .idea from the root of the project: rm -fr .idea
Re-import the project and select BSP project
There should be .bloop directory under project root if all OK
Open IntelliJ registry: Help | Find Action... | Registry
Set key scala.highlighting.compiler.errors.in.editor
Related
There is a myriad of development tools and terms in the ecosystem, for example, language server, build server, Metals, BSP, LSP, Bloop, Zinc, Coursier, incremental compiler, presentation compiler, etc.
I was wondering if someone could demonstrate how they fit together and briefly explain relations and differences. Specifically I am hoping for a diagram and answer along the lines of Making sense of Scala FP Libraries. For example, here is my attempt
(Concept) (Example implementation)
--------------------------------------------------------------------
IDE Visual Studio Code
| |
Scala IDE plugin Metals Visual Studio Extension
| |
Language Server Protocol Microsoft LSP
| |
Scala language server Metals
| |
Build Server Protocol BSP from JetBrains and Scala Center
| |
Scala build server Bloop
| |
Build tool sbt
| |
Dependency resolution Coursier
| |
Incremental compiler Zinc
| |
Presentation compiler parser and typer phases of scalac
| |
Bytecode generation remaining compiler phases
IDEs like Intellij or (once) Scala IDE are intended for "smart" development, where the editor tells you if your code is correct, suggest fixes, autogenerate some code, provide navigation around code, refactoring - in other words many features that expand way beyond simple text edition with perhaps only syntax highlighting.
Intellij has a Scala extension which makes use of their own reimplementation of a Scala compiler - they needed that for better partial compilation and intellisense working even if part of the code is broken. The import build definition from other build tool (e.g. sbt or bloop) and from then Intellij doesn't reply on anything external (unless you use some option like "build with sbt").
Scala IDE relied on Scala presentation compiler for intellisense. As you can read on scala-ide.org:
The Scala IDE for Eclipse uses the Scala Presentation Compiler, a faster asynchronous version of the Scala Compiler. The presentation compiler only runs the phases up until and including the typer phase, that is, the first 4 of the 27 scala compilation phases. The IDE uses the presentation compiler to provide semantic features such as live error markers, inferred type hovers, and semantic highlighting. This document describes the key classes you need to know in order to understand how the Scala IDE uses the presentation compiler and provides some examples of interactions between the IDE and the presentation compiler.
Every other editor/IDE is intended to use Language Server Protocol - LSP is Microsoft's invention in order to standardize a way of supporting languages within different editors (though they invented it for the sake of VS Code) that would allow them to provide IDE features. Metals (from ScalaMeta Language
Server) is LSP implementation for Scala. As you can read here:
Code completions, type at point and parameter hints are implemented using the Scala presentation compiler, which is maintained by the Scala compiler team at Lightbend.
You can add it to VS Code using Scala Metals extension.
sbt, gradle, mill, fury, cbt, etc are build tools which use something like ivy2 or coursier to resolve and download dependencies, and then use Zinc incremental compiler in order to provide ability to (re)build things incrementally to normal compiler. Build tools can run tests, generate artifacts and deploy them to repository.
bloop is a solution to problem that compiletion is fast if JVM is hot, and JVM gets cold every time you kill your build tool/IDE. For that reason you use nailgun to keep some JVM warm, running build tasks in background. On its own bloop cannot generate configuration and in general it is something that should be generated by other build tool to speed up compilation during development. Protocol used to communicate with bloop server running in background is build server protocol (bsp).
Coursier, while is used primarily for dependency resolution, can also be used to install scala programs. Some of the noteworthy programs that you can install are:
scalafmt - scala formatter
ammonite - alternative REPL to scala which provides a lot of nice features
scalafix - code-rewriting tool which is used to provide automatic code migrations
I gave up on describing thing in table, as it would much better be shown on a graph, but since SO doesn't support that visuals I just resorted to a plain text.
Suspicious that at least a part of this post might be an April Fool's joke, I set about installing Dotty on my Linux laptop and was pleased and surprised to discover that it seems to be completely straight - I was able to get the Fibonacci function as given in German working fine from the REPL.
Now I want to code in Dotty/Scala in German in the IntelliJ IDE, but have not so far managed to achieve this, or for that matter English Language 'Hello World' for which will the Dotty compile fails with an SBT error, see below (there are no errors in the IntelliJ code window for the object).
Opening a new Dotty project via the IntelliJ new project dialogue puts a new instance of Dotty in my .ivy2 directory, distinct from that I use in the REPL. I have found Felix Mulder's Dotty plugin but I'm not sure how to use a plugin from source. After the project has set itself up:
German keywords are not recognised in any new Scala file I create in src > main.
In build.sbt some operators and keywords are not recognised
In build.sbt each entry gives the error Expression Def.Setting[SomeType] must conform to DslEntry in SBT file
I get this error log warning (twice):
Binary version (0.1.1-20170410-0bd7821-NIGHTLY) for dependency
ch.epfl.lamp#scala-library;0.1.1-20170410-0bd7821-NIGHTLY in
default#skala_2.11;0.1-SNAPSHOT differs from Scala binary version in
project (2.11).
which I think might be a consequence of the skala and dotty paths in my PATH environment variable.
Searching on the error message in point 3 led me here: I can switch to an unbundled SBT I know to be good easily enough, but HW will still not compile, instead giving a quite lengthy SBT error.
Unfortunately I don't understand the syntax of the entries in build.sbt well enough to change them according to the advice of murmelssonic. If I just have to learn that then OK, I'm sure I can.
I believe I have read posts which suggest that the build.sbt errors can be ignored as they do not actually lead to compile errors, but I can't confirm this as I can't compile anything yet. Even if this be true, I want to eliminate these, the better not to obscure legitimate warnings and errors.
My question might be better expresses as simply "How do I install the Dotty plugin for IntelliJ?", but I'm not sure that's the complete solution to this collection of symptoms.
System info:
OS Kubuntu 16.10
Java 1.8_121
IntelliJ 2017.1
Dotty v0.1.1-20170410
SBT 0.13.13 and 0.13.15 (each attempted) via IntellliJ dialogue
SBT 0.1-SNAPSHOT (from sbt version on command line in sbt dir, used by changing IntelliJ settings).
While Skala is a natural development for the Scala language, seeing how its creator Martin Odersky is a German and should have implemented German keywords in the first place, JetBrains is a company founded by Russians. As such, we are committed to exporting cyrillic keywords into the world of programming.
In a way, IntelliJ-Scala is already an alternative compiler for the Scala programming language specification. This will be increasingly true with the release of the all-new Скала plugin for IntelliJ!
This is a totally official statement by the IntelliJ-Скала team's only German member.
I am using IntelliJ IDEA 14.0.3 to develop a Play 2.3.7 application using the Scala 1.3.3 plugin.
The attached screenshot shows that IntelliJ underlines the parameter to a render method as invalid when, in fact, the system compiles and runs successfully both in IntelliJ and at the command line (using Activator):
Another user has reported this problem in IntelliJ when the view template file uses Scala-specific syntax (i.e. Form[formdata.ContactFormData]) while the controller uses Java-specific syntax (i.e. Form<formdata.ContactFormdata>). That is the case here as well.
The sources to illustrate this problem are available at: https://github.com/philipmjohnson/intellij-play-error-highlight-problem
Is this indeed a bug in IntelliJ or its Scala plugin? Are there any workarounds?
My team and I have this same issue, using Intellij 14.0.3, Scala 1.3.3 plugin and Play 2.3.8.
To workaround this I open File --> Project Structure, then click on "Modules" on the left side bar. Adding target/scala-2.11/src_managed/main to the sources eliminates these reverse routing underlines. Make sure that the root target directory is not in the excluded folders.
One thing to note however, is that Intellij seems to remove this from the sources from time to time, causing much annoyance...
The above solution works, but I think it might be useful to document a ripple effect: if you are using the Checkstyle plugin, then after adding those additional source root directories, Checkstyle will process those auto-generated Java files and (in all likelihood) raise a number of (spurious) warnings.
After fiddling around a bit, it appears the easiest way to get Checkstyle to skip those files is to specify the "Inspection Scope" as the "Default" version control scope. Since you will almost certainly exclude the target/ directory from version control, this parameter to Checkstyle keeps it on the straight and narrow. Here's a screen image illustrating the setting:
I am trying to set a breakpoint in a Scala Macro implementation using the Eclipse IDE and failing
Firstly: Scala Macros Rock! Up to now I have preferred Clojure to Scala, but with macros I'm no longer sure
I'm trying to create a macro that will return the toString of a function and the function itself. When that works I'm going to make a new function with a sensible toString. Ah happy days.
But I need to be able to debug the macros. I use Eclipse (20110615-0604), with Scala (2.10.1). I downloaded the scala-compiler-2.10.1.jar and the code from http://www.warski.org/blog/2012/12/starting-with-scala-macros-a-short-tutorial/ now works. I've written a couple of simple macros as well. The macros are in an eclipse project "ScalaMacro" and the code that uses them is in a separate project "HelloScalaMacro"
I'd now like to debug them
Following the instructions at http://docs.scala-lang.org/overviews/macros/overview.html I have created a runtime configuration with scala.tools.nsc.Main as the entry point. I've added -cp HelloScala.scala, and when I run the configuration it actually seems to compile the code (if I put errors in, it reports the errors correctly).
Unfortunately the instructions imply that a breakpoint in the macro implementation should cause Eclipse to pause. It doesn't.
I've done the usual: google search for Eclipse/Scala macro/Debug/Breakpoint, read all the stackoverflow questions in the scala-macro tag, and played around a lot with every eclipse setting I can find.
So if any of you out there know how to set breakpoints, could you let me know how: is it an eclipse version / scala version / ... issue?
I haven't tried this myself, and in principle it is as likely (or more likely) to fail as what you've already tried, but if successful it could be more convenient to you.
To try this you should have Scala-IDE along with the source feature installed. Make sure you are working off of an Eclipse installation that is either "Eclipse Classic", "Eclipse for RCP Developers", or a similar concoction you came up with on your own.
You will also want to install the Equinox Weaving Launcher plugin, that will allow you to create an "Eclipse Application with Equinox Weaving" launchers.
Now:
Create a new workspace
Create a Scala project
Plant your macro code in that project
Add a break point in the macro source
Getting ready to debug:
Create a new "Eclipse Application with Equinox Weaving" debug launch configuration. Give a name more elegant than "New_configuration".
under "location", point it towards a new different workspace directory
under the "configuration" tab, provide something like "-Xmx1536m"
By default, all plugins available to your running Eclipse instance should be available to the instance you are about to launch. Eclipse may need some cajoling in order to include a non-plugin project in the classpath -- if this doesn't work, that's the first thing I'd try to look at.
You will now want to launch the debug configuration.
Depending on your Scala-IDE version, you may encounter a "Multiple launchers available -- Select one..." warning. I'd go for "Equinox Weaving enabled Eclipse Application Launcher".
Once inside the Eclipse instance being debugged:
Create the project you want to use the macro
Make sure to add a dependency on the binary output
Add a small usage example of your macro to the project in the workspace being debugged.
Cross your fingers
Build
In theory, the launching Eclipse instance will now pause the instance being debugged on your break point.
The instructions given by Nadavwr (just below) were helpful, and I recommend them to other people.
The key solution for me was to realise that there are two projects involved, the project that defines the macro, and the project that uses the macro. Rather foolishly I was trying to debug the project that defined the macro
So the instructions as given in the documentation are correct, I just had to make sure I was running them in the correct project: obvious of course.
For the benefit of other people, I found it very helpful to use a command line scalac to get the command line correct: much quicker editing that, and controlling which directory I was in, then in eclipse
The other thing to realise for people thinking of using Scala Macros are that the error messages from running scalac directly are MUCH better than those from eclipse.
I have started using Play 2.1.0 and I would like to be able to use NetBeans to develop Play Java applications. I'm not really interested in using the IDE to run or test the applications since I can do that from the command line (not that I would mind if I could also have IDE support for that) but I would like to be able to open and edit my project in NetBeans without getting annoying errors where they don't really exist. I am currently using NetBeans 7.3 so I first tried to use the nbplay plugin, however it wouldn't recognise all my imports or managed classes produced by Play. I then tried to import the project as Eclipse project, as described in this and this question, which worked better, but while working my way through one of Play's Java tutorials I am still getting the following errors which make it really annoying to work with NetBeans:
I get an "Expected an operand but found error" error in main.scala.html where #content is used, although I have instructed the IDE to disable HTML error checking for this file.
In my model classes I get errors because the classes do not declare a no-argument constructor and have public variables for persistent attributes.
Any other errors I have not come across yet?
Has anyone managed to make Play 2.1.0 work with NetBeans without getting any of the above errors? I could probably live with the first one (although it would really annoy me) but the rest are showstoppers.
Be aware that the Java hints can be enable or disable in Tools -> Options -> Editor -> Hints -> Select java language.
NetBeans now has Native Support for Play Framework 2.3.x and above: http://nbpleasureplugin.com/documentation/installation.html No Command line needed at all.
The most important features are:
Create, run, debug and test your app directly in the IDE
Routes files support (Syntax coloring, Syntax Error highlighting, Autocompletion, Code navigation, Show implementation code (without navigate to source), Hint to Create method when it doesn’t exist, formatting, Mark occurrences)
Scala Template support (Syntax coloring, Syntax Error highlighting, Autocompletion, Code navigation, Show implementation code (without navigate to source), formatting, Mark occurrences)
application.conf support (Syntax coloring, autocompletion with documentation, formatting, mark occurrences)
Dependency Management (Search on Maven and add them to build.sbt)
2 Code Coverage too.s supported (jacoco and scoverage)
Test Single File
SBT file minimal support
Configurations (Formatting indentation, syntax coloring, port to use, activator parameters, etc.)
*Support play version from 2.3.x and above
Note: I created this plugin.
Also I see this could help you: How do I use Play Framework 2.0 in netbeans