#11409: Cannot instantiate literals using TypeApplications -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11352 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Replying to [comment:4 adamgundry]:
See also #11352, which is about the same issue for the newfangled overloaded labels (and I guess overloaded string and rational literals should be treated similarly).
I experimented with something like Simon's suggestion for overloaded labels, and found that error messages got worse, because it was no longer
OK, so that makes it more worth thinking about. possible to give a `CtOrigin` that mentioned the overloaded label as the source. I don't understand why. * We continue to have a case in the type checker for integer literals, as now. * It elaborates the literal to `integerLit 3` with type `forall a. Num a => a` When we instantiate that type (which is delayed in the new `TypeApplication` world) we need a suitable `CtOrigin`. We get that using `exprCtOrigin` (see `TcExpr.tcApp`). It can produce a suitable origin for an integer literal, string -- or field label. So it seems ok to me. Worth a try? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11409#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler