how receptive would y'all be to a patch that puts the `TcLclEnv`, or something similar inside `XUnboundVar GhcTc`.

That sounds plausible.   But is an unbound-var the only place an editor/IDE tooling might want to get its hands on such a thing?   ie would that solve your problem, but not the next person’s?

Also note that you could easily build up a list of all the in-scope Ids simply by gathering them from the tree as you walk inwards.  There’s no actual need for a new function -- although I can see it might be more convenient.

Simon

From: ghc-devs <ghc-devs-bounces@haskell.org> On Behalf Of Sandy Maguire
Sent: 18 August 2019 01:28
To: ghc-devs@haskell.org
Subject: Getting a hole's relevant local binds?

Hi all,

I'm trying to get my hands on the relevant local binds (as reported by ghc in the presence of a type hole) for editor tooling support. Tracing the code suggests that these things come from the `TcLclEnv`, but afaict, all remnants of `TcLclEnv` are thrown away by the time we get a `TypecheckedModule`.

Am I mistaken in this? If not, how receptive would y'all be to a patch that puts the `TcLclEnv`, or something similar inside `XUnboundVar GhcTc`. This way editors would have an easy means of getting their hand on whatever is in scope at the site of a hole, without resorting to parsing error messages.

Cheers,

Sandy

--

I'm currently traveling the world, sleeping on people's couches and doing full-time collaboration on Haskell projects. If this seems interesting to you, please consider signing up as a host! https://isovector.github.io/erdos/