haskell / haskell-language-server

Official haskell ide support via language server (LSP). Successor of ghcide & haskell-ide-engine.
Apache License 2.0
2.66k stars 355 forks source link

More flexible prefix matching #3585

Closed noughtmare closed 1 year ago

noughtmare commented 1 year ago

Is your enhancement request related to a problem? Please describe.

The problem occurs when you add a new module, but forget to update your cabal file. Then HLS will show an error that is hard to understand:

Multi Cradle: No prefixes matched
pwd: c:\Users\nubch\Documents\haskell\tictactoe\tictactoe2 filepath: C:\Users\nubch\Documents\haskell\tictactoe\tictactoe2\app\Libr.hs prefixes: ("app/Main.hs",Cabal {component = Just "tictactoe2:exe:tictactoe2"})

Full context: https://old.reddit.com/r/haskell/comments/13c1ga5/on_the_verge_of_giving_up_learning_haskell/

Edit, another victim: https://discourse.haskell.org/t/cabal-quickstart-with-hls-pains/6867

Describe the solution you'd like

HLS should handle modules that are not explicitly listed in the other-modules or exposed-modules fields as long as the modules are still located in a directory specified by hs-source-dirs. It should still display a warning that the module is not listed in the cabal file, but it should not prevent HLS from working on those unlisted modules.

Describe alternatives you've considered

We could keep the status quo and require users to edit the cabal file or create a hie.yaml file, but those are both manual actions that take a small bit of effort and more importantly it is one more thing for newcomers to get stuck on as the reddit thread linked above shows.

Another alternative is that HLS could show a better error message which spells out that you might need to update your cabal file. I think this would be much better than the status quo, but not as good as just being more flexible.

michaelpj commented 1 year ago

This is a hie-bios issue.

michaelpj commented 1 year ago

Or possibly I'm wrong and it's implicit-hie :thinking: @fendor?

fendor commented 1 year ago

@michaelpj While I agree that the issue happens in hie-bios, I don't think hie-bios is in the position to provide less accurate info or should start guessing to what component the file might belong to.

It is not the fault of implicit-hie either here, imo.

I think the best way would be in HLS (likely supported by hie-bios/cabal/stack) to provide better diagnostics, telling the user that they are missing something.

Although, this error message in particular is a combination of implicit-hie and hie-bios providing a subpar developer experience.

michaelpj commented 1 year ago

Hmm. So what happens is something like:

So we're complaining about an issue in a file the user didn't write, which is always awkward. I'll put this back in HLS I guess, since it's kind of a combined issue.

noughtmare commented 1 year ago

The reason why I think being more flexible is a better solution than just providing better error messages is that cabal build is also flexible in this situation. And I think it would be nice if HLS would always work if cabal build works.

Edit: I have now been convinced that a better error message and a code action to add the module to the cabal package would be a better solution.

fendor commented 1 year ago

To be extremely pedantic, cabal is not flexible, it is ghc who picks up the file from the source directories, but HLS doesn't accept that and wants all targets explicitly listed.

michaelpj commented 1 year ago

I do think this is maybe an implicit-hie issue. implicit-hie could try and emit a match for other modules that are not in the cabal file and guess a component for them. It would be potentially error-prone but would probably work a lot of the time.

seanhess commented 1 year ago

How can I help? I'm the author of the issue just linked above, and the user from the second discourse link in the OP. I'm an experienced haskeller, but with zero exposure to HLS or hie. If you point me in the right direction I'd be happy to work on it. I have a full week off before I start a new job. I hope that's enough time to become familiar enough to contribute something

fendor commented 1 year ago

@seanhess Hi! I am currently putting together some thoughts in my head and I am going to write it down later this day. Do you want to implement a better error message that tells the user potential remedies? This error message will then be used by @VeryMilkyJoe (who is our hls-cabal-plugin author for this summer) to implement a code action for #3595.

If you are interested to do that, then I will write a detailed roadmap for you. I am also available for a call for resolving questions.

seanhess commented 1 year ago

Sure, I would be happy to do that! I’ll look for your roadmap

On Sat, Jul 8, 2023 at 7:56 AM fendor @.***> wrote:

@seanhess https://github.com/seanhess Hi! I am currently putting together some thoughts in my head and I am going to write it down later this day. Do you want to implement a better error message that tells the user potential remedies? This error message will then be used by @VeryMilkyJoe https://github.com/VeryMilkyJoe (who is our hls-cabal-plugin author for this summer) to implement a code action for #3595 https://github.com/haskell/haskell-language-server/issues/3595.

If you are interested to do that, then I will write a detailed roadmap for you. I am also available for a call for resolving questions.

— Reply to this email directly, view it on GitHub https://github.com/haskell/haskell-language-server/issues/3585#issuecomment-1627307846, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAD66M65I567T6YGCWTTN3XPFRIHANCNFSM6AAAAAAX43CYUE . You are receiving this because you were mentioned.Message ID: @.***>

fendor commented 1 year ago

closing in favour of #3695 which tracks the effort and outlines an implementation plan.