.scala-build should not be created when supporting standalone files

[odersky]

Describe the bug

1. Open a buffer, don't edit it
2. Rename the opened file in the terminal
3. Save with ^S

Result:

1. Compilation hangs.
2. After a minute I get a popup about no response from build server.
3. After another couple of minutes: Out of Memory, client shuts down.

Log:

2023.10.13 14:54:13 INFO compiling 37 Scala sources to /Users/odersky/workspace/dotty/compiler/target/scala-3.3.1/classes ...
2023.10.13 14:54:22 INFO compiling 36 Scala sources to /Users/odersky/workspace/dotty/compiler/target/scala-3.3.1/classes ...
2023.10.13 14:54:25 ERROR text document: file:///Users/odersky/workspace/dotty/tests/pos-custom-args/captures/outer-roots.scala
java.nio.file.NoSuchFileException: /Users/odersky/workspace/dotty/tests/pos-custom-args/captures/outer-roots.scala
at sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:106)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
at sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:218)
at java.nio.file.Files.newByteChannel(Files.java:380)
at java.nio.file.Files.newByteChannel(Files.java:432)
at java.nio.file.Files.readAllBytes(Files.java:3288)
at scala.meta.internal.io.PlatformFileIO$.slurp(PlatformFileIO.scala:45)
at scala.meta.internal.io.FileIO$.slurp(FileIO.scala:24)
at scala.meta.internal.metals.InteractiveSemanticdbs.$anonfun$textDocument$2(InteractiveSemanticdbs.scala:90)
at scala.Option.getOrElse(Option.scala:201)
at scala.meta.internal.metals.InteractiveSemanticdbs.$anonfun$textDocument$1(InteractiveSemanticdbs.scala:90)
at java.util.HashMap.compute(HashMap.java:1316)
at java.util.Collections$SynchronizedMap.compute(Collections.java:2770)
at scala.meta.internal.metals.InteractiveSemanticdbs.textDocument(InteractiveSemanticdbs.scala:89)
at scala.meta.internal.metals.InteractiveSemanticdbs.textDocument(InteractiveSemanticdbs.scala:63)
at scala.meta.internal.metals.AggregateSemanticdbs.loop$1(AggregateSemanticdbs.scala:30)
at scala.meta.internal.metals.AggregateSemanticdbs.textDocument(AggregateSemanticdbs.scala:36)
at scala.meta.internal.metals.CodeLensProvider.findLenses(CodeLensProvider.scala:22)
at scala.meta.internal.metals.MetalsLspService.$anonfun$codeLens$2(MetalsLspService.scala:1574)
at scala.meta.internal.metals.TimerProvider.timedThunk(TimerProvider.scala:25)
at scala.meta.internal.metals.MetalsLspService.$anonfun$codeLens$1(MetalsLspService.scala:1572)
at scala.meta.internal.metals.CancelTokens$.$anonfun$apply$2(CancelTokens.scala:26)
at scala.concurrent.Future$.$anonfun$apply$1(Future.scala:687)
at scala.concurrent.impl.Promise$Transformation.run(Promise.scala:467)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.lang.Thread.run(Thread.java:833)

