JetBrains/intellij-scala

Scala plugin for IntelliJ IDEA

ruslan

@unoexperto

Cannot parse intersection types in IntersectionTypes

Am I missing anything ? I'm on 2020.1 EAP with nightly Scala plugin

Pavel Fatin

@pavelfatin

@unoexperto Please try to re-import the sbt project (via sbt tool window)

ruslan

@unoexperto

@pavelfatin Oh wow. Everything is clean! Impressive work, guys. When are you estimating to be officially done with Scala 3 support ?

Rafael Merino García

@imrafaelmerino

in my project, everything is clean as well and I'm using given, using, if-then-else, no new keyword when possible and indentation over curly braces

Pavel Fatin

@pavelfatin

We may announce the support officially in the 2020.1 release. As to when it's "done" - it's not that simple, and, to some extent, depends on Scala 3 itself (it's still under heavy development).

Pavel Fatin

@pavelfatin

@unoexperto

Hey guys. I'm trying dotty-example-project with new IDEA pluging and not sure if it's plugin or my code that is problem.
In ContextQueries.scala lines 42,43 code doesn't see implicit executing context.
Importing scala.concurrent.ExecutionContext.global in scope doesn't help.
How is it supposed to work now ?

(It's probably reasonable to use the "intellij-scala" Gitter rather than the "dotty" one)

"doesn't see implicit executing context" - i.e. there's red code or...?

ruslan

@unoexperto

@pavelfatin I figured it out. What happened is moving files to new package silently removed import ExecutionContext.Implicits.global line in ContextQueries class.

@pavelfatin Perhaps IDEA should not modify imports when moving classes from one package to another ?

Pavel Fatin

@pavelfatin

Definitely. Thanks for the info!

Hanns Holger Rutz

@Sciss

I usually leave the default of IntelliJ watching build.sbt and asking me if I want to import the changes (so this is manual confirmation not auto-import). I have one project though, where I must have checked some "never" box, and so it doesn't seem to watch build.sbt (so I have to open sbt settingsand refresh explicitly every time); I searched through the preferences and project settings, and could not spot where this setting is saved. Can I reset the default behaviour without having to wipe the .idea directory?

OlegYch

@OlegYch

i think this is the setting http://prntscr.com/rezt7e

oh you mean i doesn't even notice the changes?

sounds like a bug or non-standard project

Hanns Holger Rutz

@Sciss

Yes, it doesn't notice changes. Even if I select auto-import. By the way, I cannot find the action in your screenshot, seems missing in my version (using latest stable plugin)

build.sbt looks not unlike all my others. I will try to wipe .idea and see if it helps

Yes, now it seems to work again

nafg

@nafg

Lately, importing SBT builds fails if "download SBT sources" is checked

[error] (updateSbtClassifiers) lmcoursier.internal.shaded.coursier.error.FetchError$DownloadingArtifacts: Error fetching artifacts:
[error] https://repo1.maven.org/maven2/org/webjars/envjs/1.2/envjs-1.2-sources.jar: not found: https://repo1.maven.org/maven2/org/webjars/envjs/1.2/envjs-1.2-sources.jar
[error] https://repo1.maven.org/maven2/com/google/javascript/closure-compiler-externs/v20190513/closure-compiler-externs-v20190513-sources.jar: not found: https://repo1.maven.org/maven2/com/google/javascript/closure-compiler-externs/v20190513/closure-compiler-externs-v20190513-sources.jar

This is true regardless of sbt shell setting

Justin Kaeser

@jastice

@nafg which sbt version?

nafg

@nafg

@jastice I guess ~latest, 1.3.8

Justin Kaeser

@jastice

does it fail lately with change in sbt version, in scala plugin version, or change in dependencies?

OlegYch

@OlegYch

sbt/sbt#5374

Justin Kaeser

@jastice

thanks

nafg

@nafg

@jastice maybe it's possible that if updateSbtClassifiers fails, it shouldn't cause it to lose everything else

The same thing with project sources

Isolate failures so they don't cascade, so to speak

Justin Kaeser

@jastice

yeah not entirely trivial in the current implementation I think since it's just all based off the sbt task graph

OlegYch

@OlegYch

nafg: disable 'get sbt sources'

or exclude those dependencies

or fix coursier

or disable it

nafg

@nafg

@jastice how does sbt communicate with intellij these days, is it writing an xml file to a known location?

yeah it says Writing structure to /tmp/sbt-structure.xml...

@jastice why not break it into separate commands and write each to a separate file, then don't assume if sbt failed everything is bad; take whatever xml files exist

So there could be one xml file for each of {project,sbt}-{jars,sources}

that way if any of them fail, the others, or at least those that ran first, are still there

Justin Kaeser

@jastice

@nafg we might do that but it doesn't feel worth it to mitigate bugs limited to specific sbt versions tbh

nafg

@nafg

@jastice it's not, often I might have some plugin or library dependency that depends on some artifact that for whatever reason doesn't publish a source jar

Justin Kaeser

@jastice

yes, but only specific sbt versions cause this to be an error

nafg

@nafg

I see

Justin Kaeser

@jastice

so if you set project to 1.3.6 and disable automatic sbt upgrading it should work

nafg

@nafg

what is automatic sbt upgrading

Justin Kaeser

@jastice

"allow overriding sbt version"

nafg

@nafg

What does that do exactly?

Justin Kaeser

@jastice

it upgrades the project-configured sbt version to use latest known by scala plugin when starting sbt shell

nafg

@nafg

Maybe you should change the behavior to "forces to use sbt version latest supported by scala plugin" ;)

Where communities thrive

People

Repo info

Activity