-
Notifications
You must be signed in to change notification settings - Fork 42
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
De-duplicate errors from sourcekitd and swiftc in the Problems view #653
Comments
I would love to be able to do this, but VSCode considers these two class of errors as coming from different sources and will not merge them. If I had access to the full problems list I could filter the |
And I suppose (sorry if this is a stupid question) you can’t intercept the errors coming from sourcekit-lsp, right to merge them with build issues and then publish them using your own diagnostics provider. Interestingly, I just checked what |
I can't intercept the build errors, but I can intercept the sourcekit-lsp errors. But without knowing what the build errors are I'm not sure what I can do with the sklsp errors. Yeah not showing build errors would be bad. Sourcekit-LSP only picks up the errors for the files that are open, if I understand correctly |
Seems related to #750. I can investigate this one as well. I know that TypeScript handles this well. Would be nice to see how they do it. |
I don't think the Typescript extension displays errors from the compiler. The only errors displayed come from the LSP server. |
See #759 |
To give us more control of the swift process and allow us to consume the output from swift, introduce our own CustomExecution. This will set us up to address swiftlang#750, swiftlang#653 and swiftlang#694. The CustomExecution will load the asar bundled node-pty module that ships with vscode. This way we don't need to build for every platform and arch
To give us more control of the swift process and allow us to consume the output from swift, introduce our own CustomExecution. This will set us up to address swiftlang#750, swiftlang#653 and swiftlang#694. The CustomExecution will load the asar bundled node-pty module that ships with vscode. This way we don't need to build for every platform and arch
* Add a CustomExecution for `swift` tasks To give us more control of the swift process and allow us to consume the output from swift, introduce our own CustomExecution. This will set us up to address #750, #653 and #694. The CustomExecution will load the asar bundled node-pty module that ships with vscode. This way we don't need to build for every platform and arch * Disable conpty when debugging on windows Only an issue when debugging extension. Packaged extension works fine * Fix review comments Biggest change is making sure 'cwd' is set for custom execution * Add some docstring comments Add comments to make the relationship/usage between SwiftExecution, SwiftPseudoterminal, and SwiftProcess more clear
Fixes swiftlang#653 * Keeping "$swiftc" problem matcher around in case it is still being used * Add "diagnosticsCollection" setting to give more control on which diagnostics are kept around and provided to the user * Setup diagnostics from task output and hooking into sourcekit-lsp * Handle merging based on "diagnosticsCollection" setting This does not include serialized diagnostics which will involve changes in swift itself
Fixes swiftlang#653 * Keeping "$swiftc" problem matcher around in case it is still being used * Add "diagnosticsCollection" setting to give more control on which diagnostics are kept around and provided to the user * Setup diagnostics from task output and hooking into sourcekit-lsp * Handle merging based on "diagnosticsCollection" setting This does not include serialized diagnostics which will involve changes in swift itself
Fixes swiftlang#653 * Keeping "$swiftc" problem matcher around in case it is still being used * Add "diagnosticsCollection" setting to give more control on which diagnostics are kept around and provided to the user * Setup diagnostics from task output and hooking into sourcekit-lsp * Handle merging based on "diagnosticsCollection" setting This does not include serialized diagnostics which will involve changes in swift itself
Fixes swiftlang#653 * Keeping "$swiftc" problem matcher around in case it is still being used * Add "diagnosticsCollection" setting to give more control on which diagnostics are kept around and provided to the user * Setup diagnostics from task output and hooking into sourcekit-lsp * Handle merging based on "diagnosticsCollection" setting This does not include serialized diagnostics which will involve changes in swift itself
Fixes swiftlang#653 * Keeping "$swiftc" problem matcher around in case it is still being used * Add "diagnosticsCollection" setting to give more control on which diagnostics are kept around and provided to the user * Setup diagnostics from task output and hooking into sourcekit-lsp * Handle merging based on "diagnosticsCollection" setting This does not include serialized diagnostics which will involve changes in swift itself
Fixes swiftlang#653 * Keeping "$swiftc" problem matcher around in case it is still being used * Add "diagnosticsCollection" setting to give more control on which diagnostics are kept around and provided to the user * Setup diagnostics from task output and hooking into sourcekit-lsp * Handle merging based on "diagnosticsCollection" setting This does not include serialized diagnostics which will involve changes in swift itself
* Deduplicate swift diagnostics Fixes #653 * Keeping "$swiftc" problem matcher around in case it is still being used * Add "diagnosticsCollection" setting to give more control on which diagnostics are kept around and provided to the user * Setup diagnostics from task output and hooking into sourcekit-lsp * Handle merging based on "diagnosticsCollection" setting This does not include serialized diagnostics which will involve changes in swift itself * Add some more diagnostics tests Have tests for parsing from task output, controlling the parsing of a diagnostic across multiple onWrite callbacks, and for handling the merging of diagnostics based on the diagnosticsCollection setting * Fix some issues with cleaning up old diagnostics * Makes sure always cleanup swiftc diagnostics in case diagnosticsCollection setting changed * De-duplicate error messages until swift 6 is fixed * Make sure diagnostic message capitalization is consistent Whether swiftc or SourceKit capitalize the first letter of their message or not, we'll make sure always capitalize so message user sees is consistent, and we can properly merge from the different sources * Parse note diagnotics as nested related information Notes are attached to the preceding error or warning, so when we come across a note, add it as RelatedInformation to the previous Diagnostic Additionally let the user configure the -diagnostic-style option, using "llvm" as the default so we can parse these notes * Only cleanup swiftc diagnostics after new build is done Will listen to change in settings to clear SourceKit or swiftc errors if they are respectfully disabled * Simplify diagnostic merging logic * Fix rebase error * Fix failing CI tests
In the problems pane, it would be nice if we could de-duplicate errors reported by
sourcekitd
andswiftc
. My suggestion for this would be: Ifsourcekitd
reports an error at the same location with the same message asswiftc
, hide it.The text was updated successfully, but these errors were encountered: