#12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): According to current practice of making inaccessible code an error, I think the new behavior is more correct than the old one. I think the fix for this is #11066. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12466#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): goldfire, are you saying this code should emit a warning? If so, what can be done to fix the code? FWIW, this bug also prevents the [https://github.com/ekmett/constraints/tree/1649e382b8dffe5e2694d0959caeba65e... constraints] library from building with GHC HEAD, although the bug appears in a slightly different form. Here's a stripped-down example that compiles with GHC 8.0.1, but not GHC HEAD: {{{#!hs {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} module ConstraintsBug where import GHC.TypeLits (Nat) import Unsafe.Coerce (unsafeCoerce) data Dict a where Dict :: a => Dict a newtype a :- b = Sub (a => Dict b) axiom :: forall a b. Dict (a ~ b) axiom = unsafeCoerce (Dict :: Dict (a ~ a)) type Divides n m = n ~ Gcd n m type family Gcd :: Nat -> Nat -> Nat where dividesGcd :: forall a b c. (Divides a b, Divides a c) :- Divides a (Gcd b c) dividesGcd = Sub axiom }}} {{{ $ /opt/ghc/head/bin/ghc ConstraintsBug.hs [1 of 1] Compiling ConstraintsBug ( ConstraintsBug.hs, ConstraintsBug.o ) ConstraintsBug.hs:26:14: error: • Couldn't match type ‘a’ with ‘Gcd a b’ ‘a’ is a rigid type variable bound by the type signature for: dividesGcd :: forall (a :: Nat) (b :: Nat) (c :: Nat). (Divides a b, Divides a c) :- Divides a (Gcd b c) at ConstraintsBug.hs:25:1-77 Inaccessible code in a type expected by the context: (Divides a b, Divides a c) => Dict a ~ Gcd a (Gcd b c) • In the first argument of ‘Sub’, namely ‘axiom’ In the expression: Sub axiom In an equation for ‘dividesGcd’: dividesGcd = Sub axiom • Relevant bindings include dividesGcd :: (Divides a b, Divides a c) :- Divides a (Gcd b c) (bound at ConstraintsBug.hs:26:1) }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12466#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): To clarify, I think the `constraints` code is an occurrence of the same bug since 1. `dividesGcd`'s type signature has a context (`Divides a b`, which is the same as `a ~ Gcd a b`) in which GHC determines an equality is unattainable. 2. The body of `dividesGcd` doesn't use the context, since it's defined in terms of `axiom` (a.k.a. `unsafeCoerce`). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12466#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I think comment:4 is unrelated. (But let's not lose the fact that there is a terrible pretty-printing bug there, without parentheses around the equality argument to `Dict`.) The commit in comment:7 is all about instances, and comment:4 is unrelated to instances. Yes, I think the original code should produce a warning. To suppress the warning, the user should include an implementation of `foo`, so that the generic-default implementation (which has the wrong type) is not used. But if inaccessible code is an error, then the original code should produce an error, just as it is now. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12466#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): As described in [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts... #class-default-signatures the manual], a generic-default type signature (that is, one using the `default` keyword in a class definition) is ''more specific'' than the "normal" type signature for a class method. When no implementation is given for a method in an instance declaration, the default implementation is typechecked against the generic-default type signature. In the code in the Description, this typecheck fails. On the other hand, if we provide an implementation for `foo`, the generic- default signature is not consulted in the instance declaration, and so there is no problem. When you add an `InstanceSigs` signature, then you're just writing a fresh signature that fails to typecheck. Your new signature is utterly unrelated to the generic-default signature. Does this help to clarify? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12466#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): OK, I think I've got a hunch why this code is failing all of a sudden starting with GHC HEAD. As I mentioned earlier, this code was typechecking just fine up until d2958bd08a049b61941f078e51809c7e63bc3354. You can see what code ghc is filling in with `-ddump-deriv`: {{{ $ /opt/ghc/head/bin/ghc Bug.hs -ddump-deriv [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ==================== Filling in method body ==================== Bug.Foo [GHC.Types.Char] Bug.foo = Bug.$dmfoo @GHC.Types.Char }}} If I try to implement something like `$dmfoo` manually, I can get the same error: {{{#!hs {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeFamilies #-} module Bug where class Foo a where foo :: (a ~ Int => Int) -> a -> a foo = fooDefault fooDefault :: (a ~ Int => Int) -> a -> a fooDefault _ a2 = a2 instance Foo Char where foo = fooDefault @Char }}} {{{ $ /opt/ghc/head/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:14:9: error: • Couldn't match type ‘Char’ with ‘Int’ Inaccessible code in a type expected by the context: Char ~ Int => Int • In the expression: fooDefault @Char In an equation for ‘foo’: foo = fooDefault @Char In the instance declaration for ‘Foo Char’ }}} So it's apparent that this behavior is different from before. Unfortunately, `-ddump-deriv` doesn't output this defaulting information on GHC 8.0.1 and earlier, so all we have to work with is `-ddump-simpl`. Compiling the original program with `-ddump-simpl` on GHC 8.0.1 yields: {{{ -- RHS size: {terms: 3, types: 7, coercions: 0} $cfoo_rCm :: ((Char :: *) ~ (Int :: *) => Int) -> Char -> Char [GblId, Arity=2, Caf=NoCafRefs, Str=DmdType] $cfoo_rCm = \ _ [Occ=Dead] (a2_aBf :: Char) -> a2_aBf -- RHS size: {terms: 1, types: 0, coercions: 3} Bug.$fFooChar [InlPrag=INLINE (sat-args=0)] :: Foo Char [GblId[DFunId(nt)], Arity=2, Caf=NoCafRefs, Str=DmdType] Bug.$fFooChar = $cfoo_rCm `cast` (Sym (Bug.N:Foo[0] <Char>_N) :: ((((Char :: *) ~ (Int :: *) => Int) -> Char -> Char) :: *) ~R# (Foo Char :: Constraint)) }}} I'm not sure if I'm reading that correctly, but I //think// that instead of defining `$cfoo_rCm` in terms of `$dmfoo`, GHC is inlining the definition of `$dmfoo` directly into `$cfoo` (which has so far accounted for the difference between a succesfully typechecked program and one that fails). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12466#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Oh gosh -- I've clearly been very confused. The original example makes sense to me only with a generic-default signature, so I assumed there was one. I've been thus babbling nonsense. Sorry, all! I have no idea why including the method implementation works. I don't think it should. But I still say the original code should be rejected for the same reasons I've already articulated. If inaccessible code were to become a warning, then the way to fix the warning is not to write the instance. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12466#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): So am I correct in guessing that this causes us to fail for the `Conjoined` class in `lens`? I've stripped it down removing the superclasses here: {{{#!hs class Conjoined p where conjoined :: ((p ~ (->)) => q (a -> b) r) -> q (p a b) r -> q (p a b) r conjoined _ r = r }}} (This is just a noisier version of `Foo`.) This is a rather big huge of the optimization story in `lens`, as we use it to avoid fiddling around with updating indices when the user isn't using them. This can make a 100x difference in performance for user code, so it isn't a trivial thing to throw away. If this suddenly isn't legal any more I'm really not sure what the heck we're going to do. That said, I don't see how that statement is illegal. `conjoined` takes two argument, one says _if_ you can tell me that p is (->) i'll give you a thing. The other is unconditionally usable. Once you learn p isn't `(->)` you simply can't use the first argument, as you could never satisfy its precondition. It isn't an error on the behalf of the signature of `conjoined`. It seems something is hinky in the way we're judging who has incurred an obligation here and when. We seem to be being far too eager to discharge an obligation we have no reason to even look at. Until something tries to use the first argument, why are we even doing anything with its constraints at all? The constraint being unsatisfiable in this limited situation is very much the point of the expression in the first place. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12466#comment:16 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Replying to [comment:16 ekmett]:

