scalameta / metals

Scala language server with rich IDE features 🚀
https://scalameta.org/metals/
Apache License 2.0
2.1k stars 332 forks source link

No Buildtarget found #1028

Closed GrafBlutwurst closed 4 years ago

GrafBlutwurst commented 5 years ago

Describe the bug Metals on Emacs can't find buildtargets and only relies on the presentation compiler with the standard library. This means outside of stdlib, codecompletions are not available. Jump to definition also doesn't work and error reporting is unreliable.

The lsp-log buffer also pops up with no build target: using presentation compiler with only scala-library and metals-doctor with

image

(I tried resetting .bloop and .metals multiple times)

This happens both on 0.7.6 and 0.7.6+170-9eddd91f-SNAPSHOT

I was also able to reproduce the behaviour in VSCode though I have no experience with that editor so I can't really say what's going on. Interestingly there the import build task doesn't seem to terminate.

To Reproduce

build.sbt

name := "test"
scalaVersion := "2.13.1"

val circeVersion = "0.12.3"

libraryDependencies ++= Seq(
  "io.circe" %% "circe-core",
  "io.circe" %% "circe-generic",
  "io.circe" %% "circe-parser"
).map(_ % circeVersion)

project/build.properties

sbt.version=1.3.3

Main.scala

package foo

import io.circe._

object Main {

  def main(args:Array[String]):Unit = {
    val x:Json = ???
    println("hello world")
  }
}

Expected behavior When typing the type for x or the import I'd expect completions to be there that shot the circe dependencies. When jumping to definition on Array, String or Json I'd expect to get to the appropriate sources.

Installation:

Additional context It can very much be that it is an issue of my setup that something is wonky. So if nobody can reproduce this I wouldn't be suprised. But any pointers on how I can understand what's going on here would be very appriciated.

olafurpg commented 5 years ago

Thank you for reporting! Do you get compile errors in import io.circe._? Do completions work?

I'm unable to reproduce.

2019-10-30 08 35 13

It's expected that jumping to sources, completions, errors, etc., don't work if the doctor has the following output

GrafBlutwurst commented 5 years ago

It makes absolutely sense that no completions are available if no buildtargets are detected. I just can't figure out why it doesn't find them.

Peek 2019-10-30 09-58

GrafBlutwurst commented 5 years ago

metals.log reads:

INFO  time: initialize in 0.28s
WARN  no build target: /home/grafblutwurst/projects/test/src/main/scala/foo/Main.scala
INFO  running '/home/grafblutwurst/bin/metals-sbt metalsEnable bloopInstall'
INFO  [info] Loading settings for project global-plugins from plugins.sbt,metals.sbt ...
INFO  [info] Loading global plugins from /home/grafblutwurst/.sbt/1.0/plugins
INFO  [info] Loading project definition from /home/grafblutwurst/projects/test/project
INFO  [success] Generated .bloop/test-build.json
INFO  [success] Total time: 1 s, completed Oct 30, 2019 10:27:08 AM
INFO  [info] Loading settings for project test from build.sbt ...
INFO  [info] Set current project to test (in build file:/home/grafblutwurst/projects/test/)
INFO  [info] sbt server started at local:///home/grafblutwurst/.sbt/1.0/server/17b6ee3d216ca4238654/sock
INFO  no build target: using presentation compiler with only scala-library
WARN  no build target: /home/grafblutwurst/projects/test/src/main/scala/foo/Main.scala
gabro commented 5 years ago

The logs seem to indicate that bloopInstall does not generate any target (other than test-build which is the metabuild target).

This is a long shot, but what happens if you turn your build.sbt into

val circeVersion = "0.12.3"

lazy val root = project.in(file("."))
  .settings(
    name := "test",
    scalaVersion := "2.13.1",
    libraryDependencies ++= Seq(
      "io.circe" %% "circe-core",
      "io.circe" %% "circe-generic",
      "io.circe" %% "circe-parser"
    ).map(_ % circeVersion)
  )

and try to re-import the build?

gabro commented 5 years ago

So, I've tried your exact example and I was not able to reproduce.

image

It seems in your case bloopInstall never gets to the phase where it exports the build (it only exports the meta-build), whereas it does in my example (see the highlighted lines in the screenshot)

olafurpg commented 5 years ago

What happens if you remove the custom sbt-script setting for /home/grafblutwurst/bin/metals-sbt and use the embedded launcher?

olafurpg commented 5 years ago

Also, what happens if you're using the latest 0.7.6+172-c469de61-SNAPSHOT? The logs indicate it's running sbt metalsEnable bloopInstall, in the latest SNAPSHOT we no longer call metalsEnable.

GrafBlutwurst commented 5 years ago

What happens if you remove the custom sbt-script setting for /home/grafblutwurst/bin/metals-sbt and use the embedded launcher?

Looks like this is the culprit at least for my small test project. code completion works like a charm now. Contents :

#!/bin/sh
GOOGLE_APPLICATION_CREDENTIALS="token.json" /home/grafblutwurst/.nix-profile/bin/sbt

which just sets an environment variable I need to be set for an sbt plugin that pulls internal dependencies from our GCS.

when starting metals-sbt from within the test-project top level dir it works as intended.

Edit: I can also verify it works for my sizeable multi-module mono-repo build. I just have to strip out all the GCS publishing and dependencies in the build.sbt so i no longer need the custom sbt-script. Though I don't quite understand how this could explain the error behaviour and what I did wrong with the sbt script?

olafurpg commented 4 years ago

Closing since this issue was caused by a custom sbt script.

Though I don't quite understand how this could explain the error behaviour and what I did wrong with the sbt script?

I'm not sure what's going on either. Metals just launches the custom sbt script as a normal binary