Error reporting seriously lags behind

[anthonyvdotbe]

The extension is very slow to realize when errors have been resolved. Doing Java: Clean Workspace clears the false positives, but that's not a solution (and sometimes the cleaning itself hangs and I need to restart VS Code altogether).

[lahodaj]

I think some a little bit more description of what exactly you do and see would be helpful. I don't normally see very slow error updates, but there's probably some information I am missing. One particular thing that comes to mind is whether the errors get updated if you do File/Save All. Thanks!

[anthonyvdotbe]

Here's an example of 2 warnings which persist, even after saving all files. Maybe the logs in #65 can help. They contain warnings like:

WARNING [org.netbeans.modules.java.hints]: document changed, but not canceled?
WARNING [org.netbeans.modules.java.hints]: len = 872
WARNING [org.netbeans.modules.java.hints]: startOffset = 872
WARNING [org.netbeans.modules.java.hints]: endOffset = 872

[anthonyvdotbe]

An example of autocompletion lagging behind:

in file ContentNormalizer.java I've changed the second record component from boolean dirtyBit to List<String> reasonsForRewriting:

However, when attempting to adapt code in other classes, autocompletion still only gives the old component:

[anthonyvdotbe]

Another example where adding a method isn't noticed elsewhere in the code (even after having saved all files and running a Maven build outside VS Code to verify this is indeed a false positive):

[anthonyvdotbe]

Another example. I just opened VS Code, opened the file, deleted a block of code within a method which had no impact on the correctness of the method (verified with a successful mvn clean verify outside VS Code), yet suddenly it gives me the error below:

where links is defined as:

var links = new ArrayList<String>();

Note how the first line correctly says for join(String,List<String>) (for which there are suitable methods), but then during the actual matching it seems to think there's a variable of type Path involved.

After adding a comment in the method, the error has changed to another false positive:

And yet another false positive in the same method still:

As I understand it, it says there's no suitable method open(String,Path) on the first line, only to contradict itself on the second line by saying the method open(String,Path) is not applicable.

[anthonyvdotbe]

This NetBeans issue which I filed at the time was very similar.

For reproducing, making a change like adding a parameter to a method, renaming a method, removing an enum constant (all without using a refactoring) should do the trick. I just tried:

• renaming an enum constant: a usage of the constant elsewhere (in a class in another package) was not detected as an error
• adding a parameter to a method: invocations of the method elsewhere (in a class in another package) were not detected as an error (navigating to the method from the other class, opens the file that contains the method at the beginning of the file)

Doing Java: Clean Workspace does mark the errors due to the changes.