Import suggestion for missing newtype constructor, all types constructor and indirect overloadedrecorddot fields

[guibou]

This MR contains 3 commits which improves the import suggestion code actions:

• suggests to import a module when the newtype constructor is not in scope. This usually happen when coerceing newtype.
• suggests to import a module when all the data constructors for a type are not in scope. This usually happen when creating an instance of a type from another module. For example, deriving instance Generic Bar when Bar (the type) may be in scope, but not the construtors (e.g. requiring Bar(..)).
• suggests to import a module when a field of a type is not in scope and used in an OverloadedRecordDot context, such as foo.bar where foo :: Foo and Foo(bar) is not in scope. Note that this is already partially handled by HLS in the case where the module containing Foo is already imported, but not the fields. In this context, GHC is kind enough to give us an hint (something like "maybe add field bar to import line...") and this is already handled by HLS. However, if the module containing Foo is not already imported, it does not work.

All of these case usually happen when types are "indirectly" in scope. For example, consider the followings:

module T where

data Foo = Foo { foo :: Int }

module Value where
import T

foo = Foo 10

module Usage where

import Value

result = foo.foo

In the module Usage, the type Foo is not explicitly imported, it exists just indirectly because foo is imported from Value.

Discussion

I tried to take care of multiples patterns in the regex used to match the error messages, such as qualified or not qualified types or class, as well as polymorphic or not. If you see a case not taken into account, please tell me.

Tests

I've added simple tests for the coerce and instance Generic "cases" and a more involved test for the overloaded record dot cases.

I've developed this using GHC 9.10. I'll test on other version of GHC asap, perhaps some adaptations of the regex need to be introduced.

[guibou]

Rebased and fixed test for GHC 9.4.

[soulomoon]

Thanks for the change ~
I think we just need more test on the regex.
Otherwise it is good to go.

[guibou]

I've added a new commit which fixs (and add tests) for not in scope record field.

This was working fine with ghc <9.10 when the message was Not in scope: 'foo' but since it is now Not in scope: record field 'foo' the result was that record was matched instead of foo.

see:

The regex associated with Not in scope are fragile and maybe there are other not in scope which are infortunately matched incorrectly.

[guibou]

I'm not happy. Looks like I hit the difference in GHC 9.10 (and 9.8) about in which context fields name are found.

Even if the NotInScopeTHing contains the right "foo" naming, it is not able to locate this value inside the map of indexed symbols.

I'll investigate a bit more.

[guibou]

I finally found the solution (I hope), which is to use lookupOccEnv_AllNameSpaces in order to look for symbol in all namespaces, including field selector namespaces.

I've done this refactor, added a bit more tests, tell me what you think.

Note that, maybe in a future refactor, we could try to be a bit more selective in the way we are looking for import. The NotInScope thing may contain more information that what we currently use. It contains if the symbol looked for is a type, a data, a variable, and can also be extended in order to contain the field selector information, and the lookup function can be extended to take that into account, leading to less conflicts (e.g. a missing record selector toto won't suggest the import of the function toto).

Note also that some of the tests in this MR, related to field selector, are just testing that we can suggest to import the Type name (e.g. import Module (Foo(..)) and could be extended to add support for selecting the field (when both type and field name are present, such as is HasField instance error) and the test could also be extended to test the different configuration. But maybe that's a bit outside of the scope of this MR.

[guibou]

With ghc 9.10 ;)

[soulomoon]

Note that, maybe in a future refactor, we could try to be a bit more selective in the way we are looking for import.

Maybe we can open issue to track the things we would want to do for imports. And hopefully tackle them one by one.

[soulomoon]

Great work, @guibou!
This looks good to me now — a solid improvement to the current import system.
Personally, I use import suggestions quite frequently, so this is a very welcome enhancement.