So am I correct in guessing that this causes us to fail for the `Conjoined` class in `lens`?

Yes this is where the example was reduced from.;

This is a rather big huge of the optimization story in `lens`, as we use

it to avoid fiddling around with updating indices when the user isn't using them. This can make a 100x difference in performance for user code, so it isn't a trivial thing to throw away. If this suddenly isn't legal any more I'm really not sure what the heck we're going to do. It seems that removing the constraint would preserve existing performance gains? Is the constraint used for something more than ensuring that only `p ~ (->)` can use the first argument and all other instances must use the default method? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12466#comment:18 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): @mpickering: Without the constraint none of the code that actually uses this combinator works at all. Those use sites exploit that extra bit of knowledge passed to the first argument by `instance Conjoined (->)` which knows `p ~ (->)` and therefore can use the first argument. The typical workflow is to do something like {{{#!hs traversed :: Traversable f => IndexedTraversal Int (f a) (f b) a b traversed = conjoined traverse (indexing traverse) }}} `traverse` requires its argument to be a function. `indexing traverse` isn't so picky and works for more choices of `p`. Now using that if you use `traversed` as a simple `Traversal` it'll pick the fast `traverse` path, but if you need access to the numerical indices we put on each member, and use a combinator like `itoListOf` or (`^@..`), then it'll pay the price of computing indices in an extra bit of state. This is equivalent to traversing the original `Traversable` container with `Compose (State Int) f` and bumping the counter after visiting each member, rather than just using your original functor `f`. This is much much slower. `traversed` and `indexing traverse` should be indistinguishable for users, except for the fact that the former is much much faster for the common case. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12466#comment:20 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Currently {{{ foo :: (Char ~ Int => Int) -> a -> a foo _ a2 = a2 }}} gives a similar message. Is that reasonable? The argument to `foo` can't be called. Instance decls are a bit different because you can change the type signature. Eg here is a simpler example {{{ class C a where foo :: (a~Int) => a -> a instance C Bool where foo = undefined }}} The instance decl is rejected, by both GHC 7.10 and HEAD. But of course there's nothing you can do about it. `foo` can't be called, but it needs something for the method `foo`. (It works when you leave out the definition of `foo` altogether, but I think only by accident.) What we need is NOT to complain about inconsistent 'givens' when typechecking instance methods. And certainly not to fail. Would that serve? It would sadly mean that inaccessible code somewhere deep in the body of an instance method wouldn't be reported, but maybe that's a lesser evil. I have not followed all this stuff about `Conjoined`. Is it all the same question? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12466#comment:22 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): That said, I certainly wouldn't complain if both of those things started type checking. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12466#comment:24 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I agree with your reasoning, but it's quite painful to implement the positive/negative distinction (given the way the constraint solver works). Anything is possible, but this all seems a bit exotic, so I'm inclined to look for a simple solution. I think it would be simple to: * Not complain about inaccessible code in instance methods Would that do? Currently GHC tries to do co/contra checking for subsumption checking. If we just used equality on the LHS of arrow, I think the negative/positive problem would disappear. Which is an intesting strike in favour of that approach. That would mean that this would fail: {{{ f :: (Int -> Int) -> Int g :: (forall a. a-> a) -> Int g = f }}} On the other hand, with the same signatures {{{ g x = f x }}} would succeed. The current co/contra subsumption is clever, but tricky... eg every foray into impredicative polymorphism gives up on it. Maybe we should give up on it now. Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12466#comment:26 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

