August 2016 - ghc-tickets

[GHC] #12551: Make type indices take local constraints into account in type instance declaration
by GHC 30 Aug '16

30 Aug '16

#12551: Make type indices take local constraints into account in type instance declaration -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: TypeFamilies | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Given {{{#!hs infixl 1 :$ infixr :-> data Sig x where Full :: a -> Sig a (:->) :: a -> b -> Sig a data AST dom a where Sym :: dom a -> AST dom a (:$) :: AST dom (a:->b) -> AST dom (Full a) -> AST dom b class Syntactic a dom | a -> dom where type Rep a desugar :: a -> AST dom (Full (Rep a)) sugar :: AST dom (Full (Rep a)) -> a }}} I want to be able to define the trivial instance for `Syntactic (AST dom (Full a))`: {{{#!hs instance Syntactic (AST dom (Full a)) dom where type Rep (AST dom (Full a)) = a desugar, sugar :: AST dom (Full a) -> AST dom (Full a) desugar = id sugar = id }}} This should be the only `Syntactic` instance for `AST _ _` so I would like to apply the [http://chrisdone.com/posts/haskell-constraint-trick ‘constraint’ trick] ([https://gist.github.com/Icelandjack/5afdaa32f41adf3204ef9025d9da2a70 #blog-reddit-constraint-trick-for-instances link]) but I cannot use the `Rep` instance as before: {{{#!hs -- • Type indexes must match class instance head -- Found ‘AST dom ('Full a)’ but expected ‘AST dom full_a’ -- • In the type instance declaration for ‘Rep’ -- In the instance declaration for ‘Syntactic (AST dom full_a) dom’ instance full_a ~ Full a => Syntactic (AST dom full_a) dom where type Rep (AST dom (Full a)) = a }}} Maybe this could be accepted, given that `full_a ~ Full a`, therefore the instance head is equal to `AST dom (Full a)`? My current workaround is using a type family {{{#!hs type family Edrú a where Edrú (Full a) = a instance full_a ~ Full a => Syntactic (AST dom full_a) dom where type Rep (AST dom full_a) = Edrú full_a desugar, sugar :: AST dom (Full a) -> AST dom (Full a) desugar = id sugar = id }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12551> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12446: Doesn't suggest TypeApplications when `~` used prefix
by GHC 30 Aug '16

30 Aug '16

#12446: Doesn't suggest TypeApplications when `~` used prefix -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- {{{ $ ghci -ignore-dot-ghci GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Prelude> :t undefined @(_ ~ _) <interactive>:1:1: error: Pattern syntax in expression context: undefined@(_ (~(_))) Did you mean to enable TypeApplications? }}} It is suggested with non-`~` type operators {{{ Prelude> :t undefined @((+) _ _) <interactive>:1:1: error: Pattern syntax in expression context: undefined@((+) (_) (_)) Did you mean to enable TypeApplications? }}} but not with {{{ Prelude> :t undefined @((~) _ _) <interactive>:1:15: error: parse error on input ‘)’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12446> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12483: Improve parse error message on indentation mistake
by GHC 29 Aug '16

29 Aug '16

#12483: Improve parse error message on indentation mistake -------------------------------------+------------------------------------- Reporter: harendra | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following code fragment: {{{#!hs (ExecGhc, args) -> execCompiler "" args -- NOTE: this won't currently work for GHCJS, because it doesn't have -- a runghcjs binary. It probably will someday, though. (ExecRunGhc, args) -> }}} The last line is indented by one space but it is hard to notice esp when we looking at this along with a screenful of code and there are many comments between the two lines. When this code is compiled ghc throws the following error: {{{ Main.hs:745:40: error: parse error on input ‘->’ }}} I look at the error and then the code and wonder what is wrong with this code, there is nothing noticeably wrong. If ghc can provide some context I can easily make out where the problem is. ghc can perhaps tell me how the current expression is being parsed e.g. `(ExecRunGhc, args) ->` is being considered as a continuation of the expression on the previous line. I have run into this many times. The first time it was really frustrating. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12483> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #12198: Stack fails to compile using GHC 8.0.1 on MacOS 10.12
by GHC 29 Aug '16

29 Aug '16

