Skip to content
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

Merged

Conversation

keyboardDrummer
Copy link
Member

@keyboardDrummer keyboardDrummer commented May 4, 2022

Changes

  • Adds a push based API that sends verification task status information to the LSP client.
  • Solve a bug in SlowVerifier which caused HoverReturnsBeforeVerificationIsComplete and DefinitionReturnsBeforeVerificationIsComplete to sometimes fail.

Testing

New API is unit tested

@keyboardDrummer keyboardDrummer changed the base branch from master to fixFlickering May 6, 2022 08:20
@keyboardDrummer keyboardDrummer marked this pull request as ready for review May 6, 2022 08:44
@keyboardDrummer keyboardDrummer changed the base branch from fixFlickering to master May 6, 2022 08:44
@MikaelMayer MikaelMayer marked this pull request as draft May 6, 2022 14:56
@keyboardDrummer keyboardDrummer enabled auto-merge (squash) May 26, 2022 22:55
Copy link
Member

@MikaelMayer MikaelMayer left a 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);
}
Copy link
Member

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
Copy link
Member

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.

Copy link
Member Author

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 => {
Copy link
Member

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
}
Copy link
Member

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();
Copy link
Member

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)) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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";
Copy link
Member

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.

Copy link
Member Author

@keyboardDrummer keyboardDrummer May 27, 2022

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)), @"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice overload !

MikaelMayer
MikaelMayer previously approved these changes May 27, 2022
Copy link
Member

@MikaelMayer MikaelMayer left a 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 !

@keyboardDrummer keyboardDrummer merged commit c8598c8 into dafny-lang:master May 27, 2022
@keyboardDrummer keyboardDrummer deleted the verificationOverviewAPI branch May 27, 2022 22:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants