#11573: Inferred CallStacks expose implicit parameter -------------------------------------+------------------------------------- Reporter: bgamari | Owner: gridaphobe Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | 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: | -------------------------------------+------------------------------------- Changes (by gridaphobe): * owner: => gridaphobe * priority: high => normal Comment: Just copying my response from ghc-devs :) ---- The inferred CallStack is not a bug, it was added to fix #10845. The problem is that in a function like foo :: HasCallStack => ... foo x = let bar y = undefined in bar x we need to infer a CallStack for bar (due to the structure of the constraint solver) in order to link foo's CallStack to undefined. What '''is''' a bug is that GHC shows the implicit parameter in the inferred signature. We don't expose those anymore in the CallStack API, instead we use a type synonym HasCallStack. GHC should infer HasCallStack constraints instead. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11573#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#11573: Inferred CallStacks expose implicit parameter -------------------------------------+------------------------------------- Reporter: bgamari | Owner: gridaphobe Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1911 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I think that the inferred call stack is also a bug! I believe that for top-level bindings that lack a signature, we are not inferring a `HasCallStack` constraint: {{{ foo (x:xs) = x foo [] = error "foo" }}} Here we infer `foo :: [a] -> a`, without a `HasCallStack` constraint. Correct? Alas the [http://downloads.haskell.org/~ghc/master/users- guide/glasgow_exts.html#hascallstack user manual section] does not say this. It should. Also, I believe that [wiki:ExplicitCallStack/ImplicitLocations this is the relevant wiki page] (correct?). Yet it is full of "proposals", and this particular point is an "open choice" under "Discussion". It would be great it * The user manual was updated to be a more complete and accurate spec * It referred to the wiki page * The wiki page was updated to reflect reality Finally, back to GHCi. I think that a `let` binding in GHCi should have the same status as a top-level binding in a module; and hence should not get an automatically-inferred `HasCallStack` constraint. So there are four things to fix: * Using the `HasCallStack` synonym * Treating GHCi `let` bindings as top level * Update the user manual * Update the wiki page Eric, if you are willing it would be great if you could look into this. It's such a valuable feature. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11573#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#11573: Inferred CallStacks expose implicit parameter -------------------------------------+------------------------------------- Reporter: bgamari | Owner: gridaphobe Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11383 | Differential Rev(s): Phab:D1911, Wiki Page: | Phab:D1912 -------------------------------------+------------------------------------- Changes (by gridaphobe): * differential: Phab:D1911 => Phab:D1911, Phab:D1912 * related: => #11383 Comment:

Here we infer foo :: [a] -> a, without a HasCallStack constraint. Correct?

That's incorrect as of the reworked solver, but as you've seen D1912 is going to put the original "don't infer top-level call-stacks" behavior back in place.

- The user manual was updated to be a more complete and accurate spec - It referred to the wiki page

Sure, I didn't realize we linked to the wiki from the manual.

- The wiki page was updated to reflect reality

I've been treating the wiki page as append-only, so I'll add a section that explains the final design.

I think that a let binding in GHCi should have the same status as a top- level binding in a module

I agree, and D1912 does treat them as top-level. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11573#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#11573: Inferred CallStacks expose implicit parameter -------------------------------------+------------------------------------- Reporter: bgamari | Owner: gridaphobe Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11383 | Differential Rev(s): Phab:D1911, Wiki Page: | Phab:D1912 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"7407a66d5bd29aa011f5a4228c6e2b2f7f8ad3f8/ghc" 7407a66/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7407a66d5bd29aa011f5a4228c6e2b2f7f8ad3f8" Don't infer CallStacks We originally wanted CallStacks to be opt-in, but dealing with let binders complicated things, forcing us to infer CallStacks. It turns out that the inference is actually unnecessary though, we can let the wanted CallStacks bubble up to the outer context by refusing to quantify over them. Eventually they'll be solved from a given CallStack or defaulted to the empty CallStack if they reach the top. So this patch prevents GHC from quantifying over CallStacks, getting us back to the original plan. There's a small ugliness to do with PartialTypeSignatures, if the partial theta contains a CallStack constraint, we *do* want to quantify over the CallStack; the user asked us to! Note that this means that foo :: _ => CallStack foo = getCallStack callStack will be an *empty* CallStack, since we won't infer a CallStack for the hole in the theta. I think this is the right move though, since we want CallStacks to be opt-in. One can always write foo :: (HasCallStack, _) => CallStack foo = getCallStack callStack to get the CallStack and still have GHC infer the rest of the theta. Test Plan: ./validate Reviewers: goldfire, simonpj, austin, hvr, bgamari Reviewed By: simonpj, bgamari Subscribers: bitemyapp, thomie Projects: #ghc Differential Revision: https://phabricator.haskell.org/D1912 GHC Trac Issues: #11573 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11573#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#11573: Inferred CallStacks expose implicit parameter -------------------------------------+------------------------------------- Reporter: bgamari | Owner: gridaphobe Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11383 | Differential Rev(s): Phab:D1911, Wiki Page: | Phab:D1912 -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 773e81ba563ae2839f0d61a6401e318e4bacd036. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11573#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler