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 <[email protected]> On Behalf Of Sandy Maguire Sent: 18 August 2019 01:28 To: [email protected] 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/
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
