[GHC] #15646: ghci takes super long time to find the type of large fractional number
GHC
ghc-devs at haskell.org
Sat Dec 1 15:36:53 UTC 2018
#15646: ghci takes super long time to find the type of large fractional number
-------------------------------------+-------------------------------------
Reporter: Johannkokos | Owner:
| JulianLeviston
Type: bug | Status: new
Priority: normal | Milestone: 8.6.1
Component: GHCi | Version: 8.4.3
Resolution: | Keywords: newcomer
Operating System: Unknown/Multiple | Architecture:
Type of failure: Compile-time | Unknown/Multiple
performance bug | Test Case:
Blocked By: | Blocking:
Related Tickets: #5692 | Differential Rev(s):
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by JulianLeviston):
Ok, so I compiled and added in the line:
{{{pprTrace "..." (text "litI:" <+> ppr litI <+> text "litE:" <+> ppr
litE) $ pure ()}}}
... however that's in `MatchLit`, so doesn't get executed when
typechecking, only when evaluating. Makes sense because if I typecheck, I
still get the slow behaviour, but if I evaluate, I get that error (coz I
still haven't updated the location of `mkRational` yet).
So, this also seems correct, given I have made zero changes in the
typechecker so far. So I'm looking in to that.
I hope I'm on the right track. I ran it with `./inplace/bin/ghc-stage2 -e
":t 1e289" -ddump-parsed-ast` and it responded with something that ended
with:
{{{
==================== Parser AST ====================
(Just
({ <interactive>:1:1-5 }
(BodyStmt
(NoExt)
({ <interactive>:1:1-5 }
(HsOverLit
(NoExt)
(OverLit
(NoExt)
(HsFractional
(FL
(SourceText
"1e289")
(False)
(1)
(289)
(Base10)))
(HsLit
(NoExt)
(HsString
(SourceText
"noExpr")
{FastString: "noExpr"})))))
(SyntaxExpr
(HsLit
(NoExt)
(HsString
(NoSourceText)
{FastString: "noSyntaxExpr"}))
[]
(WpHole))
(SyntaxExpr
(HsLit
(NoExt)
(HsString
(NoSourceText)
{FastString: "noSyntaxExpr"}))
[]
(WpHole)))))
}}}
And, seeing `HsOverLit` in this output, and looking at `tcExpr` in
`compiler/typecheck/TcExpr.hs`, it seems to match the `HsOverLit` clause,
which calls `newOverloadedLit` from `compiler/typechecker/Inst.hs`, which
I'm not 100% sure, but it seems to be *not* matching on a short cut
clause, and so applying `newNonTrivialOverloadedLit`.
I'll take another pass at understanding it all again tomorrow.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15646#comment:62>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list