The code action to import a qualified identifier does not produce a qualified import anymore

[Kleidukos]

Your environment

Which OS do you use? Fedora 36

Which version of GHC do you use and how did you install it? GHC 9.4.4 via ghcup

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

Which LSP client (editor/plugin) do you use? nvim_lsp

Which version of HLS do you use and how did you install it? latest master via ghcup

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

Steps to reproduce

Reproducer code

module Reproducer where

operation :: [a] -> [b]
operation = List.map

screenshot of the suggestions

Expected behaviour

HLS used to be able to suggest qualified imports for qualified identifiers

Actual behaviour

HLS is not able to suggest qualified imports for qualified identifiers anymore

Debug information

No idea what to include, please advise.

[wz1000]

See

haskell-language-server/plugins/hls-refactor-plugin/test/Main.hs

Line 1672 in 2b691b6

, ignoreForGHC94 "On GHC 9.4 the error message doesn't contain the qualified module name: https://gitlab.haskell.org/ghc/ghc/-/issues/20472"

[wz1000]

In particular https://gitlab.haskell.org/ghc/ghc/-/issues/22130

[Kleidukos]

Okay! So I have two questions:

1. Is it possible to convey this information in the UI between the time where this is discovered and fixed?

2. Shouldn't https://haskell-language-server.readthedocs.io/en/latest/support/plugin-support.html#current-plugin-support-tiers be heavily updated?
   One of the reasons that made me switch to GHC 9.4 for everyday development was seeing that only eval, stan, haddock and tactics plugins were unsupported, on the latest version of the documentation.

[michaelpj]

Is it possible to convey this information in the UI between the time where this is discovered and fixed?

Not AFAIK. How would you convey it?

Shouldn't https://haskell-language-server.readthedocs.io/en/latest/support/plugin-support.html#current-plugin-support-tiers be heavily updated?

We don't distinguish between "working at all for a GHC version" and "working but with caveats". We could do, but we can barely keep up with the information as it is.

[Kleidukos]

@michaelpj now I'm confused, isn't the whole purpose of Tier 2 to signify "it works but with caveats"??

Not AFAIK. How would you convey it?

Well I'm asking because you're the LSP person ;-)

[michaelpj]

Does it say that? Serious question, I would like to rephrase it to be clearer! The intention is more about whether we need to have it building with a new GHC before we release HLS/declare that we support that GHC version.

We don't have a finer distinction for "this works with this GHC version but not very well".

Well I'm asking because you're the LSP person

I'm asking you where you'd like to see it because you're the user ;) But seriously, there are two problems
a) It's tricky to say how to advertise information about absence
b) The LSP protocol is not that sophisticated in many ways, and it's not even clear how to sensibly convey this kind of information

[skykanin]

As a user I find it very surprising that plugins marked as tier 1 might only partially work for GHC versions that HLS supports. When the plugins support tiers page indicates that a plugin is working I don't take that to mean "at least partially working".

[wz1000]

Since this is a GHC regression, we can't really do much about it in HLS. We simply do not have enough information in HLS with GHC 9.4 to fix this. I'm not sure what we can do here, because the plugin has been ported to GHC 9.4, its just that some features cannot work with GHC 9.4.

[Kleidukos]

@wz1000 indeed on the technical level there isn't much that can be done (and I'm not implying that you have failed in any way), however the tier system and its unwritten infidelities can be worked on to adhere closer to the principle of least surprise.

Moreover, even if not perfect, functions like knownIssueFor could be made to output their parameters in a format that the docs could import to generate the compatibility table.

Of course I'm not throwing ideas and expecting you to implement them. If you're open to such a contribution, I can submit a patch for the compatibility data to be amended with the output of knownIssueFor.

[wz1000]

Of course I'm not throwing ideas and expecting you to implement them. If you're open to such a contribution, I can submit a patch for the compatibility data to be amended with the output of knownIssueFor.

This sounds like a good idea, but it may be a lot more work than you bargained for. Many tests in the testsuite are disabled using these functions not because the feature doesn't work, but because nobody figured out how to make the test work, or due to subtle (but not incorrect) differences across GHC versions.

[michaelpj]

When the plugins support tiers page indicates that a plugin is working I don't take that to mean "at least partially working".

It means working well enough that we think we can ship it. As @wz1000 says, almost all versions of GHC have a few quirks that make certain things not work or not work perfectly. I don't think we can realistically provide this information to users.

I do think we could decide that we don't consider a plugin "supported" for a GHC version if it has critical bugs, and then we could have considered this a critical bug. Obviously, a PR claiming to make a tier 1 plugin support a new GHC version by disabling all the functionality would not be acceptable!

[ParetoOptimalDev]

When the plugins support tiers page indicates that a plugin is working I don't take that to mean "at least partially working".

It means working well enough that we think we can ship it. As @wz1000 says, almost all versions of GHC have a few quirks that make certain things not work or not work perfectly. I don't think we can realistically provide this information to users.

I do think we could decide that we don't consider a plugin "supported" for a GHC version if it has critical bugs, and then we could have considered this a critical bug. Obviously, a PR claiming to make a tier 1 plugin support a new GHC version by disabling all the functionality would not be acceptable!

At work we've dropped HLS (and re-adopted) quite a few times because of tier-1 features not working or having critical bugs. We tend to re-evaluate whenever a big major version gets released.

If tier-1 guaranteed "no critical bugs" there would be less surprise for us re-adopting HLS. In fact I believe frustration from not knowing tier-1 didn't make the "no critical bugs" distinction might have led to us dropping HLS a few times when we didn't need to.