Syntax highlight, hover and code-completion suddenly stop working #5272
Labels
Projects
Milestone
Comments
|
Is it in a specific file? Or is it all of them? Does it happen during a longer session of coding? Any chance you could run the command |
|
Once it happens, it affects all files. And whenever I change to a different file, I see that It happened after some time of coding. I was moving some functions around, there were compiling errors as expected while the code was being written... everything normal. Then suddenly it broke. Oh, it was a test file (ScalaTest); not sure if there's anything special with test files...
|
|
It happened again (coincidence or not, again in a test file). |
|
Ideally, we could check the classpath, but it shouldn't really change to miss The only thing you could do currently, is check the doctor, click on the module that is having issues and see if there is anything on the classpath that might cause issues. All the info about that module you can give us would probably be useful. On out side, we should try to generate a proper report that tries to at least analyze if all the needed files are in place. |
|
I've been using the snapshot versions released after opening this ticket, and it didn't happen again so far. I'll observe for some more time... |
|
Well, it's been really stable lately. I did a lot of stuff - refactorings, solved merge conflicts - that used to cause the crash and nothing happened 🎉 I'm not sure, but I think it got stable when I've got the snapshot containing this: #5278 Anyway, I'm happily closing this 😃 |
|
Let us know if you find any more issues! We should be able to add even more reporting to more easily rule out some problems |
|
Unfortunately, it's back =(
Current environment:
In the logs, I've found: In the report Stack trace: Short summary After the error, code completion, syntax highlight, hover... nothing works anymore. All files are affected, not only those which were open. Closing and reopening the files doesn't work. "Clean and restart build server" doesn't work. The only way to make things go back to normal is closing and reopening the VSCode workspace of the project. |
|
Oh, another detail: sometimes I spot a strange message in the logs: The problematic project is 2.13.12, but I have 3.3.1 as a global scala installation. Looks suspect... |
tgodzik
added
bug
|
That message is sometime false positive, so no need to worry about it. I am trying to add more data to reports in #5272 Let's see if that helps. |
|
The additional reporting is now added to snapshots. If you are using them then you should see the additional debug data, otherwise we will do a release this month. |
|
After a long time, here I am again... Current status:
This time, I'm seeing different error messages, besides the ones already known. As usual, the only way to go back to normal is Closing and Reopening the Workspace. |
|
I'm having the same issue, my setup: |
|
I has a suspicion that it's reflect-portable that is causing that, but I can't seem to reproduce, it might be another libary on the classpath or the reflect library is broken locally? Though the latter is rather unlikely. |
|
@altrack would you be able to add the list of dependencies that you add in your project? Can be just setting from sbt. Also, does this happen all the time in that project? |
|
This happens consistently to me on my project every day, so I'd be very happy to provide any information that can help it be fixed.
Linked Here is Let me know if there's anything else that I can include to be helpful! |
does the problem still occur if you upgrade to 2.13.14? |
|
I've been wondering if maybe we might Scala reflect twice on the classpath and have some suspicions. I should try to reproduce with an older version. |
tgodzik
added a commit
to tgodzik/metals
that referenced
this issue
May 24, 2024
I think this was done by mistake in scalameta#2417 but very rarely caused any issues. Previous to that PR we would only get Scala jars from ScalaBuildTarget.getJars method and after we would use the full classpath. This never happened in the latest Scala version as we would just start mtags via new ScalaPresentationCompiler and it would happen randomly for some other versions. Now, since we always use mtags artifacts they always contain the needed Scala jars (unless there would be a custom platform) so there is no need to add anything more. This might have caused scalameta#5272
tgodzik
added a commit
to tgodzik/metals
that referenced
this issue
May 24, 2024
I think this was done by mistake in scalameta#2417 but very rarely caused any issues. Previous to that PR we would only get Scala jars from ScalaBuildTarget.getJars method and after we would use the full classpath. This never happened in the latest Scala version as we would just start mtags via new ScalaPresentationCompiler and it would happen randomly for some other versions. Now, since we always use mtags artifacts they always contain the needed Scala jars (unless there would be a custom platform) so there is no need to add anything more. This might have caused scalameta#5272
tgodzik
added a commit
to tgodzik/metals
that referenced
this issue
May 24, 2024
I think this was done by mistake in scalameta#2417 but very rarely caused any issues. Previous to that PR we would only get Scala jars from ScalaBuildTarget.getJars method and after we would use the full classpath. This never happened in the latest Scala version as we would just start mtags via new ScalaPresentationCompiler and it would happen randomly for some other versions. Now, since we always use mtags artifacts they always contain the needed Scala jars (unless there would be a custom platform) so there is no need to add anything more. This might have caused scalameta#5272
tgodzik
added a commit
to tgodzik/metals
that referenced
this issue
May 24, 2024
I think this was done by mistake in scalameta#2417 but very rarely caused any issues. Previous to that PR we would only get Scala jars from ScalaBuildTarget.getJars method and after we would use the full classpath. This never happened in the latest Scala version as we would just start mtags via new ScalaPresentationCompiler and it would happen randomly for some other versions. Now, since we always use mtags artifacts they always contain the needed Scala jars (unless there would be a custom platform) so there is no need to add anything more. This might have caused scalameta#5272
tgodzik
added a commit
that referenced
this issue
May 27, 2024
I think this was done by mistake in #2417 but very rarely caused any issues. Previous to that PR we would only get Scala jars from ScalaBuildTarget.getJars method and after we would use the full classpath. This never happened in the latest Scala version as we would just start mtags via new ScalaPresentationCompiler and it would happen randomly for some other versions. Now, since we always use mtags artifacts they always contain the needed Scala jars (unless there would be a custom platform) so there is no need to add anything more. This might have caused #5272
|
I have merged a potential fix for an error that could explain the issue, it's available under newest snapshot. |
|
Ok, that hasn't fixed anything unfortunately and I seem to be able to reproduce now fairly regularily. The weirdest thing is that it fails at https://github.com/scala/scala/blame/0d8f4caa713977983c53828f87d50fbadc7dd7ab/src/reflect/scala/reflect/internal/Definitions.scala#L1477 The method flag is not set actually. @SethTisue any idea how that could even be possible? |
tgodzik
added
investigation needed
and removed
needs more information
|
Could it be some combination of classfiles compiled with -Xtarget and -release flag, later the presentation compiler using the same? Or maybe it's the release flag with the presentation compiler that causes this 🤔 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
Sometimes while coding (while there's still compiling errors to solve), syntax highlight, hover (type at point) and code-completion suddenly stop working.
Looking at the
OUTPUT (Metals)tab, I see the following message appearing every time I change to a file:Meanwhile, in
metals.log, I've found this:I've seen this problem before while reporting a different issue.
Expected behavior
No response
Operating system
macOS
Editor/Extension
VS Code
Version of Metals
v0.11.12+73-f470c9c8-SNAPSHOT
Extra context or search terms
VSCode 1.78.2
Scala 2.13.10
sbt 1.8.3
Build server is sbt
The text was updated successfully, but these errors were encountered: