Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
GHC
GHC
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 4,320
    • Issues 4,320
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge Requests 355
    • Merge Requests 355
  • Requirements
    • Requirements
    • List
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Security & Compliance
    • Security & Compliance
    • Dependency List
    • License Compliance
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Code Review
    • Insights
    • Issue
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • Glasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #17718

Closed
Open
Opened Jan 20, 2020 by Richard Eisenberg@raeDeveloper

Refactor solver to leave breadcrumbs

Today, the solver works hard to find how givens can imply wanteds. If it fails, it exits with unsolved wanteds. These wanteds are then scrutinized carefully in the TcErrors module in order to produce nice, user-readable error messages. However, the current design means that TcErrors needs to do much work trying to analyze the tea leaves that the solver has left behind. That is, it must reconstruct why a constraint was failed to be solved. This involves some duplicate code and duplicate work (such as looking in instance environments).

Instead, we can imagine a structure, stored within a CtLoc, that records the solver's movements, including movements it failed to make (such as "tried to unify, but hit an occurs-check failure"). This structure could then be consumed in TcErrors. Effectively, this means that the solver could more directly communicate with users and explain its reasoning. We might also imagine a future where users can query GHC for information about even type-correct programs.

This ticket is to track this refactoring opportunity.

Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: ghc/ghc#17718