When encountering an unsupported GHC version, HLS should output the last supported GHC version

[niekvandepas]

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

I just tried using HLS in VS Code (via the Haskell extension) and got an error message saying, "ERROR Error: HLS does not support GHC 9.10.2 yet." Understandable, but it would be nice to know what version of GHC I can use.

Describe the solution you'd like

The error message should include the latest supported GHC version.

Describe alternatives you've considered

Googling it which is annoying and not straightforward, since support for particular GHC versions depends on the version of HLS you're using, which you then have to look up as well, so you have to google how to do that, etc.

[fendor]

Thanks for the bug report!

The error message originates from vscode-haskell's GHCup integration. It should be doable to fix this in vscode-haskell.

PRs welcome!

[niekvandepas]

I'm not familiar with the codebase, but glancing at it, I think the fix should be in hlsBinaries.ts, around line 480:

// first we get supported GHC versions from available HLS bindists (whether installed or not)
const metadataMap = (await getHLSesfromMetadata(context, logger)) || new Map<string, string[]>();
// then we get supported GHC versions from currently installed HLS versions
const ghcupMap = (await getHLSesFromGHCup(context, logger)) || new Map<string, string[]>();
// since installed HLS versions may support a different set of GHC versions than the bindists
// (e.g. because the user ran 'ghcup compile hls'), we need to merge both maps, preferring
// values from already installed HLSes
const merged = new Map<string, string[]>([...metadataMap, ...ghcupMap]); // right-biased
// now sort and get the latest suitable version
const latest = [...merged]
  .filter(([_k, v]) => v.some((x) => x === projectGhc))
  .sort(([k1, _v1], [k2, _v2]) => comparePVP(k1, k2))
  .pop();

if (!latest) {
  throw new NoMatchingHls(projectGhc);
} else {
  return [latest[0], projectGhc];
}

ghcupMap I think is a map of installed HLS versions to compatible GHC versions. How do we decide which version of HLS gets preference if multiple are installed, and thus what GHC to recommend installing?

Once we know what version of GHC to recommend, the change to the error constructor is trivial (although the error message I just wrote is ugly):

export class NoMatchingHls extends Error {
  constructor(readonly ghcProjVersion: string, readonly supportedGhcVersion: string) {
    super(`HLS does not support GHC ${ghcProjVersion} yet; supported GHC version is ${supportedGhcVersion}`);
  }
  public docLink(): Uri {
    return Uri.parse('https://haskell-language-server.readthedocs.io/en/latest/support/ghc-version-support.html');
  }
}

[fendor]

I am not 100% sure, but there are a couple of factors we take into account, predominantly user-choice. When the user chooses an older GHC version, we try to install an HLS version compatible with the GHC version. If the user chooses a specific HLS version, we try to use it.

By default, I believe we install a dummy toolchain, check which GHC version is used by the user on this particular project, and then install the HLS version compatible with the chosen GHC version.

[hasufell]

The following file is out of date: https://github.com/haskell/ghcup-metadata/blob/develop/hls-metadata-0.0.1.json

[fendor]

Thanks for pointing this out! I hadn't realized.

[hasufell]

haskell/ghcup-metadata@8e67d7c

[niekvandepas]

Hmm, reconsidering what feedback we want to present to the user on a GHC/HLS version mismatch... it seems there are two options:

• "Current version of HLS does not support . Latest GHC version that works with current HLS is ."
• "Current version of HLS does not support . Latest HLS that works with your project GHC version is .

I don't really have an intuition as to which is preferable...

[fendor]

I think, ideally, it depends on what the user has explicitly requested. If the user explicitly requested to use a specific HLS version, then the first error message would be good, otherwise the latter.
Similarly, we would like to show the former (or something else entirely?), if there is no HLS version that supports the given GHC version, but the latter in most other cases.

So, maybe that's the way forward for now? If there is no HLS version compatible with the current GHC version, report this, otherwise suggest the latest HLS version that is compatible with the project GHC version?