“Insert type annotation” wrongly infers `Any` type

[mberndt123]

Describe the bug

1. Clone this repo: https://github.com/zio/zio-http/
2. check out commit ade9245c (current main as of this writing)
3. open the project using VS Code, import project (bloop or sbt, doesn't matter)
4. Remove the type annotation from val live in object NettyClientDriver, save file
5. use the insert type annotation feature to add the type annotation again

Metals will infer Any instead of the correct type

Expected behavior

The inferred type should be ZLayer[NettyConfig, Nothing, NettyClientDriver]

Operating system

Linux

Editor/Extension

VS Code

Version of Metals

v1.3.1

Extra context or search terms

No response

[mberndt123]

Another issue is:

In the same file, go to line 89. Position the cursor on line 89 between the leading dot and the word customHeaders. Trigger code completion -> works fine, you get all the right methods.

Move the cursor to line 90 between the leading dot and the word webSocketUri. Trigger code completion -> You only get junk.

[tgodzik]

Looking into the project it seems that for both Bloop and sbt BSP it's failing. The weirdest thing is that the presentation compiler seems to be sending us errors all around :thinking:

[mberndt123]

It looks mostly fine in the Metals doctor though 🤷🏻‍♂️ Perhaps it is somehow related to the sbt-projectmatrix plugin?

[tgodzik]

Not sure, either presentation compiler is doing something weird or we are giving it a wrong classpath somehow.

[tgodzik]

Finally, going back to the issue I see a lot of:

[error] zio.http.netty.client.NettyClientDriver.requestWebsocket(file:///home/tgodzik/Documents/metals/tests/unit/target/e2e/community/zio/zio-http/jvm/src/main/scala/zio/http/netty/client/NettyClientDriver.scala:129)
[error]  
[error]  No automatically generated traces are permitted here. Add an implicit parameter
[error]  to pass through a user generated trace or explicitly call `newTrace`
[error]  to force generation of a new trace.
[error]  
[error]  copy/paste:
[error]    (implicit trace: Trace)  <- no existing implicit parameter list
[error]    , trace: Trace           <- existing implicit parameter list
[error]    (newTrace)                       <- I know what I'm doing, generate a new trace anyway
[error]    

and anything that takes in trace as a parameter fails.

[tgodzik]

Yep, looks like if I remove import zio.stacktracer.TracingImplicits.disableAutoTrace everything works :O

[tgodzik]

Looks like it also works with implicit val trace: Tracer.instance.Type with Tracer.Traced = Trace.empty it doesn't like the alias

[tgodzik]

Turns out this is a duplicate of https://github.com/scalameta/metals/issues/4495 which is caused itself by https://github.com/scala/bug/issues/12663

If you are in any other package than zio this will be fine.