#12198: Stack fails to compile using GHC 8.0.1 on MacOS 10.12 -------------------------------------+------------------------------------- Reporter: mistydemeo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 failed when trying to build stack from source on MacOS 10.12 using GHC 8.0.1. The relevant part of the error is here: {{{ [ 1 of 87] Compiling Stack.FileWatch ( src/Stack/FileWatch.hs, dist/dist- sandbox-68bf8d9c/build/Stack/FileWatch.o ) [ 2 of 87] Compiling System.Process.PagerEditor ( src/System/Process/PagerEditor.hs, dist/dist-sandbox- 68bf8d9c/build/System/Process/PagerEditor.o ) [ 3 of 87] Compiling System.Process.Log ( src/System/Process/Log.hs, dist /dist-sandbox-68bf8d9c/build/System/Process/Log.o ) [ 4 of 87] Compiling System.Process.Read ( src/System/Process/Read.hs, dist/dist-sandbox-68bf8d9c/build/System/Process/Read.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/4d/rttdp_9d2s7f36zplgwnqrgr0000gn/T/ghc94633_0/libghc_44.dylib, 5): no suitable image found. Did find: /var/folders/4d/rttdp_9d2s7f36zplgwnqrgr0000gn/T/ghc94633_0/libghc_44.dylib: malformed mach-o: load commands size (40192) > 32768 }}} Full build logs (includes dependency installation via cabal-install): https://gist.github.com/8e005710eab17139c02267bac3029e33 This occurred when installing stack, but reporting here because of the "Please report this as a GHC bug" message in the failed build output. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12198> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12475: GHCi no longer handles stdin being closed gracefully
by GHC 29 Aug '16

29 Aug '16

#12475: GHCi no longer handles stdin being closed gracefully -------------------------------------+------------------------------------- Reporter: rowanblush | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 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: -------------------------------------+------------------------------------- It used to be the case that GHCi handled the user closing stdin gracefully, continuing to accept input and restoring stdin on :reload (as is documented in the GHC Users Guide GHCi FAQ (1)). This was the case in 7.6.3, but at least as of 7.8.4 GHCi now dies immediately after printing the prompt following usage of `getContents`. I'm using NixOs version 16.03.1171.9cb194c (Emu). I don't believe this to be a nix- or nixpkgs-related problem, but I don't have any other machines on which to test. I test 7.6.3, 7.8.4, 7.10.3 and 8.0.1 below. {{{ #!sh [rowanblush@coquelicot:~] +$ nix-shell -p haskell.packages.ghc763.ghc --command "ghci" --pure GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> getContents >> return () Prelude> getLine *** Exception: <stdin>: hGetLine: illegal operation (handle is closed) Prelude> :reload Ok, modules loaded: none. Prelude> getLine echo "echo" Prelude> :q Leaving GHCi. [rowanblush@coquelicot:~] :$ nix-shell -p haskell.packages.ghc784.ghc --command "ghci" --pure GHCi, version 7.8.4: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> getContents >> return () Prelude> <stdin>: hGetChar: illegal operation (handle is closed) [rowanblush@coquelicot:~] +$ nix-shell -p haskell.packages.ghc7103.ghc --command "ghci" --pure GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help Prelude> getContents >> return () Prelude> <stdin>: hGetChar: illegal operation (handle is closed) [rowanblush@coquelicot:~] +$ nix-shell -p haskell.packages.ghc801.ghc --command "ghci" --pure GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rowanblush/.ghci Prelude> getContents >> return () Prelude> <stdin>: hGetChar: illegal operation (handle is semi-closed) [rowanblush@coquelicot:~] +$ }}} (1): https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ghci.html #faq-and-things-to-watch-out-for -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12475> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #12473: Ambiguous type var with DefaultSignatures and FunctionalDependencies
by GHC 29 Aug '16

29 Aug '16

#12473: Ambiguous type var with DefaultSignatures and FunctionalDependencies -------------------------------------+------------------------------------- Reporter: dylex | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | 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: -------------------------------------+------------------------------------- Consider: {{{ {-# LANGUAGE DefaultSignatures, FunctionalDependencies, ScopedTypeVariables #-} class Foo a b where foo :: a -> b -> Int class Bar a b | b -> a where get :: b -> a bar :: b -> Int default bar :: Foo a b => b -> Int bar b = foo (get b :: a) b }}} This works fine with ghc 7.10.3 (even without the explicit :: a type spec), but with 8.0.1, produces: {{{ - Could not deduce (Foo a0 b) from the context: Foo a b bound by the type signature for: bar :: Foo a b => b -> Int at t.hs:6:3-17 The type variable `a0' is ambiguous - In the ambiguity check for `bar' To defer the ambiguity check to use sites, enable AllowAmbiguousTypes When checking the class method: bar :: forall a b. Bar a b => b -> Int In the class declaration for `Bar' }}} Not sure if this is intentional or some good way to get around it, but I couldn't find anything related to it in the release notes or any similar looking bugs. (Real-life case: https://github.com/dylex/postgresql- typed/blob/master/Database/PostgreSQL/Typed/Dynamic.hs#L48 ) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12473> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12471: Weirdness when using quosiquoter in pattern synonyms / GADT context
by GHC 29 Aug '16

29 Aug '16

#12471: Weirdness when using quosiquoter in pattern synonyms / GADT context -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple TemplateHaskell, PatternSynonyms, | GADTs | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Using [https://hackage.haskell.org/package/applicative- quoters-0.1.0.8/docs/Control-Applicative-QQ-Idiom.html idiom brackets], is this a bug? {{{#!hs import Control.Applicative.QQ.Idiom data Exp a where I :: Int -> Exp Int pattern MkI :: Int ~ a => a -> Exp a pattern MkI a = I a c :: Exp a -> IO a c (MkI n) = pure n }}} This works. If I replace `pure n` by `[i| n |]` I get this error: {{{ tKTa.hs:10:4-8: error: … • Couldn't match type ‘a’ with ‘Int’ arising from a pattern ‘a’ is a rigid type variable bound by the type signature for: c :: forall a. Exp a -> IO a at /tmp/tKTa.hs:9:6 • In the pattern: MkI n In an equation for ‘c’: c (MkI n) = (pure n) • Relevant bindings include c :: Exp a -> IO a (bound at /tmp/tKTa.hs:10:1) Compilation failed. }}} This works without the pattern synonym {{{#!hs c :: Exp a -> IO a c (I n) = [i| n |] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12471> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12448: Allow partial application of bidirectional pattern synonyms
by GHC 29 Aug '16

29 Aug '16

#12448: Allow partial application of bidirectional pattern synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs type Product3 = (,,) }}} Allow {{{#!hs pattern Product3 :: a -> b -> c -> Product3 a b c pattern Product3 = (,,) }}} to mean {{{#!hs pattern Product3 :: a -> b -> c -> Product3 a b c pattern Product3 x y z = (x, y, z) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12448> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12416: Some GCC versions warn about failed inlines
by GHC 29 Aug '16

29 Aug '16

#12416: Some GCC versions warn about failed inlines -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System | 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: -------------------------------------+------------------------------------- gcc 4.8.4 on Ubuntu 14.04 warns about failed inlinings. I'm not really sure what to do about this at the moment, so I'm going to leave this here. {{{ In file included from rts/Schedule.h:15:0: error: 0, from rts/Capability.c:23: In function ‘initCapability’: rts/Trace.h:742:20: error: warning: inlining failed in call to ‘traceSparkCounters.part.10’: call is unlikely and code size would grow [-Winline] INLINE_HEADER void traceSparkCounters(Capability *cap STG_UNUSED) ^ cc1: warning: called from here [-Winline] In function ‘yieldCapability’: rts/Trace.h:742:20: error: warning: inlining failed in call to ‘traceSparkCounters.part.10’: call is unlikely and code size would grow [-Winline] INLINE_HEADER void traceSparkCounters(Capability *cap STG_UNUSED) ^ cc1: warning: called from here [-Winline] In function ‘shutdownCapabilities’: rts/Trace.h:742:20: error: warning: inlining failed in call to ‘traceSparkCounters.part.10’: call is unlikely and code size would grow [-Winline] INLINE_HEADER void traceSparkCounters(Capability *cap STG_UNUSED) ^ cc1: warning: called from here [-Winline] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12416> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12349: Parallel make should interleave output if it means we can report an error earlier
by GHC 29 Aug '16

29 Aug '16

#12349: Parallel make should interleave output if it means we can report an error earlier -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- Steps to reproduce: 1. Take the example from #12347 2. Run `ghc --make` and observe what order the modules are reported in (on my box the ordering is `C`, `B`, then `A`) 3. Modify `A` to be a small, quick-to-compile module with a type error. `module A where x = True True` works grand. 4. Run `ghc --make All A B C -j4 +RTS -N4` Expected result: `ghc --make` reports the error in `A` immediately Actual result: `ghc --make` ponders for a while before reporting the error An interesting way to mix up the experiment is to put the type error in `C` rather than `A`. Then indeed the error is reported early, but GHC fails to exit until some undetermined later time (it is certainly not waiting for the other threads to finish compiling, because you don't see object files being produced.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12349> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1