Doesn't revalidate project files after classpath changes if autobuild is off. #3155
Comments
|
I was able to reproduce this once, but I'm not able to do so anymore. Are there a set of consistent steps to do this, or did I just run into some kind of weird race condition. I did notice that the library was accessible and just the diagnostics were stale. If I turn off the autobuild, open one (invisible) project, add another (invisible project), and quickly open a file that makes use of some referenced library (under |
|
I can reproduce it consistently, but it is a little tricky. My directory structure looks like:
Steps to reproduce:
Here's the LSP logs starting from step 5. I left out all the |
|
I'm definitely able to reproduce so thank-you for the detailed example. At first I thought maybe I think the issue has more to do with the fact that the autobuild (being disabled) is respected by the code paths from CC'ing @testforstephen for awareness. |
Ahh, so that's why vscode sends "java/validateDocument" when the editor receives focus! Very helpful, thank you. I guess this begs the question of whether we want to revalidate open files when the classpath changes. Since the classpath rarely changes, it wouldn't have too much performance cost in the grand scheme, and when it does change, diagnostics across many files are likely to be stale. Then again, these stale diagnostics aren't a severe problem because focusing those files will refresh them.
This might change your mind: you can reproduce this bug by modifying directory structure: pom.xml: <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>foo.bar</groupId>
<artifactId>salut</artifactId>
<version>0.0.1-SNAPSHOT</version>
<build>
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.5.1</version>
<configuration>
<source>1.7</source>
<target>1.7</target>
</configuration>
</plugin>
</plugins>
</build>
<dependencies>
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-lang3</artifactId>
<version>3.5</version>
</dependency>
</dependencies>
</project>Foo.java: package java;
import org.apache.commons.lang3.StringUtils;
/**
* This is foo
*/
public class Foo {
public static void main(String[] args) {
System.out.print( StringUtils.capitalize("Hello world! from "+Foo.class));
}
public void linkedFromFoo2() {
}
}Steps:
|
|
If it helps: When autobuilding is enabled and the classpath changes, the WorkspaceDiagnosticsHandler gets a resource change event for all files inside the project. These IResourceDeltas have marker deltas, so the WorkspaceDiagnosticsHandler revalidates the file here: When autobuilding is disabled, the WorkspaceDiagnosticsHandler still gets a resource change event for each file inside the project, but these IResourceDelta have no marker deltas so the files are never revalidated. It looks like the Eclipse Core library is responsible for rebuilding the project when the classpath changes. Rebuilding the project updates the diagnostic markers, which WorkspaceDiagnosticsHandler happens to see and send to the client. |
Yeah that's convincing. My first reaction was to avoid validating on classpath change when the issue seems to be only about project import/folder addition. However, if the issue exists on a classpath change as well, then it makes sense. |
If you add a project to the workspace that references a new library (e.g. JavaFX), it will first validate your project files without that dependency and then add the dependency to the classpath. If you have autobuild (
java.autobuild.enabled) turned on, it will rebuild your project with the new classpath. The result is a flash of errors when the project is first imported:dependency_error_flash.mp4
However, if you have autobuild turned off, it will never revalidate your project with the new classpath and the errors will remain on screen. Of course, once you start typing, the files are revalidated anyways and the errors disappear.
Maybe the server should revalidate all open project files if autobuild is turned off?
The text was updated successfully, but these errors were encountered: