SourceKit-LSP not reporting diagnostics

[adam-fowler]

If I compile a SwiftPM project and then type code referencing a symbol that doesn't exist, or the wrong parameter to a function it will not report a diagnostic for these. eg

let s = String("test", doesNotExist: true)

should produce a diagnostic extra argument 'doesNotExist' in call. This does not happen.

This was working in Swift 5.8, it is no longer working in 5.9

[ahoppen]

Tracked in Apple’s issue tracker as rdar://117732149

[ahoppen]

I have been able to reproduce this once using Swift 5.9 but not using Swift 5.10 or a recent main snapshot. Also, when I tried reproducing it using Swift 5.9 again, I couldn’t.

Does this reproduce consistently for you? If so, does it also reproduce using a recent main development snapshot? If it does reproduce on main, could you gather logs using the following command after hitting the issue and attach the logs?

log show --last 10m --predicate 'subsystem CONTAINS "sourcekit-lsp"' > /tmp/log.txt

[adam-fowler]

It does appear to be fixed on main. It would be helpful if we could find out why it is an issue in 5.9. This significantly damages the quality of support vscode can supply. Swift 5.10 is not going to be released for a significant amount of time.

[ahoppen]

Does it reproduce reliably for you in 5.9?

[adam-fowler]

Yes

[ahoppen]

That’s really weird. I just tried reproducing it for quite a while now and couldn’t.

Could you set SOURCEKIT_LOGGING to 99 (I always forget what the real maximum log level is) in swift.swiftEnvironmentVariables, reproduce the issue attach the log output from the SourceKit Language Server output? I hope that I can tell what’s going wrong from there.

[ahoppen]

Ah, I think I have found a hypothesis (hit this on main just now):

In 5.9 we switched to the pull model for diagnostics (#751) instead of always pushing diagnostics to the client. But it appears that whenever a diagnostic request fails (in the case I hit, sourcekitd crashed), VS Code won’t request diagnostics for that document again, which is surprising to me. I would have expected diagnostics to be requested again, maybe after a delay.

It would be interesting to see if that is the same issue that you are hitting, @adam-fowler. If it is, that should be obvious from the log.

The “fix” would be to never return an error from the textDocument/diagnostic request. Instead, if we fail to get diagnostics, we should just an empty diagnostics array.

[ahoppen]

#1022 fixes the suspicion I have above, so let’s close this.