Plugin: hls-cabal-plugin

[fendor]

Support for cabal files

This issue tracks the efforts to bring language server support for cabal files to HLS.
Cabal files are an integral part of Haskell projects, but currently, HLS can not help you at all with writing cabal files, there is no error if a construct is unknown, we can not auto-complete field names, we have no knowledge about modules, etc...

Adding first-class support cabal files is a huge amount of work, so we break it up into multiple sub-issues, that can be worked on individually.

Features

Formatting of .cabal files

A nice-to-have thing is to be able to format cabal files, which helps to minimise bikeshedding about formatting, minimises git-diffs, etc...
Moreover, formatters can bring long-desired features, such as auto-expand of exposed modules.
Thanks to @VeryMilkyJoe, we have #2047 which is already a POC of using cabal-fmt for formatting and needs to be pushed over the finish line.

cabal format is not suited for formatting as it inlines common sections.

Completion

Assistance in writing cabal files through completion suggestions.
See #3664 for status and details.

Completion of field-names

Auto-completion of field-names is a must-have in a configuration language. What does this entail? Ideally you can just use auto-completion to figure out what fields are available in a specific section.
For example, we should be able to complete: name, cabal-version, version, author, license, homepage, and many more.

As the next step we want to be able to auto-complete within stanzas, such as library, executable, testsuite and benchmark.
In these stanzas, the available fields are different, thus auto-completion needs to be aware of its current location within the cabal file.

Completion of cabal values

This is the natural extension of the former: now we want to be able to aid users to fill-in the values in a cabal file and suggest sensible inputs.

For example, when users want to fill in the cabal-version not all values are valid, suggesting the ones that we know of (maybe even with short explanations) will make it trivial to write a cabal file.

Keys that we can easily autocomplete the values for: cabal-version, license, license-file, build-type, default-language, testsuite > type and source-repository > type.

Keys that require more work to autocomplete: ghc-options, hs-source-dirs, exposed-modules, other-modules, main-is and last but not least build-depends.

Snippets

Snippets can be used to generate blocks that are commonly used. As an example:

mainlib<trigger autocomplete>

can get expanded to:

library
  exposed-modules:    [] # <-- needs to be filled by users
  hs-source-dirs:     []
  build-depends:      base
  ghc-options:        -Wall
  -- other-modules:
  default-language: Haskell2010

Many more of these snippets can be added to aid the writing of cabal files. Especially newcomers will benefit from such a feature, as it helps to fill out less-known fields and teaches you at the same time about the available fields.

Diagnostics

Clearly, we also want to display errors in the file format immediately, such as parsing errors, or invalid values for fields, unknown fields, maybe even complain when modules do not exist in the filesystem!

We can imagine many more kinds of diagnostics.

Linting

The cabal check can be helpful to find common errors or issues that would forbid users to upload their package to hackage.

Limitations

This issue does not cover any coordination between Haskell files and cabal files, such as #2851 and #659

[fendor]

All features discussed in this issue have been implemented, afaict. So closing, now we still need a vscode-haskell release haskell/vscode-haskell#1103 and another HLS release with the latest changes :)