-
Notifications
You must be signed in to change notification settings - Fork 260
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Publish verification status notifications #2094
Publish verification status notifications #2094
Conversation
…-lang#2004)" (dafny-lang#2092)" This reverts commit 954d495.
8d6c036
to
44b1faa
Compare
…agnostics are finished
05e6b99
to
23fb624
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm very happy with the solution you did to ensure we don't unnecessarily trigger translation if verification is not requested.
I have only a straightforward refactoring request and a discussion on the name of the push API to harmonize it with the others.
|
||
public static Task<U> Select<T, U>(this Task<T> task, Func<T, U> f) { | ||
return task.ContinueWith(completedTask => f(completedTask.Result), TaskContinuationOptions.OnlyOnRanToCompletion); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice helper !
} | ||
} | ||
|
||
// TODO for backwards compatibility. No longer needed when the IDE switches to the textDocument/verificationStatus API |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you saying the IDE would update the status bar based on the new API? I think that should work.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Jep
var diagnostics = errorReporter.GetDiagnostics(document.Uri).OrderBy(d => d.Range.Start).ToList(); | ||
concurrentDictionary.AddOrUpdate(id, diagnostics, (_, _) => diagnostics); | ||
var result = implementationTasks.Select(implementationTask => implementationTask.ObservableStatus.Select( | ||
async boogieStatus => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now is a good time to refactor the body of this closure so a named separated async method, else I find it hard to read.
Running = 2, // Currently running | ||
Error = 4, // Finished and had errors | ||
Correct = 5, // Finished and was correct | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good job for the comments and re-numbering !
|
||
var printer = new ModelCapturingOutputPrinter(logger, progressReporter, options.GutterStatus); | ||
cancellationToken.ThrowIfCancellationRequested(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great! This is what guarantees that typing multiple times will not result in verification to be started all the times.
@@ -52,13 +52,13 @@ private class SignatureHelpProcessor { | |||
} | |||
|
|||
public SignatureHelp? Process() { | |||
if (!symbolGuesser.TryGetSymbolBefore(document, GetOpenParenthesePosition(), cancellationToken, out var symbol)) { | |||
if (!symbolGuesser.TryGetSymbolBefore(document, GetOpenParenthesesPosition(), cancellationToken, out var symbol)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if (!symbolGuesser.TryGetSymbolBefore(document, GetOpenParenthesesPosition(), cancellationToken, out var symbol)) { | |
if (!symbolGuesser.TryGetSymbolBefore(document, GetOpenParenthesisPosition(), cancellationToken, out var symbol)) { |
Singular?
return null; | ||
} | ||
return CreateSignatureHelp(symbol); | ||
} | ||
|
||
private Position GetOpenParenthesePosition() { | ||
private Position GetOpenParenthesesPosition() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
private Position GetOpenParenthesesPosition() { | |
private Position GetOpenParenthesisPosition() { |
Idem?
@@ -4,5 +4,6 @@ public static class DafnyRequestNames { | |||
public const string CompilationStatus = "dafny/compilation/status"; | |||
public const string GhostDiagnostics = "dafny/ghost/diagnostics"; | |||
public const string VerificationStatusGutter = "dafny/verification/status/gutter"; | |||
public const string VerificationStatusNotification = "dafny/textDocument/verificationStatus"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One more time on that, so far I've seen the APIs above look more like
"dafny/<pipeline context>/<result>
except for counter-examples where /verification
is missing
I think it would make sense to choose a similar structure for new push APIs. Since there is also a precedent (dafny/compilation/status
), I think it would make sense to have an API like one of the following:
dafny/verification/status/textDocument
dafny/verification/status/tree
dafny/verification/status/names
dafny/verification/status/declarations
dafny/verification/status/browsable
or maybe reverse the last two:
dafny/verification/textDocument/status
dafny/verification/tree/status
dafny/verification/names/status
dafny/verification/declarations/status
dafny/verification/browsable/status
Let me know what you think.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've seen the APIs above look more like ...
To me it looks like the current code took the name of the variable and then replaced camel-casing with /
separation to form the operation name, which I find strange. We can use camel-casing in the operation name without introducing additional /
's, just like LSP does.
LSP categorises the operations based on what they operate on in the IDE, the main ones are textDocument/<name>
, workspace/<name
and window/<name>
. I think we should stick to that.
I think that APIs which don't relate to verification should already be in LSP, so dafny
and verification
always occur together and we might as well only mention dafny
.
Given the above I would pick these names
public const string Counterexample = "textDocument/dafny/counterexample";
public const string GhostDiagnostics = "textDocument/dafny/ghostness";
public const string VerificationStatusGutter = "textDocument/dafny/lineStatus";
public const string VerificationStatusNotification = "textDocument/dafny/symbolStatus";
// Becomes obsolete by 'textDocument/dafny/symbolStatus'
public const string CompilationStatus = "dafny/compilation/status";
But that would be out of scope for this PR. How about we ignore the operation names until we merge a PR that introduces a naming scheme for them?
var y := x." | ||
} | ||
); | ||
ApplyChange(ref documentItem, new Range((4, 21), (4, 21)), @" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice overload !
…dafny into verificationOverviewAPI
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fantastic work, can't wait to see the VSCode extension to deal with it !
Changes
HoverReturnsBeforeVerificationIsComplete
andDefinitionReturnsBeforeVerificationIsComplete
to sometimes fail.Testing
New API is unit tested