def main(args: Array[String]): Unit = ... ) and I can't find a way to build it, event with nightly builds for the scala plugin, do you know if it is possible (I even can't run it if it's not in an abject (like possible now with scala3) ?
4 replies
I have a question about Intellij/SBT integration.
By default, SBT allows scala source to be located at src/main/scala or in the root of the project directory. This later option isnt widely known, but it documented at https://www.scala-sbt.org/1.x/docs/Howto-Customizing-Paths.html#Disable+using+the+project%E2%80%99s+base+directory+as+a+source+directory
As a result, there existing SBT projects where sources are all in the base dir. Ive found that IJ doesnt add the base dir as a Source folder when importing an SBT project, even though SBT by default supports it as a source dir.
One can add it manually, and then IJ presentation compiler works properly. But it gets wiped out the next time the project imports from SBT, so a poor workaround.
Is there a way to make IJ/SBT integration respect the sourcesInBase SBT setting?
2 replies
2 replies
Foo & Bar case class out of the object main but it failed either...
https://youtrack.jetbrains.com/issue/SCL-19871
Can some one authoritative check out with this issue? https://youtrack.jetbrains.com/issue/SCL-19871
1 reply
Hello together. Can I change the root directory of the "sbt shell" in IntelliJ?
I have a project structure like this:
project
├── backend (sbt)
└── frontend (angular)
I have the feeling, that if I open the "sbt shell" of IntelliJ Plugin, it will launch in the root directory. Because there is no build.sbt and project directory, it gets created ...
Would be nice if you can help me here.
Thanks!
2 replies
:point_up: Edit: It does work. I end up with two modules - one of them is a sbt project, the other is an angular one.
But maybe this is the "key" here and you pointed me into the right direction - maybe I should just open two IntelliJ projects separately - one for the angular project and one for the sbt project. In that way, the SBT shell should work as expected.
Thanks for your reply :-)
1 reply
:point_up: Edit: It does work. I end up with two modules - one of them is a sbt project, the other is an angular one.
But maybe this is the "key" here and you pointed me into the right direction - maybe I should just open two IntelliJ projects separately - one for the angular project and one for the sbt project. In that way, the SBT shell should work as expected.
The only thing I am not sure about is the VCS integration then - because its a single repo. But I will check this out.
Thanks for your reply :-)
I've just spottted a concurrent write error logged in the BSP project import. I can't share the logs at the moment as I spotted it on a client's network and I don't have permissions to send data out.
The racing threads appear to be at:
The latter calls setLanguageLevel and is guarded by a runWriteAction. The former calls setSdk and is not guarded by a runWriteAction.
BspMetadataService appears to be analagous to SbtModuleExtService in terms of its write-actions. But that could be buggy as well :)
Hello everyone, I am writing a macro extension plug-in based on Scala plug-in.
How can I make intellij idea prompt withthisconstructor generated by myself? I usedSyntheticMembersInjectorand so on, but it didn't meet the expectation.
By the way, there's nothing wrong with other methods, only thethisconstructor. I wonder if I missed something important? Is there such an example? (my template isdef this(……) =this(...)) Thanks.
Hello everyone, is there any way to solve this problem? Thank you.
I spotted an "Outdated Stub In Index" exception in the Scala Plugin. The call tree included ScalaLineMarker -> SamUtil.SamTypeImplenetation. This called down into our custom extension implementing SyntheticMembersInjector. I just noticed that the injector is poorly implenented, it is matching annotations in a way the triggers stub trees to be forced into full trees; the inefficent getNode.getText rather than findAnnotationNoAliases is what led into the PsiFileImpl.loadTreeElement.
We are removing the call to getNode.getText here, but I am left wondering whether there is a problem in ScalaLineMarker itself. Does the SAM line marker provider (or one of the utilities that it calls) need to be made DumbService-aware, ie return a default answer during re-indexing?
Cannot process toolwindow sbt
java.lang.AbstractMethodError: Missing implementation of resolved method 'abstract com.intellij.openapi.externalSystem.settings.AbstractExternalSystemSettings getSettings(com.intellij.openapi.project.Project)' of abstract class com.intellij.openapi.externalSystem.service.task.ui.AbstractExternalSystemToolWindowFactory.
at com.intellij.openapi.externalSystem.service.task.ui.AbstractExternalSystemToolWindowFactory.shouldBeAvailable(AbstractExternalSystemToolWindowFactory.java:35)
at com.intellij.toolWindow.ToolWindowSetInitializerKt.beanToTask(ToolWindowSetInitializer.kt:262)
at com.intellij.toolWindow.ToolWindowSetInitializerKt.beanToTask(ToolWindowSetInitializer.kt:248)
at com.intellij.toolWindow.ToolWindowSetInitializerKt.access$beanToTask(ToolWindowSetInitializer.kt:1)
at com.intellij.toolWindow.ToolWindowSetInitializerKt$computeToolWindowBeans$1.accept(ToolWindowSetInitializer.kt:278)
at com.intellij.toolWindow.ToolWindowSetInitializerKt$computeToolWindowBeans$1.accept(ToolWindowSetInitializer.kt)
at com.intellij.openapi.extensions.impl.ExtensionPointImpl.processWithPluginDescriptor(ExtensionPointImpl.java:301)
at com.intellij.toolWindow.ToolWindowSetInitializerKt.computeToolWindowBeans(ToolWindowSetInitializer.kt:274)
at com.intellij.toolWindow.ToolWindowSetInitializer$1.get(ToolWindowSetInitializer.kt:101)
at com.intellij.toolWindow.ToolWindowSetInitializer$1.get(ToolWindowSetInitializer.kt:83)
at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1700)
at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.exec(CompletableFuture.java:1692)
at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
at java.base/java.util.concurrent.ForkJoinPool.awaitQuiescence(ForkJoinPool.java:2984)
at com.intellij.idea.StartupUtil.start(StartupUtil.java:270)
at com.intellij.idea.Main.bootstrap(Main.java:118)
at com.intellij.idea.Main.main(Main.java:79)
Hi, I have a macro that generates an implicit with a dependent type member. Like this:
trait RelativeComplement[A, B] {
type Out
}
object RelativeComplement {
type Aux[A, B, Out0] = RelativeComplement[A, B] { type Out = Out0 }
implicit def materialize[A, B, Out]: Aux[A, B, Out] = macro RelativeComplementMacro.materialize[A, B, Out]
}(this is Scala 2)
I'd like to make it so IntelliJ knows what Out will be, given A and B, instead of inferring Nothing or something like that. I saw the 2015 blog post about SyntheticMembersInjector, but that doesn't seem to apply to this case (since it only lets you inject members into a trait or class or object definition, as far as I can tell). Is there any way to accomplish what I'm going for? Maybe a different extension point? Or is there just hard-coded support for some core Shapeless macro DepFns and no way to add others?
RelativeComplement[A with B with C with D, B with D]#Out will be A with C. The macro is just a few lines of code. And it's usually not even necessary – just, when it is necessary, it's necessary. The compiler does fine with it, just IntelliJ always says Nothing.
Hi, I've a question regarding the transitive dependency behavior of module dependencies. I'm referring to the "Export" option described in this section of the documentation. https://www.jetbrains.com/help/idea/2022.1/working-with-module-dependencies.html#dependency-scope
I read it that way that dependencies, which do not have the export option enabled are not propagated to dependent modules. But it looks like that this is not the case. When running the dependent module, all library dependencies of the module dependencies are also present in the downstream classpath. But my expactation was, that only those libraries are propagated downstream, which have the export option enabled, in my case none.