Edit and continue diagnostic source

[tmat]

Directly hook EnC document analysis into pull diagnostic handler instead of going through legacy incremental analyzer system.

Since pull diagnostics ae implemented in the LSP layer we need to expose the EnC session state to this layer via a new MEF component (IEditAndContinueSessionTracker). Previously the state was directly on EditAndContinueLanguageService, which is in Editor Features layer. We also need the IActiveStatementSpanLocator, which reports the current locations of active statements to the EnC analysis, to be available in LSP layer.

There are three kinds of EnC diagnostics: 1) rude edits that are determined from document semantic analysis and 2) emit errors reported by the compiler when we try to emit deltas and 3) issues related to the current state of the debuggee.

When pull request for semantic diagnostics is processed and the EnC session is active we analyze the document for rude edits and report them. We don't attempt to emit the deltas at that point or check the debuggee status. Emitting deltas is expensive and the diagnostics that are only reported in emit phase are rare. The debuggee status may change at any point during the edit session and it might be confusing to report these diagnostics until the user is actually applying the change. Instead, we store emit and debuggee state relate diagnostics to the EnC session state and when we pull we simply include the stored diagnostics. We invalidate and refresh the pull diagnostics whenever the EnC session state changes (start session, enter/exit break state, end session).

[tmat]

@davidwengier @dibarbet @CyrusNajmabadi ptal

[tmat]

@dibarbet @CyrusNajmabadi Updated per our discussion.

[tmat]

I did not need to add any special handling to clear diagnostics. Added a test to cover it. Seems to work.

[CyrusNajmabadi]

@tmat @dibarbet what is "DocumentNonLocalDiagnosticIdentifier"?

[dibarbet]

oh - we already create buckets in VSCode - I completely forgot about this. Its for diagnostics reported on the document during compilation end

roslyn/src/Features/LanguageServer/Protocol/Handler/Diagnostics/Public/PublicDocumentPullDiagnosticsHandler_IOnInitialized.cs

Line 43 in b67df4c

Identifier = DocumentNonLocalDiagnosticIdentifier.ToString()

[CyrusNajmabadi]

Signing off on teh pull-diags changes. Just nits and small requests for explanations or docs. Glad it was so simple :)

[dibarbet]

oh - we already create buckets in VSCode - I completely forgot about this. Its for diagnostics reported on the document during compilation end

roslyn/src/Features/LanguageServer/Protocol/Handler/Diagnostics/Public/PublicDocumentPullDiagnosticsHandler_IOnInitialized.cs

Line 43 in b67df4c

Identifier = DocumentNonLocalDiagnosticIdentifier.ToString()

[dibarbet]

currently these won't ever show in VSCode (because we only register the kind for VS diagnostics).

For VSCode, buckets are named 'identifiers', and they can only be registered dynamically like we do here -

roslyn/src/Features/LanguageServer/Protocol/Handler/Diagnostics/Public/PublicDocumentPullDiagnosticsHandler_IOnInitialized.cs

Line 43 in b67df4c

Identifier = DocumentNonLocalDiagnosticIdentifier.ToString()

And unfortunately it has a different field name. If you add add the identifier, in the Public doc pull handler, you'll also need to add the code to check for the identifier and create a source for it.