#14969: panic on incorrect syntax -------------------------------------+------------------------------------- Reporter: johnleo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sighingnow): This panic is caused by the bad `TcLevel` when checking the `TcLevel` invariants, maybe related to ticket:14884. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14969#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#14969: panic on incorrect syntax -------------------------------------+------------------------------------- Reporter: johnleo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): To be clear, in comment:2, do you mean that it doesn't build with a standard 8.4.1 bindist, or with 8.4.1 built from source with `ASSERT`ions enabled? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14969#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#14969: panic on incorrect syntax -------------------------------------+------------------------------------- Reporter: johnleo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"07abff7192dcc9ce667d3c5cdb3f34ca8c87f2fb/ghc" 07abff71/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="07abff7192dcc9ce667d3c5cdb3f34ca8c87f2fb" Test #14884, #14969 These were fixed by faec8d358985e5d0bf363bd96f23fe76c9e281f7 test cases: typecheck/should_fail/T14884 ghci/scripts/T14969 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14969#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#14969: panic on incorrect syntax -------------------------------------+------------------------------------- Reporter: johnleo | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/scripts/T14969 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tritlo): Yes, I've hit this recently during my work on improving the implementation of the suggestions, and now I've become more familiar with how to properly set the tcLevel. I'll submit the patch soon (hopefully), after I manage to iron out a few more kinks. Thanks for the nab goldfire, hopefully there won't be any more to nab :) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14969#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#14969: panic on incorrect syntax -------------------------------------+------------------------------------- Reporter: johnleo | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: fixed | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/scripts/T14969 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by johnleo): The latest behavior using 8.5.20180413 on my Mac is that if I type `3 _ 4` or `3 _` GHCI now hangs, which I do not consider an improvement over the panic. I have to type `^C` to break. If I type something like `_` or `_ 3` I get a `Found hole` message as expected. Reopening, but if it makes more sense to file a new bug instead I can do that. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14969#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#14969: Underconstrained typed holes are non-performant -------------------------------------+------------------------------------- Reporter: johnleo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | ghci/scripts/T14969 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * failure: None/Unknown => Compile-time performance bug Comment: Note that it doesn't loop infinitely, but rather takes a very long time to compute: {{{ $ time ghc/inplace/bin/ghc-stage2 -XFlexibleContexts -e "3 _ 4" <interactive>:0:1: error: • Could not deduce (Num t1) from the context: (Num t, Num (t2 -> t -> t3)) bound by the inferred type for ‘it’: forall t t2 t3. (Num t, Num (t2 -> t -> t3)) => t3 at <interactive>:0:1-5 The type variable ‘t1’ is ambiguous • In the ambiguity check for the inferred type for ‘it’ To defer the ambiguity check to use sites, enable AllowAmbiguousTypes When checking the inferred type it :: forall t1 t2 t3. (Num t1, Num (t2 -> t1 -> t3)) => t3 real 0m32.219s user 0m32.176s sys 0m0.084s }}} In other words, this is the same problem observed in https://ghc.haskell.org/trac/ghc/ticket/10946#comment:9. This is good home for this particular bug. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14969#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#14969: Underconstrained typed holes are non-performant -------------------------------------+------------------------------------- Reporter: johnleo | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | ghci/scripts/T14969 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Tritlo): * status: new => patch Comment: A fix for this is included in https://phabricator.haskell.org/D4444, where we change the default sorting algorithm to one based on comparing sizes of types rather than subsumption, which is much faster and gives comparable results. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14969#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#14969: Underconstrained typed holes are non-performant -------------------------------------+------------------------------------- Reporter: johnleo | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | ghci/scripts/T14969 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4444 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): It would be good to get this done. e.g #13499 is another example of the typed-hole perf problem. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14969#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#14969: Underconstrained typed holes are non-performant -------------------------------------+------------------------------------- Reporter: johnleo | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | ghci/scripts/T14969 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4444 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"e0b44e2eccd4053852b6c4c3de75a714301ec080/ghc" e0b44e2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e0b44e2eccd4053852b6c4c3de75a714301ec080" Improved Valid Hole Fits I've changed the name from `Valid substitutions` to `Valid hole fits`, since "substitution" already has a well defined meaning within the theory. As part of this change, the flags and output is reanamed, with substitution turning into hole-fit in most cases. "hole fit" was already used internally in the code, it's clear and shouldn't cause any confusion. In this update, I've also reworked how we manage side-effects in the hole we are considering. This allows us to consider local bindings such as where clauses and arguments to functions, suggesting e.g. `a` for `head (x:xs) where head :: [a] -> a`. It also allows us to find suggestions such as `maximum` for holes of type `Ord a => a -> [a]`, and `max` when looking for a match for the hole in `g = foldl1 _`, where `g :: Ord a => [a] -> a`. We also show much improved output for refinement hole fits, and fixes #14990. We now show the correct type of the function, but we also now show what the arguments to the function should be e.g. `foldl1 (_ :: Integer -> Integer -> Integer)` when looking for `[Integer] -> Integer`. I've moved the bulk of the code from `TcErrors.hs` to a new file, `TcHoleErrors.hs`, since it was getting too big to not live on it's own. This addresses the considerations raised in #14969, and takes proper care to set the `tcLevel` of the variables to the right level before passing it to the simplifier. We now also zonk the suggestions properly, which improves the output of the refinement hole fits considerably. This also filters out suggestions from the `GHC.Err` module, since even though `error` and `undefined` are indeed valid hole fits, they are "trivial", and almost never useful to the user. We now find the hole fits using the proper manner, namely by solving nested implications. This entails that the givens are passed along using the implications the hole was nested in, which in turn should mean that there will be fewer weird bugs in the typed holes. I've also added a new sorting method (as suggested by SPJ) and sort by the size of the types needed to turn the hole fits into the type of the hole. This gives a reasonable approximation to relevance, and is much faster than the subsumption check. I've also added a flag to toggle whether to use this new sorting algorithm (as is done by default) or the subsumption algorithm. This fixes #14969 I've also added documentation for these new flags and update the documentation according to the new output. Reviewers: bgamari, goldfire Reviewed By: bgamari Subscribers: simonpj, rwbarton, thomie, carter GHC Trac Issues: #14969, #14990, #10946 Differential Revision: https://phabricator.haskell.org/D4444 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14969#comment:17 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler