Description
HLS uses in many locations regexes to extract information out of GHC diagnostics to then offer code actions based on them.
This has served us well for many years, but it is time for an improvement!
GHC has structured diagnostics since GHC 9.4 (at least), but HLS isn't really using them, even though we keep them around since #4433.
This issue tracks the effort to update the full HLS codebase to use structured diagnostics instead of handwritten regex matchers.
- ghcide (huge amount of work)
- hls-alternate-number-format-plugin
- hls-call-hierarchy-plugin
- hls-change-type-signature-plugin
- hls-class-plugin (Draft: Migrate
hls-class-pluginto use structured diagnostics #4472 @fendor) - hls-code-range-plugin
- hls-eval-plugin
- hls-explicit-fixity-plugin
- hls-explicit-imports-plugin
- hls-explicit-record-fields-plugin
- hls-gadt-plugin
- hls-hlint-plugin
- hls-module-name-plugin
- hls-notes-plugin
- hls-overloaded-record-dot-plugin
- hls-pragmas-plugin
- hls-qualify-imported-names-plugin
- hls-refactor-plugin (huge amount of work)
- hls-rename-plugin
- hls-retrie-plugin
- hls-splice-plugin
- hls-stan-plugin
Not all the listed plugins actually benefit from structured diagnostics, but we need to check which ones need to be updated. For example, I don't hls-stan-plugin uses ghc in any way, so will likely not need updating.
I will update the list as time goes on.
The task for each of these plugins/packages would be to check whether the plugin needs updating, try to migrate it to use structured diagnostics or document what is missing to migrate them to structured diagnostics. This may require us to send issues to GHC upstream.
If you need inspiration for what this migration may look like, the PR #4472 migrates the hls-class-plugin to use structured diagnostics.
I am planning to present this issue at ZuriHac, if you want to work on migrating a plugin, please comment here and I will update the table.