2023.10.13 14:54:27 INFO Deduplicating compilation of project_bd2c96d2de from bsp client 'scala-cli 0.1.19' (since 4h 32m 27.423s)
2023.10.13 14:54:27 INFO compiling project_bd2c96d2de (470 scala sources and 5 java sources)
2023.10.13 14:54:28 INFO time: compiled scala3-compiler in 14s
2023.10.13 14:54:28 INFO compiling scala3-presentation-compiler
2023.10.13 14:54:28 INFO compiling scala3-compiler-test
2023.10.13 14:54:28 INFO compiling 2 Scala sources to /Users/odersky/workspace/dotty/presentation-compiler/target/scala-3.3.1/classes ...
2023.10.13 14:54:28 INFO compiling 7 Scala sources and 1 Java source to /Users/odersky/workspace/dotty/compiler/target/scala-3.3.1/test-classes ...
2023.10.13 14:54:30 INFO time: compiled scala3-presentation-compiler in 0.54s
2023.10.13 14:54:30 INFO compiling scala3-presentation-compiler-test
2023.10.13 14:54:30 INFO time: compiled scala3-presentation-compiler-test in 26ms
2023.10.13 14:54:30 INFO time: compiled scala3-compiler-test in 1.32s
2023.10.13 14:54:30 INFO Processing buildTarget/scalaMainClasses
2023.10.13 14:54:31 INFO compiling scala3-interfaces
2023.10.13 14:54:31 INFO compiling scala3-library
2023.10.13 14:54:31 INFO time: compiled scala3-interfaces in 2ms
2023.10.13 14:54:31 INFO time: compiled scala3-library in 3ms
2023.10.13 14:54:31 INFO compiling tasty-core
2023.10.13 14:54:31 INFO time: compiled tasty-core in 2ms
2023.10.13 14:54:31 INFO compiling scala3-compiler
2023.10.13 14:54:31 INFO time: compiled scala3-compiler in 14ms
2023.10.13 14:54:31 INFO compiling scala3-sbt-bridge
2023.10.13 14:54:31 INFO compiling scala3-presentation-compiler
2023.10.13 14:54:31 INFO compiling scala3-compiler-test
2023.10.13 14:54:31 INFO compiling 1 Java source to /Users/odersky/workspace/dotty/sbt-bridge/src/target/classes ...
2023.10.13 14:54:31 INFO time: compiled scala3-compiler-test in 9ms
2023.10.13 14:54:31 INFO time: compiled scala3-presentation-compiler in 14ms
2023.10.13 14:54:31 INFO compiling scala3-presentation-compiler-test
2023.10.13 14:54:31 INFO time: compiled scala3-presentation-compiler-test in 7ms
2023.10.13 14:54:32 INFO time: compiled scala3-sbt-bridge in 1.06s
2023.10.13 14:54:33 INFO compiling scala3-library-bootstrapped
2023.10.13 14:54:33 INFO compiling 2 Scala sources to /Users/odersky/workspace/dotty/out/bootstrap/scala3-library-bootstrapped/scala-3.4.0-RC1-bin-SNAPSHOT-nonbootstrapped/classes ...
2023.10.13 14:54:35 INFO Processing buildTarget/scalaTestClasses
2023.10.13 14:54:35 INFO compiling scala3-library
2023.10.13 14:54:35 INFO time: compiled scala3-library in 1ms
2023.10.13 14:54:35 INFO compiling scala3-interfaces
2023.10.13 14:54:35 INFO compiling tasty-core
2023.10.13 14:54:35 INFO time: compiled scala3-interfaces in 1ms
2023.10.13 14:54:35 INFO time: compiled tasty-core in 1ms
2023.10.13 14:54:35 INFO compiling scala3-compiler
2023.10.13 14:54:35 INFO time: compiled scala3-compiler in 15ms
2023.10.13 14:54:35 INFO compiling scala3-presentation-compiler
2023.10.13 14:54:35 INFO compiling scala3-compiler-test
2023.10.13 14:54:35 INFO time: compiled scala3-presentation-compiler in 5ms
2023.10.13 14:54:35 INFO time: compiled scala3-compiler-test in 6ms
2023.10.13 14:54:35 INFO compiling scala3-presentation-compiler-test
2023.10.13 14:54:35 INFO time: compiled scala3-presentation-compiler-test in 3ms
2023.10.13 14:54:35 INFO Processing buildTarget/jvmRunEnvironment
2023.10.13 14:54:35 INFO compiling scala3-interfaces
2023.10.13 14:54:35 INFO compiling scala3-library
2023.10.13 14:54:35 INFO time: compiled scala3-interfaces in 3ms
2023.10.13 14:54:35 INFO time: compiled scala3-library in 4ms
2023.10.13 14:54:35 INFO compiling tasty-core
2023.10.13 14:54:35 INFO time: compiled tasty-core in 1ms
2023.10.13 14:54:35 INFO compiling scala3-compiler
2023.10.13 14:54:35 INFO time: compiled scala3-compiler in 13ms
2023.10.13 14:54:35 INFO compiling scala3-sbt-bridge
2023.10.13 14:54:35 INFO compiling scala3-compiler-test
2023.10.13 14:54:35 INFO compiling scala3-presentation-compiler
2023.10.13 14:54:35 INFO time: compiled scala3-sbt-bridge in 8ms
2023.10.13 14:54:35 INFO time: compiled scala3-presentation-compiler in 8ms
2023.10.13 14:54:35 INFO time: compiled scala3-compiler-test in 13ms
2023.10.13 14:54:35 INFO compiling scala3-presentation-compiler-test
2023.10.13 14:54:35 INFO time: compiled scala3-presentation-compiler-test in 3ms
2023.10.13 14:54:35 INFO compiling scala3-library-bootstrapped
2023.10.13 14:54:41 WARN sbt does not support buildTarget/inverseSources, unable to fetch targets owning source.
2023.10.13 14:54:41 WARN no build target for: /Users/odersky/workspace/dotty/tests/neg/i18588.scala
2023.10.13 14:54:41 WARN sbt does not support buildTarget/inverseSources, unable to fetch targets owning source.
2023.10.13 14:54:41 WARN no build target for: /Users/odersky/workspace/dotty/tests/neg/i18588.scala
2023.10.13 14:54:48 WARN sbt does not support buildTarget/inverseSources, unable to fetch targets owning source.
2023.10.13 14:54:48 WARN no build target for: /Users/odersky/workspace/dotty/tests/neg/i18588.scala
2023.10.13 14:55:05 INFO Processing workspace/buildTargets
2023.10.13 14:55:13 WARN sbt does not support buildTarget/inverseSources, unable to fetch targets owning source.
2023.10.13 14:55:13 WARN no build target for: /Users/odersky/workspace/dotty/tests/neg/i18588.scala
2023.10.13 14:56:06 INFO Processing workspace/buildTargets
2023.10.13 14:56:08 INFO time: code lens generation in 1.36s
2023.10.13 14:56:16 INFO time: code lens generation in 1.24s
2023.10.13 14:56:30 WARN sbt does not support buildTarget/inverseSources, unable to fetch targets owning source.
2023.10.13 14:56:32 WARN no build target for: /Users/odersky/workspace/dotty/tests/neg/i18588.scala
2023.10.13 14:56:41 INFO time: code lens generation in 24s
2023.10.13 14:56:53 INFO BSP server: [warn] ./backend/jvm/ClassNode1.java:1:1: Using directives detected in multiple files. It is recommended to keep them centralized in the /Users/odersky/workspace/dotty/tests/pos-with-compiler-cc/project.scala file.
2023.10.13 14:56:53 INFO BSP server: [warn] ./backend/jvm/LabelNode1.java:1:1: Using directives detected in multiple files. It is recommended to keep them centralized in the /Users/odersky/workspace/dotty/tests/pos-with-compiler-cc/project.scala file.
2023.10.13 14:56:53 INFO BSP server: [warn] ./backend/jvm/MethodNode1.java:1:1: Using directives detected in multiple files. It is recommended to keep them centralized in the /Users/odersky/workspace/dotty/tests/pos-with-compiler-cc/project.scala file.
2023.10.13 14:56:53 INFO BSP server: [warn] ./dotc/profile/ExtendedThreadMxBean.java:1:1: Using directives detected in multiple files. It is recommended to keep them centralized in the /Users/odersky/workspace/dotty/tests/pos-with-compiler-cc/project.scala file.
2023.10.13 14:56:53 INFO BSP server: [warn] package dotty.tools.dotc.profile;
2023.10.13 14:56:53 INFO BSP server: [warn] ^
2023.10.13 14:56:53 INFO BSP server: [warn] ./dotc/profile/ExternalToolHook.java:1:1: Using directives detected in multiple files. It is recommended to keep them centralized in the /Users/odersky/workspace/dotty/tests/pos-with-compiler-cc/project.scala file.
2023.10.13 14:56:53 INFO BSP server: [warn] package dotty.tools.dotc.profile;
2023.10.13 14:56:53 INFO BSP server: [warn] ^
2023.10.13 14:56:59 INFO time: code lens generation in 35s
2023.10.13 14:56:59 INFO time: code lens generation in 37s
2023.10.13 14:57:06 INFO Processing workspace/buildTargets
2023.10.13 14:58:32 INFO Processing workspace/buildTargets
2023.10.13 14:59:13 INFO Processing workspace/buildTargets
[Error - 15:01:20] Request textDocument/codeAction failed.
Message: Internal error.
Code: -32603
java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
at org.eclipse.lsp4j.jsonrpc.services.GenericEndpoint.lambda$null$0(GenericEndpoint.java:67)
at org.eclipse.lsp4j.jsonrpc.services.GenericEndpoint.request(GenericEndpoint.java:120)
at org.eclipse.lsp4j.jsonrpc.RemoteEndpoint.handleRequest(RemoteEndpoint.java:261)
at org.eclipse.lsp4j.jsonrpc.RemoteEndpoint.consume(RemoteEndpoint.java:190)
at org.eclipse.lsp4j.jsonrpc.json.StreamMessageProducer.handleMessage(StreamMessageProducer.java:194)
at org.eclipse.lsp4j.jsonrpc.json.StreamMessageProducer.listen(StreamMessageProducer.java:94)
at org.eclipse.lsp4j.jsonrpc.json.ConcurrentMessageProcessor.run(ConcurrentMessageProcessor.java:113)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: java.lang.reflect.InvocationTargetException
at jdk.internal.reflect.GeneratedMethodAccessor11.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at org.eclipse.lsp4j.jsonrpc.services.GenericEndpoint.lambda$null$0(GenericEndpoint.java:65)
... 11 more
Caused by: java.lang.OutOfMemoryError: Java heap space

2023.10.13 15:01:21 INFO time: code lens generation in 1.23s

Expected behavior

Regular compilation

Operating system

macOS

Editor/Extension

VS Code

Version of Metals

1.0.1

Extra context or search terms

Build server is SBT

[tgodzik]

Doesn't seem like I am able to reproduce. I suspect that the issue might be when we try and generate too many in memory semanticdb files, but this should happen over some time not right away.

What I find curious is that you get logs from scala-cli and sbt at the same tiime, which I can't seem to figure out how that happened.

2023.10.13 14:54:27 INFO Deduplicating compilation of project_bd2c96d2de from bsp client 'scala-cli 0.1.19' (since 4h 32m 27.423s)
2023.10.13 14:54:27 INFO compiling project_bd2c96d2de (470 scala sources and 5 java sources)

Looks like Scala CLI was set up for a large bulk of files and is trying to compile with issues, but we don't start two different build servers at any point.

[tgodzik]

Open a buffer, don't edit it
Was it a normal project file or a test one (used for testing the compiler). Ideally if you have an exact file that is causing the issue I would be super thankful for that info.

Save with ^S
If you rename a file it will be recognized as removed. The exception happens because we are trying to read from the file system it while it no longer exists, we can remedy that for sure. It's not possible to just save it with ctrl + s, you need to edit it and save only then.

