[GHC] #14273: Typed holes' "valid substitutions" suggestions are oblivious to type class constraints

[GHC]

#14273: Typed holes' "valid substitutions" suggestions are oblivious to type class
constraints
-------------------------------------+-------------------------------------
        Reporter:  RyanGlScott       |                Owner:  Tritlo
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler (Type    |              Version:  8.3
  checker)                           |
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Poor/confusing    |  Unknown/Multiple
  error message                      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #9091             |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by Tritlo):

 And the plot thickens:

 if I add a module declaration, I get an additional error message, i.e.,
 when the code is the following:

 {{{
 module TestShow  where

 pleaseShow :: Show a => Bool -> a -> Maybe String
 pleaseShow False _ = Nothing
 pleaseShow True  a = Just (show _a)
 }}}

 I get the same error as before, but now with an additional message before
 the typed hole error message:
 {{{
 t4.hs:5:28: error:
     • Could not deduce (Show a0) arising from a use of ‘show’
       from the context: Show a
         bound by the type signature for:
                    pleaseShow :: forall a. Show a => Bool -> a -> Maybe
 String
         at t4.hs:3:1-49
       The type variable ‘a0’ is ambiguous
       These potential instances exist:
         instance (Show b, Show a) => Show (Either a b)
           -- Defined in ‘Data.Either’
         instance Show Ordering -- Defined in ‘GHC.Show’
         instance Show Integer -- Defined in ‘GHC.Show’
         ...plus 23 others
         ...plus 54 instances involving out-of-scope types
         (use -fprint-potential-instances to see them all)
     • In the first argument of ‘Just’, namely ‘(show _a)’
       In the expression: Just (show _a)
       In an equation for ‘pleaseShow’: pleaseShow True a = Just (show _a)
   |
 5 | pleaseShow True  a = Just (show _a)
   |                            ^^^^^^^
 }}}

 Which does tell you the constraint on the hole (if you connect the
 ambiguous type variable names yourself). I suspect I'll have to invoke the
 same mechanism, and then add the constraints derived with that mechanism
 and wrap the type with that as well.

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