Skip to content

HLS looking in wrong ghcup directory for documentation #3858

Open
@lordmilko

Description

@lordmilko

Your environment

  • Windows 11
  • GHCup 0.1.19.4
  • GHC 9.4.7
  • cabal 3.10.1.0
  • HLS 2.4.0.0
  • vscode 1.83.1
  • vscode-haskell 2.4.1

Which OS do you use?
Windows

Which version of GHC do you use and how did you install it?
9.4.7 from GHCup

How is your project built (alternative: link to the project)?
cabal

Which LSP client (editor/plugin) do you use?
vscode + vscode-haskell

Which version of HLS do you use and how did you install it?
2.4.0.0 from ghcup

Have you configured HLS in any way (especially: a hie.yaml file)?
No

Steps to reproduce

There is a somewhat secret feature of HLS wherein on hover, it can show a link to Documentation/Source code on Hackage - but evidently only when you have local *.html documentation files for the code you're trying to view (which is itself a bit confusing, given you're taken to a webpage on Hackage anyway)

image

While the expectation is that such documentation would be generated under C:\cabal\store\<ghc>\<package>\share\doc, curiously, in my instance, despite having documentation: True and ghc-options: -haddock in my C:\cabal\config file, no documentation was generated for any packages; not that this necessarily mattered, because documentation for core libraries was generated under C:\ghcup\ghc\9.4.7\doc\html\libraries

To some extent, this is not a problem for HLS, because it exclusively seems to look for documentation under my ghcup installation. However, it would appear that HLS erroneously believes that ghcup documentation will exist under the path C:\ghcup\ghc\doc, as shown in this capture from Process Monitor

image

This is wrong - HLS should instead be looking under the subdirectory of the version of GHC that is in use by the project, i.e. in my case C:\ghcup\ghc\9.4.7\doc

If I symlink C:\ghcup\ghc\doc to C:\ghcup\ghc\9.4.7\doc, HLS is able to see the documentation and the Documentation and Source links display as expected, however symlinking to a specific GHC install defeats the purpose of using GHCup.

While for my purposes I'm mainly interested in getting on-hover-documentation going for the built in libraries, it's super hard to find any information about how to correctly configure this feature properly; there are half a dozen different issues that all seem to contain contradictory information.

Expected behaviour

HLS should locate the *.html documentation files in the correct directory

Actual behaviour

HLS looks in the wrong directory for *.html documentation files

Metadata

Metadata

Assignees

No one assigned

    Labels

    HackathonThis issue is suitable for hackathon sessionslevel: easyThe issue is suited for beginnersos: windowstype: bugSomething isn't right: doesn't work as intended, documentation is missing/outdated, etc..

    Type

    No type

    Projects

    Status

    Todo

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions