January 2016 - ghc-tickets

[GHC] #11449: Treat '_' consistently in type declarations
by GHC 25 Jan '16

25 Jan '16

#11449: Treat '_' consistently in type declarations -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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 doesn't treat `_` consistently in type declarations {{{ -- Example A data T _ = MkT -- Not allowed -- Example B class C a where type T a -- Example C class C [_] where -- Not allowed type T [_] = Int -- Not allowed -- Example D data family D a data instance D [_] = MkD -- Allowed -- Example E type family F a type instance F [_] = Int -- Allowed }}} This seems inconsistent and annoying (see [https://mail.haskell.org/pipermail/glasgow-haskell- users/2016-January/026114.html email thread]). Really, we should consistently treat `_` in a binding position simply as ''a binder that binds nothing'', just like at the term level. But in Haskell 98 `_` is a reserved identifier, so these programs are illegal. We use `PartialTypeSignatures` to allow `_` in occurrence positions in types. Should the same flag enable `_` in binding positions? It would seem a little odd to require `PartialTypeSignatures` for (A) and (C). Any suggestions? A couple of wrinkles. First, since `_` binds nothing, it certainly doesn't bind occurrences of `_`. Thus for example, with `PartialTypeSignatures` {{{ instance C [_] where op = .... (let f :: _ -> _ f = e in ...) ... }}} The occurrences of `_` in `op`'s RHS are ''not'' bound by the `_` in the `instance` header. (The would be if all three were `a`, say.) Rather the occurrences of `_` are holes in the type signature and should be separately reported as such. Second, the implementation would be tricky in one spot: {{{ class C a where type T a instance C (Either _ _) where type T (Either _ _) = ... }}} We must check that the type family instance is at the same type as the class. Do we want to insist that it looks ''exactly'' the same, or would you be allowed to say this? {{{ instance C (Either _ _) where type T (Either a b) = a -> b }}} My instinct is to say "exactly the same" for now anyway. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11449> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10751: Implement Phase 1 of MonadFail Proposal (MFP)
by GHC 25 Jan '16

25 Jan '16

#10751: Implement Phase 1 of MonadFail Proposal (MFP) -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.2 Keywords: report- | Operating System: Unknown/Multiple impact | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- See also - https://www.reddit.com/r/haskell/comments/3a1o06/monadfail_proposal_mfp/ TODO: At this point this ticket is mostly a reminder that stuff may need to be done for GHC 7.12 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10751> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[GHC] #11248: Ambiguous Types with Constraint Synonyms
by GHC 25 Jan '16

25 Jan '16

#11248: Ambiguous Types with Constraint Synonyms -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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: -------------------------------------+------------------------------------- The following code fails to compile: {{{ {-# LANGUAGE DataKinds, TypeOperators, TypeFamilies, KindSignatures, ConstraintKinds #-} import GHC.TypeLits type a / b = FDiv a b type a ** b = FMul a b type family FDiv a b where FDiv 11648 128 = 91 type family FMul a b where FMul 64 91 = 5824 type family FGCD a b where FGCD 128 448 = 64 FGCD 128 5824 = 64 type family FLCM a b where FLCM 128 5824 = 11648 data CT (m :: Nat) (m' :: Nat) type H0 = 128 type H1 = 448 type H0' = 11648 type H1' = 5824 main' = let x = undefined :: CT H0 H0' in foo x :: CT H1 H1' foo x = bug x type Ctx2 e r s e' r' = (e ~ FGCD r e', r' ~ FLCM r e', e ~ FGCD r s) type Ctx1 e r s e' r' = (Ctx2 e r s e' r', e' ~ (e ** (r' / r))) bug :: (Ctx1 e r s e' r') => CT r r' -> CT s s' bug = undefined }}} with the error {{{ Could not deduce ((~) Nat (FGCD r e'0) (FGCD r s)) ... The type variable ‘e'0’ is ambiguous When checking that ‘foo’ has the inferred type foo :: forall (r :: Nat) (s :: Nat) (s' :: Nat) (e' :: Nat). ((~) Nat (FGCD r s) (FGCD r e'), (~) Nat (FMul (FGCD r s) (FDiv (FLCM r e') r)) e') => CT r (FLCM r e') -> CT s s' Probable cause: the inferred type is ambiguous }}} However, if I move the `e' ~ ...` constraint from `Ctx1` to `Ctx2` or to the context of `bug`, it compiles as expected. Somehow, GHC misses the constraint when it is in `Ctx1`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11248> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #11056: Need to generate Typable info for promoted data constructors
by GHC 25 Jan '16

25 Jan '16

#11056: Need to generate Typable info for promoted data constructors -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 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: -------------------------------------+------------------------------------- Trac #10052 isn't relevant for HEAD, because HEAD generates implicit `Typeable` bindings for everything. But in testing {{{ {-# LANGUAGE PolyKinds, DataKinds #-} module Foo where import Data.Typeable data T = A | B Int bar :: TypeRep bar = typeRep (Proxy :: Proxy '[True]) }}} I discovered that we aren't generating tycon-rep bindings for promoted data constructors. As a result we get {{{ GHC error in desugarer lookup in Foo: Can't find interface-file declaration for variable tc'[] Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error }}} In particular `TcTypeable.mkTypeableBinds` doesn't generate the bindings for the `tc'[]` and `tc':`. It's not hard to fix this, but it will add more top-level declarations for each data type decl. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11056> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11478: ghc -e shouldn't print "Loaded GHCi configuration" message
by GHC 25 Jan '16

25 Jan '16

#11478: ghc -e shouldn't print "Loaded GHCi configuration" message -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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: -------------------------------------+------------------------------------- Phab:D1756 added a message when ghci loads a configuration file. But `ghc -e` is secretly ghci too, and we certainly shouldn't print the message then, since the output `ghc -e` is likely to be consumed by a shell script or the like. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11478> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10560: -f and -O options interact in non-obvious, order dependent ways
by GHC 25 Jan '16

25 Jan '16

#10560: -f and -O options interact in non-obvious, order dependent ways -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The `-O[012]` and `-f*` flags are both implemented by manipulating a set of flags in `DynFlags`. These manipulations occur in the order that the flags occur in the command line. This leads to some rather surprising behavior. For instance, if the user wants to compile with optimization but specifically wants to disable specialisation, they might enter `-fno- specialise -O1`. This, however, would not do what the user expects as `-O1` implies `-fspecialise`, overriding the first flag. This is surprising and poorly documented behavior at best. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10560> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #11306: Do not generate warning in `do` when result is of type `Void`.
by GHC 25 Jan '16

25 Jan '16

#11306: Do not generate warning in `do` when result is of type `Void`. -------------------------------------+------------------------------------- Reporter: diatchki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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 generates warnings when `do` notation statements discard their result, without an explicit `_ <- `, unless the discarded result is of type `()`. Another type which is used to indicate "no result", is `Void` from `Data.Void`. There are no meaningful values of this type, so we should also skip the warnings for such situations. Here is an example: {{{#!hs import Data.Void f :: IO Void f = undefined main :: IO () main = do f return () }}} GHC output: {{{ test.hs:7:11: Warning: A do-notation statement discarded a result of type ‘Void’ Suppress this warning by saying ‘_ <- f’ or by using the flag -fno-warn-unused-do-bind }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11306> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8325: Pattern guards in anonymous functions
by GHC 25 Jan '16

25 Jan '16

#8325: Pattern guards in anonymous functions ------------------------------------+------------------------------------- Reporter: mcollis | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- In the course of a project, I had an idea that would allow less cumbersome use of cases in anonymous functions. Here's a simple example of what I'm proposing: {{{ (\x y | x > y -> x | otherwise -> something else) }}} Currently, the only way to accomplish this is with if() then ... else syntax or the use of the MultiWayIf and LambdaCase extensions. The syntax I've proposed here matches with existing anonymous function syntax and doesn't conflict with any other GHC syntax. This would greatly improve the readability of complex anonymous functions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8325> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11476: gcc leaves undeleted temporary files when invoked with a response file
by GHC 25 Jan '16

25 Jan '16

#11476: gcc leaves undeleted temporary files when invoked with a response file -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Split off from #10986. In changeset:296bc70b5ff6c853f2782e9ec5aa47a52110345e (present in 7.10.3, but not 7.10.2) ghc started using response files when invoking gcc as a linker, to work around command-line length limits. Unfortunately, gcc leaves behind a temporary file `/tmp/cc??????` when it is invoked with a response file. That means that every time we link an executable, gcc leaks a temporary file. In the course of a validate run (due mainly to the testsuite) that means thousands of temporary files. I'm not sure exactly which versions (or which OSes) are affected, but from ticket:10986#comment:5 it seems that at least gcc 4.6.3 on Windows is affected, and Windows is where we need the response file the most (since the command line length limit is shortest there). slyfox filed an upstream bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69351 But in the mean time, this is pretty terrible. What can we do about it? One suggestion: ghc already creates a temporary directory like `/tmp/ghc1740_0`. So make a subdirectory `/tmp/ghc1740_0/cc`, and set `TMPDIR` (or whichever similarly-named environment variable has highest precedence) for the invocation of gcc to that directory. Then, when cleaning up, we blow away that whole directory. Then we are immune to gcc leaving behind any temporary files. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11476> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #5615: ghc produces poor code for `div` with constant powers of 2.
by GHC 24 Jan '16

24 Jan '16

#5615: ghc produces poor code for `div` with constant powers of 2. -------------------------------------+------------------------------------- Reporter: Lennart | Owner: | daniel.is.fischer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Runtime | Test Case: performance bug | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by liyang): * cc: liyang (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5615#comment:27> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0