More flexible prefix matching

[noughtmare]

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]

This is a hie-bios issue.

[michaelpj]

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

[fendor]

@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]

Hmm. So what happens is something like:

• implicit-hie makes a specific hie-bios cradle that matches the various known paths
• hie-bios notes that this file doesn't match any of the paths, so it gives up

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]

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]

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]

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]

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]

@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]

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 <#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 <#3585 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAD66M65I567T6YGCWTTN3XPFRIHANCNFSM6AAAAAAX43CYUE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[fendor]

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