Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Warnings in Cabal files #196

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.

Sign up for GitHub

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

Jump to bottom
Open
dschrempf opened this issue Apr 14, 2025 · 3 comments
Open

Warnings in Cabal files #196

dschrempf opened this issue Apr 14, 2025 · 3 comments

Comments

@dschrempf
Copy link
Contributor

dschrempf commented Apr 14, 2025 •
edited
Loading

When activating lsp-mode in Haskell Cabal files, I receive numerous warnings (I tried GHC 9.10.1, HLS 2.9.0.0 and HLS 2.10.0.0):

LSP :: Error from the Language Server: No plugins are available to handle this SMethod_TextDocumentDocumentHighlight request.
 Plugins installed for this method, but not available to handle this request are:
ghcide-hover-and-symbols does not support .cabal filetypes). (Method not Found)

A temporary fix is

(add-hook 'haskell-cabal-mode-hook
            ;; Document highlight is not supported for Cabal files.
            (lambda () (setq-local lsp-enable-symbol-highlighting nil)))

There are still some warnings about code lenses, but they are less prominent, and do not disturb the workflow.

EDIT:
For Cabal project files, we get more warnings:

pragmas-suggest does not support .project filetypes).
ghcide-code-actions-bindings does not support .project filetypes).
cabalHaskellIntegration does not support .project filetypes).
explicit-fields does not support .project filetypes).
ghcide-code-actions-type-signatures does not support .project filetypes).
ghcide-code-actions-fill-holes does not support .project filetypes).
changeTypeSignature does not support .project filetypes).
ghcide-code-actions-imports-exports does not support .project filetypes).
cabal does not support .project filetypes).
overloaded-record-dot does not support .project filetypes).
gadt does not support .project filetypes).
importLens does not support .project filetypes).
class does not support .project filetypes).
qualifyImportedNames does not support .project filetypes).
alternateNumberFormat does not support .project filetypes).
pragmas-disable does not support .project filetypes).

I guess this is to be expected. Do you think it is worth adding support for cabal and cabal.project files? Where do we need to start? What do you think?
@dschrempf
Copy link
Contributor Author

dschrempf commented Apr 18, 2025 •
edited
Loading

I just had a brief look at the LSP, and I think HLS is doing the correct hting here. It advertises a maximum set of capabilities across all file types to the client, but then informs the client that it can not handle speicific requests for specific file types.

So we should handle this on the client side.

The question is, does lsp-mode provide functionality for this (multiple file types with different capability subsets), or do we have to write special code for lsp-haskell? We can either deactivate features after receiving the warning response from the server, or we can deactivate those features right away.

I also saw that there was a release for VSCode which includes Cabal file support. vscode-haskell activates the Cabal file support depending on the HLS version available, but I do not think it activates a different set of capabilities depending on the HLS version.

@michaelpj
Copy link
Collaborator

Hmm, I think this is probably a HLS bug? We have had various issues in HLS of this form, where we support a particular feature in some but not all situations, so we end up returning errors unhelpfully. Here we do support symbol highlighting, just not in cabal files. AFAIK there is no way for us to express the true situation in the LSP capability model, so I think we just need HLS to return an empty result in this case or something.

@dschrempf
Copy link
Contributor Author

OK, that makes sense but differs from what I got when reading the specs. I guess what I did not see is that the correct responses would be empty-like objects, and not Errors/Warnings, as you said.

@dschrempf dschrempf mentioned this issue Apr 18, 2025
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@michaelpj @dschrempf