-
Notifications
You must be signed in to change notification settings - Fork 256
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
Post-mortem/investigation on #2828 #2945
Comments
|
One thing that happens often is that you have an error in your code, the default path after detecting that error in the resolver breaks an invariant (e.g. something ends up being null or a In these cases the CLI output shows the error before the crash. So, we should either:
The second option would be particularly nice, but how easy is it? |
Testing the IDE with the bug: it doesn’t recover if you remove the code that triggers the bug, even though it should. I'm guessing it fails to update the document state after you trigger the bug so it keeps working with the broken document. Also, even though in the case of this bug the problem occurs both in the CLI and LSP server, I think we can do better to ensure uniformity between server and CLI. I think we should expose a small Dafny agnostic compiler API, something similar to LSP, that exposes enough for both the language server and CLI to operate on, so there is little room for differences between the CLI and language server. This would also mean we remove the duplication in compilation driving logic that exists between LSP server and CLI. A coarse way to view this is that the CLI would run on top of the current LSP server back-end, which would move to DafnyPipeline : ) Also, PR related to this postmortem: #2949 |
#2229 was a bit of that, but it wasn't complete (and we abandoned it because there was no identified use case at the time). |
Action item: #2945 |
Fixes #2945 ### Changes Remove an instance of static state in the compilation pipeline. Such static state is bad because the pipeline may be run multiple times, causing subsequent runs to be affected by previous ones. ### Testing - TODO, but out of scope of this PR: change our integration tests to run all the tests in a single Dafny process. <!-- Is this a user-visible change? Remember to update RELEASE_NOTES.md --> <!-- Is this a bug fix? Remember to include a test in Test/git-issues/ --> <!-- Is this a bug fix for an issue introduced in the latest release? Mention this in the PR details and ensure a patch release is considered --> <!-- Does this PR need tests? Add them to `Test/` or to `Source/*.Test/…` and run them with `dotnet test` --> <!-- Are you moving a large amount of code? Read CONTRIBUTING.md to learn how to do that while maintaining git history --> <small>By submitting this pull request, I confirm that my contribution is made under the terms of the [MIT license](https://github.com/dafny-lang/dafny/blob/master/LICENSE.txt).</small>
#2790 introduced a case (issue ref), where the resolver crashed on an invalid Dafny program. This kind of regression is especially disruptive for those using the VSCode extension, since it crashes the extension completely, and it often isn't obvious to users what part of their code is triggering the bug so it looks like the extension is 100% broken.
Let's look into a few questions:
The text was updated successfully, but these errors were encountered: