Skip to content

Qualify types as necessary in hints in warnings/errors #1647

Description

@hdgarrood

For example, I have a module which has a toplevel function which returns a Text.Parsing.Parsers.Pos.Position which isn't annotated with a type. The hint that appears with the warning says the inferred type was forall 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.Position in this case.

Activity

  1. garyb commented on Nov 20, 2015

    @garyb
    Member

    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.

  2. self-assigned this
    on Nov 20, 2015
  3. paf31 commented on Nov 20, 2015

    @paf31
    Contributor

    Right now, we don't pretty-print module names, but another option would be to strip module names before putting a type/expression into an ErrorMessage value, whenever a name is in scope, and to pretty-print module names if they appear in a Qualified 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?

  4. garyb commented on Nov 20, 2015

    @garyb
    Member

    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! 😄

  5. added this to the 0.9.0 milestone on Nov 24, 2015
  6. paf31 commented on Nov 24, 2015

    @paf31
    Contributor

    @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.

  7. reopened this on Nov 24, 2015
  8. garyb commented on Nov 24, 2015

    @garyb
    Member

    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 😄

  9. modified the milestones: 0.9.0, 0.10.0 on Apr 10, 2016
  10. modified the milestones: 0.10.0, on Sep 17, 2016
  11. modified the milestones: 1.0, Approved on Oct 1, 2016
  12. added a commit that references this issue on Apr 12, 2017
    acaaf67
  13. kritzcreek commented on Jan 25, 2018

    @kritzcreek
    Member

    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.

  14. gabejohnson commented on Aug 19, 2019

    @gabejohnson

    This 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.

  15. shmish111 commented on Oct 28, 2020

    @shmish111

    I keep coming up against this when doing refactorings, it's super annoying to get Could not unify type Query with Query and it would be a huge help if they were just fully qualified if they have the same name.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions