Properly expose project load errors in VS Code, improve error handling in WASM/JS #2476
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR improves how project loading and QIR generation errors are handled in the VS Code extension. Additionally, there are internal changes normalizing how we raise and handle errors coming from the WASM component.
User facing changes
Previously, whenever project load failed while performing some task, we would show a modal dialog. Additionally we would populate the Problems view with sticky "QDK command error:" errors.
Removed excessive modal dialogs on project load errors for tasks that don't need them:
These user-invoked commands continue to show the modal dialog when project load fails:
Removed the sticky "QDK command error:" errors for project load, since the language service already reports those errors. We don't want to litter the Problems view with duplicates.
Kept the sticky errors for when QIR generation fails at runtime. These are runtime errors and therefore are not reported by the language service, so no risk of duplication.
Improved the contents of these modal error dialogs to be more user-friendly.
Internals
Added a new
QdkDiagnosticsclass that properly extends JavaScript'sErrortype and contains VS Code-ish diagnosticsMany WASM functions use a
stringas an error type, which is really a JSON-serializedIQSharpError[]array. Given the limitations of wasm-bindgen, and also the fact that this error has to travel across worker threads, we can't really use a more sophisticated error type here.So instead, we convert these into
QdkDiagnosticsin JavaScript.To make sure the error type flows properly from the worker thread to the main thread, we serialize the errors to cloneable objects.
Going forward, when adding new WASM functions, we should try to conform to this pattern of error handling. WASM functions should throw
IQSharpError[]strings wherever appropriate, and the appropriate wrappers should be used in JavaScript to convert it into aQdkDiagnostics.Before/After
For my own sanity, here's a visual list of the places where error UX changed.
Project load error in Run / Debug
Project load error in Histogram / Circuit / Estimate / QIR generation / Submit to Azure
Project load error in Copilot Q# tools / Submit to Azure
Project load error in Documentation generation
Project load error in Test case run (
vscode/src/language-service/testExplorer.ts)Runtime error in QIR generation
Errors in Playground QIR/RIR panels