You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, diagnostics are reported using problem matchers. This works, but has several downsides:
Diagnostics are duplicated between Sweetpad and sourcekit-lsp: sourcekit-lsp reports errors and warning on the fly for open files using the index datastore. When building, xcodebuild will report the same errors, this is expected. Because these errors are now matched by Swetpad, it causes duplicate errors in the diagnostics panel for the same file and line number.
Diagnostics persist even when a file is changed. When a file contains an error at a specific line, that error remains there even when the file is changed. This causes errors to show up in wrong places and, even worse, it causes errors to be shown even when the underlying issue is fixed. This is also reported in Build errors stay in the "Problems" panel #171
Proposal
To fix these issues, Sweetpad could adopt a different way of reporting diagnostics. Instead of using problem matchers, issues can be detected in the build output manually. This allows the extension to loop through all extracted diagnostics, filter out the diagnostics that are already reported by sourcekit-lsp, and only report those errors which do not already exist.
For the second issue, Sweetpad could observe document events and clear diagnostics in a file when the document is changed. This prevents stale diagnostics from showing up in the wrong place. Since that file is now open, sourcekit-lsp will handle diagnostic reporting on the fly.
Currently, diagnostics are reported using problem matchers. This works, but has several downsides:
xcodebuildwill report the same errors, this is expected. Because these errors are now matched by Swetpad, it causes duplicate errors in the diagnostics panel for the same file and line number.Proposal
To fix these issues, Sweetpad could adopt a different way of reporting diagnostics. Instead of using problem matchers, issues can be detected in the build output manually. This allows the extension to loop through all extracted diagnostics, filter out the diagnostics that are already reported by
sourcekit-lsp, and only report those errors which do not already exist.For the second issue, Sweetpad could observe document events and clear diagnostics in a file when the document is changed. This prevents stale diagnostics from showing up in the wrong place. Since that file is now open,
sourcekit-lspwill handle diagnostic reporting on the fly.