I agree with your reasoning, but it's quite painful to implement the

#12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:26 simonpj]: positive/negative distinction (given the way the constraint solver works). Anything is possible, but this all seems a bit exotic, so I'm inclined to look for a simple solution.

I think it would be simple to:

* Not complain about inaccessible code in instance methods

Would that do?

That doesn't seem likely to solve the problem in general, and leads to an odd inconsistency. Unfortunately, I don't know enough about type checking to understand the problem with the positive/negative approach. If you can't make that work, I would personally prefer dialing back the inaccessible code error to a warning and being stingier about emitting it. Having to manually defer GHC's checking using `Dict` and such always struck me as unnatural and potentially fragile. If I state ex falso, I'm usually doing it on purpose. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12466#comment:30 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): @Iceland_jack: That should complain. The only way for it to become solvable is for the user to supply an orphan instance. We could never supply any errors for unsatisfied instances if that worked. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12466#comment:32 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I propose (comment:31) to report an error for a Given insoluble (e.g. `Int ~ Bool`) only if * there is an enclosing pattern match * that binds some equalities Otherwise silently ignore Given insolubles. That will resolve all the complaints here, I think. It's possible that we should warn; but it'd have to be not in `-Wall` because in some cases (like the instance one above) you can't "fix" the program to avoid the warning. So for now I'm inclined just to silently ignore. OK? Patch in preparation. Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12466#comment:34 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj):

Can you give an example or two of code that will still produce an error?

Yes indeed: see comment:31. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12466#comment:36 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Plus this {{{ commit 5eeabe250a1de456f70af07bd3f507a32cb8e10e Author: Simon Peyton Jones Date: Mon Sep 12 22:21:15 2016 +0100 Test wibbles for commit 03541cba I must have failed to validate properly, sorry. These testsuite wibbles belong with commit 03541cbae50f0d1cdf99120ab88698f29a278159 Author: Simon Peyton Jones Date: Fri Sep 9 17:42:42 2016 +0100 Be less picky about reporing inaccessible code testsuite/tests/typecheck/should_fail/FDsFromGivens.hs | 5 ++++- testsuite/tests/typecheck/should_fail/FDsFromGivens.stderr | 4 ++++ testsuite/tests/typecheck/should_fail/T10715.hs | 4 +++- testsuite/tests/typecheck/should_fail/T10715.stderr | 4 ++++ testsuite/tests/typecheck/should_fail/T8392a.hs | 2 ++ testsuite/tests/typecheck/should_fail/T8392a.stderr | 4 ++++ 6 files changed, 21 insertions(+), 2 deletions(-) }}} This should, I hope, unglue the log-jam of #12220 and #12533. Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12466#comment:38 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T12466, | T12466a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.0.2 Comment: comment:37 merged to `ghc-8.0` as 0e4e03a2a810ffa8ae16815d2ce4aad11d4b1065. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12466#comment:40 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler