October 2016 - ghc-tickets

[GHC] #12429: Pattern synonym parse error should recommend enabling extension
by GHC 02 Mar '17

02 Mar '17

#12429: Pattern synonym parse error should recommend enabling extension -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.3 Keywords: pattern | Operating System: Unknown/Multiple synonym error messages | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently, if you try to use pattern synonyms in a module without -XPatternSynonyms, you can get a very uninformative parse error. For example: {{{#!hs module X where import Data.Text (pattern Y) x = 3 }}} Yields, when compiled on GHC 7.10, {{{ test.hs:3:27: parse error on input "Y" }}} It would be helpful if in addition to the error, the message suggested to the user to enable the PatternSynonyms extension, as many other error messages already do. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12429> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #11179: Allow plugins to access "dead code"
by GHC 02 Mar '17

02 Mar '17

#11179: Allow plugins to access "dead code" -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC removes dead-bindings quite early in the compilation process, which makes perfect sense from a pure compilation point of view. But with user- plugins, some of the dead-bindings can be interesting: They might be properties or other code that instructs the plugin to do a certain action, even if the binding isn't otherwise used anywhere else or exported. (Think of embedded properties.) Here's a discussion about the issue, where SimonPJ asked for a ticket to be filed: [http://mail.haskell.org/pipermail/ghc- devs/2015-December/010708.html] It appears the desugarer removes some of the dead-code. One option could be to stop the desugarer from doing that, and leaving it to the later optimizer passes so plugins can still see all the bindings (if they run early enough), or require the user to put in an "KeepAlive" pragma on bindings that she cares about. While keeping all-dead code in the desugarer would be the simplest thing to do, requiring the user to put in a pragma isn't a terrible solution either. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11179> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #9729: GHCi accepts invalid programs when recompiling
by GHC 01 Mar '17

01 Mar '17

#9729: GHCi accepts invalid programs when recompiling -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: GHC Blocked By: | accepts invalid program Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Here's what's happening: Module A imports module B. Module B contains a function with constraints that are '''required''' to compile module B. If I load module A in GHCi, I can remove some (required) constraints on the function in module B and GHCi will successfully reload module B. My example uses the [https://hackage.haskell.org/package/syntactic syntactic] library. I attempted to recreate the situation I just described without syntactic, but I was unsuccessful. Module A.hs: {{{ #!haskell module A where import B import Data.Syntactic.Sugar.BindingT () main = print "hello" }}} Module B.hs: {{{ #!haskell {-# LANGUAGE GADTs, TypeOperators, FlexibleContexts #-} module B where import Data.Syntactic data Let x where Let :: Let (a :-> (a -> b) :-> Full b) share :: (Let :<: sup, sup ~ Domain b, sup ~ Domain a, Internal (a -> b) ~ (Internal a -> Internal b), -- remove me Syntactic a, Syntactic b, Syntactic (a -> b), SyntacticN (a -> (a -> b) -> b) (ASTF sup (Internal a) -> ASTF sup (Internal (a -> b)) -> ASTF sup (Internal b))) => a -> (a -> b) -> b share = sugarSym Let }}} Here's a terminal transcript: {{{ $ ghci A [1 of 2] Compiling B ( testsuite/B.hs, interpreted ) [2 of 2] Compiling A ( testsuite/A.hs, interpreted ) Ok, modules loaded: A, B. > (Now remove the constraint from B and save. This *should* break module B) > :r [1 of 2] Compiling B ( testsuite/B.hs, interpreted ) Ok, modules loaded: A, B. > :q $ ghci B [1 of 2] Compiling B ( testsuite/B.hs, interpreted ) testsuite/B.hs:21:9: Could not deduce (Internal (a -> b) ~ (Internal a -> Internal b)) }}} If I had to guess what's going on, it's that GHCi is remembering the instance that A imports from BindingT: {{{ instance (...) => Syntactic (a -> b) where type Internal (a -> b) = Internal a -> Internal b }}} This instance implies the constraint that module B needs, however it should never be visible to module B. GHCi seems to be ignoring that and using the instance to recompile module B. When compiling from scratch, module B is compiled first, so of course the instance (and therefore the constraint) are not visible. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9729> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12703: Expand Backpack's signature matching relation beyond definitional equality
by GHC 01 Mar '17

01 Mar '17

#12703: Expand Backpack's signature matching relation beyond definitional equality -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently, signature matching is done by strict definitional equality. This can be pretty inconvenient in some cases (it is also the only place in the Haskell language that we actually expose definitional equality): **Polymorphism.** This is the obvious one. If I have an implementing function that is more polymorphic than my signature, I have to manually monomorphize it. {{{ unit p where signature H where import Prelude (Int) data String length :: String -> Int unit q where module H(String, length) where -- from Prelude unit r where dependency p[H=q:H] }}} Gives {{{ <no location info>: error: Identifier ‘Data.Foldable.length’ has conflicting definitions in the module and its hsig file Main module: Data.Foldable.length :: Data.Foldable.Foldable t => forall a. t a -> GHC.Types.Int Hsig file: Data.Foldable.length :: GHC.Base.String -> GHC.Types.Int The two types are different }}} Essentially, you have to monomorphize any functions you want to use. Annoying! **Quantifier ordering.** Here's a more subtle one: if I don't explicitly specify a type signature, GHC will pick whatever quantifier ordering it wants. Quantifier ordering affects definitional equality. It's actually pretty easy to trigger this, since GHC seems to always pick the reverse of what you'd get if you explicitly specified the type signature: {{{ unit p where signature H where k :: a -> b -> a unit q where module H where k x y = x unit r where dependency p[H=q:H] }}} Fails with: {{{ q.bkp:7:9: error: Identifier ‘q:H.k’ has conflicting definitions in the module and its hsig file Main module: q:H.k :: t2 -> t1 -> t2 Hsig file: q:H.k :: a -> b -> a The two types are different }}} **Constraint relaxation.** In #12679, you might want to define an abstract class which you can use to let implementors pass in type class instances that they might need. But you often end up in situations where the real implementations of your functions require less constraint than the signature specifies; for example, you might write `insert :: Key k => k -> a -> Map k a -> Map k a`, but if Map is an association list and just appends the new value onto the front of the list, no Eq constraint needed! There goes another impedance matching binding. **Type families.** Type family applications aren't reduced when deciding definitional equality. {{{ {-# LANGUAGE TypeFamilies #-} unit p where signature H where f :: Int unit q where module H where type family F type instance F = Int f :: F f = 2 unit r where dependency p[H=q:H] }}} Gives {{{ q.bkp:11:9: error: Identifier ‘q:H.f’ has conflicting definitions in the module and its hsig file Main module: q:H.f :: q:H.F Hsig file: q:H.f :: GHC.Types.Int The two types are different }}} **Discussion.** It's instructive to consider what the impacts of this sort of relaxation would have on hs-boot files. Some of the equalities that users expect in the source language have operational impact: for example, the ordering of constraints affects the calling convention of the function in question. So there would need to be an impedance matching binding to reorder/drop constraints to match the defining function. We already do an impedance matching of this sort with dictionary functions; this would be a logical extension. Thus, a signature would have to monomorphize, coerce, etc--whatever it needs to show the matching holds. I think this is quite plausible, although it would require rewriting this chunk of code. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12703> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10749: Boot file instances should imply superclasses
by GHC 01 Mar '17

01 Mar '17

#10749: Boot file instances should imply superclasses -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.11 Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Currently, if I write the following program: {{{ -- A.hs-boot module A where data T instance Ord T -- B.hs module B where import {-# SOURCE #-} A f :: T -> T -> Bool f x y = x == y }}} I get: {{{ B.hs:4:11: No instance for (Eq T) arising from a use of `==' Possible fix: add an instance declaration for (Eq T) In the expression: x == y In an equation for `f': f x y = x == y }}} This is a bit confusing, because Ord instances are supposed to imply Eq instances. GHC should either: 1. Reject A.hs-boot (claiming that it could not find evidence that T had an Eq instance), or 2. Accept B.hs, since the instance requirement for Ord should imply Eq. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10749> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9131: Experiment with a dedicated solver for Coercible
by GHC 01 Mar '17

01 Mar '17

#9131: Experiment with a dedicated solver for Coercible ------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- This is something that I might want to do some time; it should not distract us from working and improving the current design and implementation. But I think it should be explored. Currently `Coercible` appears as a type class, we have instances to explain it, and use the existing solver to solve them. The last part sometimes causes problems: * the order the instances are tried matters, there might be dead ends (#9117) * recursive newtypes are not handled as good as they could be. It would be worth exploring if a dedicated solver for `Coercible` constraints could solve these issues. It could replace the existing `getCoercibleInst`. Given a constraint `Coercible s t` it would solve it completely, do nothing or (and this is not planned out yet) return some sufficient and in some sense primitive constraint that should appear in inferred type signatures etc. Ideally we could still explain `Coercible` in terms of the instances written in the ICFP’14 paper, and simply state „GHC will find a solution using these instances, if there are any.“ instead of „The usual solver is employed, it might run into dead ends (or not, hard to tell).“ When tackling this task, I should do something that I keep postponing (because I don’t like to admit my lack of knowlege about that) but I think is really important: What are the theoretical properties of solving `Coercible` constraints? Is it even decidable? Semi decidable? Are there existing standard algorithms? How does this relate to SMT solving? And why don’t I know these things... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9131> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9117: Coercible constraint solver misses one
by GHC 01 Mar '17

01 Mar '17

#9117: Coercible constraint solver misses one ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When I say {{{ import Data.Type.Coercion import Data.Coerce eta :: Coercible f g => Coercion (f a) (g a) eta = Coercion }}} I get {{{ Could not coerce from ‘f a’ to ‘g a’ because ‘f a’ and ‘g a’ are different types. arising from a use of ‘Coercion’ from the context (Coercible f g) bound by the type signature for eta :: Coercible f g => Coercion (f a) (g a) at /Users/rae/temp/Roles.hs:6:8-44 In the expression: Coercion In an equation for ‘eta’: eta = Coercion }}} But, this coercion is easily expressible in Core. If `(co :: f ~R# g)` then `(co <a> :: f a ~R# g a)`, where `<a>` is the notation for a reflexivity coercion for the type `a`. The constraint solver should be able to do this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9117> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 35

[GHC] #12699: Suspicious treatment of renaming of field labels
by GHC 01 Mar '17

01 Mar '17

#12699: Suspicious treatment of renaming of field labels -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While working on my rework of interface file names (Phab:D2467) I noticed that there is some funniness in the treatment of renaming field selectors. Namely, `ifaceConDeclFields` are `IfaceTopBndr`s (and should therefore be renamed), renaming them causes `bkpreex06` to fail with the panic `find_lbl missing foo`. Looking at the environment reveals that there are selectors named `foo` in scope, but they were not renamed. I believe this is due to the implementation of `tcIfaceDataCons`, which typechecks the fields with `mapM (traverse lookupIfaceTop) (ifaceConDeclFields if_cons)`. In essence, this projects the field labels back to `OccName`s (in `ifaceConDeclFields`) and then looks each of these `OccName`s up in the name cache, thereby retrieving the un-renamed `Name`. This seems wrong. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12699> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #8779: Exhaustiveness checks for pattern synonyms
by GHC 28 Feb '17

28 Feb '17

#8779: Exhaustiveness checks for pattern synonyms -------------------------------------------+------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Pattern synonyms are great, as they decouple interface from implementation. Especially if #8581 is also implemented, it should be possible to change a type completely while retaining the existing interface. Exciting! Another missing piece is exhaustiveness checks. Given this pattern {{{ initLast [] = Nothing initLast xs = Just (init xs, last xs) pattern xs ::: x <- (initLast -> Just (xs,x)) }}} we want the compiler to tell the programmer that {{{ f [] = ... f (xs ::: x) = ... }}} is complete, while {{{ g (xs ::: x) = ... }}} is not. With view pattern directly, this is impossible. But the programmer did not write view patterns! So here is what I think might work well, inspired by the new `MINIMAL` pragma: We add a new pragma `COMPLETE_PATTERNS` (any ideas for a shorter name). The syntax is essentially the same as for `MINIMAL`, i.e. a boolean formula, with constructors and pattern synonyms as atoms. In this case. {{{ {-# COMPLETE_PATTERNS [] && (:::) #-} }}} Multiple pragmas are obviously combined with `||`, and there is an implicit `{-# COMPLETE_PATTERNS [] && (:) #-}` listing all real data constructors. When checking for exhaustiveness, this would be done before unfolding view patterns, and for `g` above we get a warning that `[]` is not matched. Again, the implementation is very much analogous to `MINIMAL`. Clearly, a library author can mess up and give wrong `COMPLETE_PATTERNS` pragmas. I think that is ok (like with `MINIMAL`), and generally an improvement. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8779> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 58

[GHC] #12459: UnboxedTuple makes overloaded labels fail to parse
by GHC 26 Feb '17

26 Feb '17

#12459: UnboxedTuple makes overloaded labels fail to parse -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Keywords: orf | 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: -------------------------------------+------------------------------------- [https://gist.githubusercontent.com/PkmX/bfb2c5af4317c96282795f8c588fda1c/ra… This] works (removing spaces) {{{#!hs -- user = ( #login := "themoritz", #id := 3522732 ) user :: User user = (#login := "themoritz", #id := 3522732) }}} but it doesn't when `UnboxedTuples` are enabled: {{{#!hs -- tWKw.hs:63:46: error: parse error on input ‘)’ user = (#login := "themoritz", #id := 3522732) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12459> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11