Inconsistent/unhelpful types in hover messages

I'm in the middle of case bashing out some code. It looks like this:

```
type (⥤) :: (*, *) -> (*, *) -> *
data ax ⥤ by
where
Pairrow :: (a -> b) -> (x -> y) -> '(a, x) ⥤ '(b, y)

infixr 0 ⥤

type (:⚡) :: (*, *) -> (*, *) -> *
data ax :⚡ by
where
LL :: x -> b -> '(a, x) :⚡ '(b, y)
LM :: a -> b -> '(a, x) :⚡ '(b, y)
LR :: a -> y -> '(a, x) :⚡ '(b, y)

infixr 5 :⚡

type (⚡:) :: (*, *) -> (*, *) -> *
data ax ⚡: by
where
RL :: a -> y -> '(a, x) ⚡: '(b, y)
RM :: x -> y -> '(a, x) ⚡: '(b, y)
RR :: x -> b -> '(a, x) ⚡: '(b, y)

infixr 5 ⚡:

type (:⚡:) :: (*, *) -> (*, *) -> (*, *)
type ab :⚡: cd = '(ab :⚡ cd, ab ⚡: cd)

assoc :: forall a b c d e f. '(a, b) :⚡: ('(c, d) :⚡: '(e, f)) ⥤ ('(a, b) :⚡: '(c, d)) :⚡: '(e, f)
assoc = Pairrow
(\case
x `LL` (y `LL` z) -> (x `RM` y) `LL` z
-- x `LL` (y `LM` z) -> (x `RR` y) `LL` z
x `LL` (y `LM` z) -> (x `LL` y) `LM` z
x `LL` (y `LR` z) -> (x `LL` y) `LR` z

x `LM` (y `LL` z) -> (x `LR` y) `LM` z
x `LM` (y `LM` z) -> (x `LM` y) `LM` z
x `LM` (y `LR` z) -> (x `LM` y) `LR` z

x `LR` (y `RL` z) -> (x `LM` y) `LR` z
x `LR` (y `RM` z) -> (x `LR` y) `LR` z
-- x `LR` (y `RR` z) -> (x `LR` y) `LM` z
x `LR` (y `RR` z) -> (x `RL` y) `LL` z
)

(\case
l `RL` m -> _ l m
)
```

On the last line, there is a hole, plus a couple terms I pattern matched out. I would like to know the types of these terms to facilitate further programming. When I look at the hover information at various positions in that line, here is what I see:

On the pattern variable `l`:


On the infix pattern constructor `RL`:


On the pattern variable `m`:


On the hole:


On the use of `l` on the RHS of the arrow:


On the use of `m` on the RHS of the arrow:


So far, what this tells me is that:

```
l :: a
m :: y
```

Which is not very enlightening. The fact that the type of `l` is correct is a complete coincidence: the `a` it is talking about is not the same `a` as in the type signature. Moreover the type of `m` is apparently just "`y`", instead of the composite type involving `:⚡:` that I expect. The `a` and `y` type variables actually arise from the data constructor's type signature, and are both out of scope in this context.

If I change the type to:

```
assoc :: forall aa b c d e f. '(aa, b) :⚡: ('(c, d) :⚡: '(e, f)) ⥤ ('(aa, b) :⚡: '(c, d)) :⚡: '(e, f)
```

I would like to be informed that the type of `l` is `aa` (instead the hover information still blithely reports `l :: a`).

The eagle-eyed reader will notice that the hover information from the hole actually has _two_ type signatures in it. The second type signature is the more accurate one, so whatever machinery is producing the hole type error is unifying things sufficiently to tell me the complicated type of `m` (and similarly is talking about the "right" `a`, and would update to `aa` in the scenario above, etc.). It would be nice if the machinery that produced hover information was just as accurate.

I'm assuming the hover information is actually coming from the annotated AST in an .hie file or byproduct, so it might need some tweaking of `ghc` to accomplish this (maybe this needs to be filed there?).