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,260
    • Issues 4,260
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge Requests 398
    • Merge Requests 398
  • 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
  • #13154

Closed
Open
Opened Jan 20, 2017 by Ryan Scott@RyanGlScottMaintainer

Standalone-derived anyclass instances aren't as permissive as empty instances

Note that these are accepted:

class Foo (a :: TYPE ('TupleRep '[]))
instance Foo (a :: TYPE ('TupleRep '[]))
instance Foo (##)

But if you try to write these same instances using DeriveAnyClass and StandaloneDeriving, they'll be rejected for no good reason:

deriving instance Foo (a :: TYPE ('TupleRep '[]))

{-
    • Can't make a derived instance of ‘Foo a’:
        The last argument of the instance must be a data or newtype application
-}

deriving instance Foo (##)

{-
    • Can't make a derived instance of ‘Foo (# #)’:
        The last argument of the instance cannot be an unboxed tuple
-}

The latter error is a vestige of #12512 (closed), and should be easy enough to rectify. The former error is a bit tricker to fix, since much of the code in TcDeriv/TcDerivInfer assumes that the type to which the class is applied to in the instead head is a datatype or newtype TyCon. It's apparent that this doesn't hold true in the presence of DeriveAnyClass, however, so that code should be refactored to reflect this.

For practical reasons, however, it might be best to wait until after #12144 (closed) is fixed to tackle this one, since that splits out some logic in TcDerivInfer for DeriveAnyClass so as to make it no longer rely on the aforementioned TyCon invariant.

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