[GHC] #12466: Typechecker regression: Inaccessible code in a type expected by the context

[GHC]

#12466: Typechecker regression: Inaccessible code in a type expected by the context
-------------------------------------+-------------------------------------
        Reporter:  RyanGlScott       |                Owner:
            Type:  bug               |               Status:  new
        Priority:  highest           |            Milestone:  8.0.2
       Component:  Compiler (Type    |              Version:  8.1
  checker)                           |
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  GHC rejects       |  Unknown/Multiple
  valid program                      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by mpickering):

 Replying to [comment:16 ekmett]:
 > So am I correct in guessing that this causes us to fail for the
 `Conjoined` class in `lens`?

 Yes this is where the example was reduced from.;

 >
 > This is a rather big huge of the optimization story in `lens`, as we use
 it to avoid fiddling around with updating indices when the user isn't
 using them. This can make a 100x difference in performance for user code,
 so it isn't a trivial thing to throw away. If this suddenly isn't legal
 any more I'm really not sure what the heck we're going to do.

 It seems that removing the constraint would preserve existing performance
 gains? Is the constraint used for something more than ensuring that only
 `p ~ (->)` can use the first argument and all other instances must use the
 default method?

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12466#comment:18>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler