Repository navigation
Qualify types as necessary in hints in warnings/errors #1647
Description
Activity
Yes! Also, if something is imported from a qualified module we should include the qualification in the error: currently in SlamData we've had trouble errors like "Could not unify type Query with Query", as there are two query algebras imported qualified from different modules.
This isn't super easy to do right now though, we'll have to introduce something so that after desugaring the identifier contains the pre-desugared value too.
Reacted by Liam McDermott and Sam RakerRight now, we don't pretty-print module names, but another option would be to strip module names before putting a type/expression into an
ErrorMessagevalue, whenever a name is in scope, and to pretty-print module names if they appear in aQualified something.We could keep the pre-desugared thing around, like for qualified imports, but it's probably fine to just show either no module (default if in scope) or the whole module (if not), surely?
That works too, but since everything gets fully qualified in name desugaring it's still a bit of work to figure out whether it's in scope or not (it means checking things that arrive via re-export too, not just considering the list of imports directly).
It'd be nice to show the user the code they actually wrote in error messages too, where possible! 😄
@gary I've put this in 0.9, feel free to move it if you think it belongs elsewhere, I'm just doing some bookkeeping.
0.9 sounds good, now the end of 0.8 is in sight I'd like to get it wrapped up and out the door 😄
- added a commit that references this issue
on Apr 12, 2017 I'd like to solve this by using a pretty printer that supports annotations, and annotate all names with their respective qualification. That way editors or other interactive environments could show the module of the given identifier on hover and we can decide to print the qualification in the error message at the last step
Doc -> Text.Reacted by Liam Goodacre, Gabe Johnson, coot, Liam McDermott and Mark EibesThis bit me today. We have several modules in an application at work that use the same type name but are referenced qualified outside of the module. I changed the qualifier in one place but not another. The error was of little help.
I keep coming up against this when doing refactorings, it's super annoying to get
Could not unify type Query with Queryand it would be a huge help if they were just fully qualified if they have the same name.
For example, I have a module which has a toplevel function which returns a
Text.Parsing.Parsers.Pos.Positionwhich isn't annotated with a type. The hint that appears with the warning says the inferred type wasforall t11. t11 -> Position, however, if I write that verbatim, I get a type error "Unknown type Position".Could we make it so that it if the type isn't already in scope, it gets qualified? So it could print the inferred type as
Text.Parsing.Parsers.Pos.Positionin this case.