#10946: Typed hole inside typed Template Haskell bracket causes panic -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by Jan Stolarek ): In [changeset:"f64f7c36ef9395da1cc7b686aaf1b019204cd0fc/ghc" f64f7c3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f64f7c36ef9395da1cc7b686aaf1b019204cd0fc" Tests for #10945 and #10946 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10946#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10946: Typed hole inside typed Template Haskell bracket causes panic -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: th/T10946 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by Jan Stolarek ): In [changeset:"75492e7467ff962f2f2e29e5c8b2c588c94ae8a7/ghc" 75492e7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="75492e7467ff962f2f2e29e5c8b2c588c94ae8a7" Add typed holes support in Template Haskell. Fixes #10267. Typed holes in typed Template Haskell currently don't work. See #10945 and #10946. }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10946#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10946: Typed hole inside typed Template Haskell bracket causes panic -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: th/T10946 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"c6ac1e5f25e980c69e36581666210749811ee1c6/ghc" c6ac1e5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c6ac1e5f25e980c69e36581666210749811ee1c6" users_guide: TH now partially supports typed holes As requested in #10267. However we still lack support in typed splices. See #10945 and #10946. }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10946#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10946: Typed hole inside typed Template Haskell bracket causes panic -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: th/T10946 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by elliottt): The problem seems to be that the quoted expression {{{[|| _x ||]}}} will introduce a hole constraint of the form {{{ _x :: a }}} when spliced, but that the error will be reported outside of the implication introduced by the signature. When checking the following program: {{{ m :: a m = _x }}} {{{simplifyTop}}} will report that it's found an unsolved wanted constraint of the form {{{ forall (a :: *). () => _x :: a }}}. However, when checking the original program, {{{simplifyTop}}} is called from a different path ({{{tcTopSpliceExpr}}}), and reports the wanted constraint as being of the form {{{ _x :: a }}}. As it lacks the context of the binding for {{{a}}}, it falls through to the base case of {{{getSkolemInfo}}}, which causes the panic. At this point, I'm not sure what the right path forward is. Should {{{tcTopSpliceExpr}}} be using {{{simplifyTop}}}, or is there just some additional context needed to be setup before that call? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10946#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10946: Typed hole inside typed Template Haskell bracket causes panic -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: th/T10946 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): A correction to comment:9—it doesn't loop infinitely, but it does take a full five minutes to complete that test case on my machine. Still, that's quite severe—we should find out what caused this to regress. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10946#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10946: Typed hole inside typed Template Haskell bracket causes panic -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: th/T10946 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tritlo): RyanGlScott: It seems like what's happening is that since the variable has no constraints on it at all, then it's matching everything in scope (including everything in scope in TemplateHaskell), and then doing the subsumption graph sorting on that, which takes a very long time. I'll give it some thought, but it seems like the right way to go would be to not try to find valid substitutions for this too general case. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10946#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10946: Typed hole inside typed Template Haskell bracket causes panic -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: th/T10946 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tritlo): On the other hand, this is the right behavior, since a type variable with no constraints on it could be substituted with any identifier of any type. So the time it is taking is really due to the bug giving the hole a too general type. simonpj: Yes, that's a good point. When we don't try to sort the substitution, that is indeed what happens. We should set some limit for how many substitutions we attempt to sort by the subsumption graph method, and default to some other method otherwise (like e.g. sorting by module). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10946#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10946: Typed hole inside typed Template Haskell bracket causes panic -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: th/T10946 Blocked By: | Blocking: Related Tickets: #14969 | Differential Rev(s): 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/10946#comment:16 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10946: Typed hole inside typed Template Haskell bracket causes panic -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: th/T10946 Blocked By: | Blocking: Related Tickets: #14969 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tritlo): No, the initial error still occurs, but the hang introduced by the valid hole fits should no longer be a problem. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10946#comment:18 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler