Cabal file completions

[VeryMilkyJoe]

Add completion suggestions for cabal files.

Related to #3664, by suggestion of #2940.

Current state:

Completions for keywords

• sensitive to stanzas

Value completion for different kinds of values

We implement completion according to the cabal package description.

• Various simple static values
• Name field (based on cabal file name)
• Licenses
• Files
• Directories
• Exposed modules
• Other modules

Snippet completion

• Snippet for common keywords in cabal file
• Snippets for stanzas and their required fields
• Snippet for common-warnings

Examples

Keyword completion inside a stanza:

Value completion for existing keyword:

Snippet for library stanza

[michaelpj]

Generally look good! I think my main high-level worry is that this might not deal well with large files because it looks like it's doing a decent amount of stuff that's linear in the number of lines. Yes, cabal files tend to be short, but they could be long, e.g. imagine if we did actually merge all the HLS packages into a single package with many libraries!

I had two thoughts about fixing this:

1. Use the Rope type that the VFS uses for file contents, which has good performance for line-based operations
2. Actually parse the file into some kind of structure which we can then use for efficiently looking up where a position is later. This would be more work, I'm not sure if we could reuse the cabal parser or whether we'd need to do something else, but in principle you could look at the source spans for syntax elements and try to descend into the closest piece of syntax while hopefully doing a number of operations proportional to the depth of the syntax tree instead.

[VeryMilkyJoe]

1. Use the Rope type that the VFS uses for file contents, which has good performance for line-based operations

Thank you! I will include this.

2. Actually parse the file into some kind of structure which we can then use for efficiently looking up where a position is later. This would be more work, I'm not sure if we could reuse the cabal parser or whether we'd need to do something else, but in principle you could look at the source spans for syntax elements and try to descend into the closest piece of syntax while hopefully doing a number of operations proportional to the depth of the syntax tree instead.

I have thought about this, since it would probably make a lot of the cabal plugin's features more neat in the long run.
As far as I can tell there is no AST representation of cabal files, which is what we would want, I only found the GenericPackageDescription which does not contain source spans and neither does the cabal parser. It seems like there is no intermediate representation used anywhere (https://hackage.haskell.org/package/Cabal-syntax-3.10.1.0/docs/Distribution-PackageDescription-Parsec.html#v:parseGenericPackageDescription).
It might be nice to implement our own representation but I would argue that this is out of scope for this PR.

[fendor]

First review round! 🎊

I think this is in a good shape, couple of tests, couple of docs and then we can likely merge it, imo.

[michaelpj]

Ran out of time so I just commented on the file completions.

[fendor]

LGTM, last review round, then we will merge this.

[fendor]

LGTM, let's get this merged and get some user feedback.