Don't suggest imports from deprecated modules

[amesgen]

Closes #2415

I tested this manually for now; but I will also try to come up with a regression test, will remove draft status when that is done.

Concerning the concrete changes in behavior, have a look at this project, specifically the file src/B.hs:

ex1 :: String
ex1 = hello <> " " <> foo

ex2 :: [a] -> Int -> a
ex2 l i = l !? i

ex3 = offsetTimeIncrease

It contains four things which are not in scope, so HLS shows code actions for adding imports for them.

• hello: A non-deprecated identifier from the module A, but also reexported from the deprecated module AD.
  • Before this PR: HLS offers to import hello from both A and AD.
  • After this PR: HLS offers to import it only from A.
• foo: A deprecated identifier from a deprecated module.
  • Before this PR: HLS offers to import it from AD.
  • After this PR: HLS still offers to import it from AD. My only guess it that this is due to HIE files not containing deprecation information? Also compare to offsetTimeIncrease.
• !?: The motivation example from Import extension plugin: don't suggest imports from deprecated modules #2415, now works as expected.
• offsetTimeIncrease: A deprecated identifier from the non-deprecated module System.Time.Extra.
  • Before this PR: HLS offers to import it from Extra and System.Time.Extra.
  • After this PR: HLS does not offer to import it at all.

Any opinions on whether this behavior is fine?

[michaelpj]

This is a bit tricky, I think your behaviour seems reasonable, but we should capture the design in a comment somewhere.

Things are nicer for completion items, where you can explicitly tag them as deprecated...

[July541]

I'd prefer to mark deprecated items as deprecated instead of hiding them. https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#completionItem

[michaelpj]

I'd prefer to mark deprecated items as deprecated instead of hiding them

This PR is only about code actions (despite the branch name), so that doesn't apply. For completions, yeah, we should do that if we don't already.

[amesgen]

I'd prefer to mark deprecated items as deprecated instead of hiding them.

Thanks for pointing that out, I agree. Right now, this PR works by completely forgetting that deprecated identifiers exist, so I am now changing that such that the completion code can take that into account (right now, e.g. deprecated are not marked as such in the completions).

Also, nice touch that the deprecated property is deprecated 😄 (in favor of tags).

[pepeiborra]

Is this ready for review?