[odersky]

It was the dotty compiler. I had the same behavior repeatedly over the last weeks. Not sure it always had to do with file renames though. Also, I don't ussually run scala-cli at all, so I am surprised that this happens. I do often run an explicit sbt compile from a terminal over the same files, sometimes continuously. Can that explain the log?

Also, btw, I was unable to easily find out what the target directory of the metals build is. Is that in the logs somewhere? That's basically why I run a separate sbt build since sometimes I am not sure whether metals compiles into the right directory.

[odersky]

I guess my point is that Metals should handle this scenario gracefully. If files are missing, just ignore them.

[tgodzik]

It was the dotty compiler. I had the same behavior repeatedly over the last weeks. Not sure it always had to do with file renames though. Also, I don't ussually run scala-cli at all, so I am surprised that this happens. I do often run an explicit sbt compile from a terminal over the same files, sometimes continuously. Can that explain the log?

It doesn't really explain the log. Do you have .bsp/scala-cli.json or .bsp/scala.json created somewhere? Maybe it's picking it up? But this shouldn't really happen that we get two build server. Especially in the Scala compiler. We only start scala-cli if there is no other build tool or a user explicitely wants that for their script.

Maybe there are two Metals processes running at the same time and both logging?

Also, it would probably great to try and get heapdump when the memory usage goes up. Also, what is the xmx you are using? I usally set at least 2gb for larger codebases while the default is one.

