Hi Jack, You're spot on here. And, looking through #9173, I wouldn't expect this to be an easy change, precisely for the reason you articulate here. You could change the TypeEqOrigin constructor of CtOrigin (in TcRnTypes.hs) to also carry the expression, except that sometimes even that will be hard. In unrelated work, I needed to do precisely this, and needed to use something like (Maybe (HsExpr TcId)).
In any case, this isn't newcomer material, I'm afraid. You're welcome to keep trying, but I think your energy is better spent elsewhere for a few bugs and then to return here with a little more experience working with GHC. If you want type-checker related bugs, you could always look through the first section of my pet page of such things: https://ghc.haskell.org/trac/ghc/wiki/Status/RAE-Tickets But even things listed there as "easy" mean that they may be easy for someone who knows GHC well, but not so much for a newcomer. Thanks for contributing! Richard On Aug 8, 2015, at 10:56 PM, Jack Bowman <[email protected]> wrote: > Hi all, > I'm new to the GHC codebase and am looking to contribute. I started trying to > implement https://ghc.haskell.org/trac/ghc/ticket/9173 , "better type error > messages". I'm having some difficulty and was hoping someone more experienced > could point me in the right direction. > Part of the proposed change is that the "inferred:" line lists both the > expression ("Just 5") and its type ("Maybe a0"). That's good because it's > more clear that way. Currently those are in different parts of the error > message. The function misMatchMsg (TcErrors.hs) creates the text "couldn't > match expected type...". The text "In the second argument of..." is created > by funAppCtxt (TcExpr.hs) during type checking. Bringing these together seems > tricky. When we're generating a message like "couldn't match expected > type..." I don't see how to access the expression text, like the "LHsExpr > Name"s available to funAppCtxt. Is there an easy way to get that? We have the > constraint and the two types, but I don't think those include this info. > It seems fundamental to the error messages that the context ("in the _ > argument..., in the expression ...") is built up as *text* while we do type > checking, which means it's hard to customize when building the final error > message. > Please let me know if I'm missing something. There's a lot of type checker > state that I might be misunderstanding. > Thanks,Jack > _______________________________________________ > ghc-devs mailing list > [email protected] > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
