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,248
    • Issues 4,248
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge Requests 391
    • Merge Requests 391
  • 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
  • #7855

Closed
Open
Opened Apr 22, 2013 by Edward Z. Yang@ezyangDeveloper

Use optimizer for more information about incomplete pattern matches

This mail gave me an idea that was too cute not to write down (though I don't expect it to be implemented any time soon), http://www.haskell.org/pipermail/haskell-cafe/2013-April/107775.html

The observation is that the typechecking phase is not necessarily the best point in time to check for pattern coverage exhaustiveness: if we tentatively stub in a default case with an error, and after optimization passes, we find that this case has been eliminated, then in fact there was no pattern coverage incompleteness. So, the strategy would be to defer reporting certain coverage failures until we can do actually check if there are any problems later. Obviously if no predicates or view patterns (or similar things) are involved, then there is no point in attempting to defer it, but otherwise this could help reduce warnings in code that make heavy use of these features.

Trac metadata
Trac field Value
Version 7.7
Type FeatureRequest
TypeOfFailure OtherFailure
Priority normal
Resolution Unresolved
Component Compiler (Type checker)
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: ghc/ghc#7855