Anyway, I will try and create some PR that could help reduce the memory used.

Also, btw, I was unable to easily find out what the target directory of the metals build is. Is that in the logs somewhere? That's basically why I run a separate sbt build since sometimes I am not sure whether metals compiles into the right directory.

If you are running sbt BSP it should be exactly the same target directory as normal sbt.

[tgodzik]

Och, maybe we somehow picked up scala-cli from /Users/odersky/workspace/dotty/tests/pos-with-compiler-cc/project.scala? We assume it's scala-cli in that case, but that is not at the root, so sbt should be picked up first 🤔

[tgodzik]

I guess my point is that Metals should handle this scenario gracefully. If files are missing, just ignore them.

Already fixing that here #5749 but I doubt it would cause anything aside from that exception

[tgodzik]

Ok, so I managed to reproduce having both sbt and scala-cli:

1. create .sc file in one of the tests directories (tests/pos)
2. agree to import it as a Scala CLI script
3. scala CLI will try to compile everything within that file which will not work and the results are unexpected

I would start with removing .scala-build directory if it exists somewhere and maybe removing automatic import of script files (reset notifications command, also available in the doctor and metals view).

[odersky]

I actually had quite a lot of these. Reachable from the dotty workspace:

~/workspace/dotty> lsr .scala-build
./community-build/community-projects/stdLib213/src/library/scala/.scala-build
./out/testPickling/pos/.scala-build
./out/testPickling/new/.scala-build
./tests/pos-with-compiler-cc/.scala-build
./tests/pos/i16351/.scala-build
./tests/pos/.scala-build
./tests/new/.scala-build
./sandbox/.scala-build

I have no idea what they do?

[tgodzik]

Those are created by scala-cli when it compiled any specific code within that particular directory. It contains the compiled classfiles and some metadata for Bloop. If you have auto import of scripts turned on it will start a new scala-cli build server each time you open .sc file, which in case of the compiler looks to cause some problems. Normally we ask each time you open .sc file, so this should not happen.

[odersky]

How do I turn off auto import of scripts? I searched a bit but could not find anything.

[tgodzik]

You probably chose it at some point, you can reset notifications via a command, in metals view or the doctor

[odersky]

Ok, I found the command and executed it (did not find anything in the Doctor view). But what has "reset notifications" have to do with auto-running scripts?

[tgodzik]

There is an option to always automatically import scala scripts, which will cause every .sc to be imported as scala cli. When resetting notifications next time you will be asked again if you want to import them automatically. If you ignore the promt or decline the scripts shouldn't be imported

[tgodzik]

It's really just my guess, but I cannot explain the behaviour you are facing otherwise. I will try to figure out how to reduce the possible impact next week

[github-actions]

This issue was closed because no new information was added for the last 30 days. If you have any relevant information, feel free to add it and reopen the issue.

[tgodzik]

Let's keep it open since we actually had to revert the change for the time being.

[tgodzik]

I think I know the reason for OOMs that people had. We would tokenize each file that had a diagnostic, so if there are too many, we might end up having all the tokens in memory concurrently.

This was now fixed and together with the currently reverted fix we should be much safer.

[tgodzik]

This should no longer be an issue, we are also working on better standalone scala file support but that is not really related, so I will close it.