September 2018 - ghc-tickets

[GHC] #15457: (~) and (!) are parsed inconsistently in types (plus documentation warts)
by GHC 04 Oct '18

04 Oct '18

#15457: (~) and (!) are parsed inconsistently in types (plus documentation warts) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 (Parser) | 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: -------------------------------------+------------------------------------- (Spawned from https://ghc.haskell.org/trac/ghc/ticket/10056?replyto=41#comment:41) `~` and `!` are slightly special in the parser to allow strict annotations and lazy annotations (with `-XStrict`) in data types. As a result, we initially parse all uses of `~`/`!` as bangs, and we use a post-parsing pass (`mergeOps`/`splitTilde`) to figure out which uses of `~` are actually meant to refer to the equality type constructor. There's a couple of unsatisfying things here: 1. `splitTilde` handles `~`, but not `!`. This means that any use of `!` as a type operator will not work, as evidenced by this GHCi session: {{{ λ> type a ! b = Either a b <interactive>:1:6: error: Malformed head of type or class declaration: a !b }}} We should update `splitTilde` to handle `!` as well. (And perhaps give that function a new name to reflect its more ambitious goals.) 2. `Note [Parsing ~]` is supposed to explain all of this hullabaloo, but it does a rather poor job of it. Let's add some more prose to it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15457> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15483: ghc -M requires -dep-suffix for no good reason
by GHC 03 Oct '18

03 Oct '18

#15483: ghc -M requires -dep-suffix for no good reason -------------------------------------+------------------------------------- Reporter: ulysses4ever | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Driver | Version: 8.4.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: -------------------------------------+------------------------------------- Doing {{{ ghc -M Foo.hs }}} gives {{{ You must specify at least one -dep-suffix }}} I went to the documentation and noticed ([https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/separate_co… #makefile-dependencies 7.8.12]) an example: {{{ depend : ghc -dep-suffix '' -M $(HC_OPTS) $(SRCS) }}} So, empty suffix is fine. Why not default to empty string then? I found a commit which introduced the requirement ([https://github.com/ghc/ghc/commit/af072fc35d8dbe7962e62700da052593e999c0ef af072fc]): it says, it fixed #7381, and this doesn't seem to do anything with `dep-suffix` in particular. So, maybe there is no good reason to require that. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15483> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #12556: `stimes` adds extra power to Semigroup
by GHC 03 Oct '18

03 Oct '18

#12556: `stimes` adds extra power to Semigroup -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: task | Status: new Priority: normal | Milestone: Component: | Version: 8.0.1 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ ghci> stimes 0 (undefined :: [_]) [] }}} ghci> stimes 0 undefined () }}} makes it seem like `stimes 0` has some knowledge about `mempty` from `Monoid` but it has the following type {{{#!hs stimes 0 :: Semigroup a => a -> a }}} Desired behaviour? Given that type (assuming it only has the power of `<>`) I would have assumed this behaviour {{{ ghci> data L a = N | C a (L a) deriving Show ghci> instance Semigroup (L a) where (<>) = undefined ghci| ghci> stimes 0 (undefined :: L _) *** Exception: stimes: positive multiplier expected }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12556> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15693: Abstracting out pattern into a pattern synonym fails with scary error
by GHC 03 Oct '18

03 Oct '18

#15693: Abstracting out pattern into a pattern synonym fails with scary error -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- This '''works''' {{{#!hs {-# Language DataKinds, TypeOperators, PolyKinds, PatternSynonyms, GADTs #-} import Data.Kind data Ctx :: Type -> Type where E :: Ctx(Type) (:&:) :: a -> Ctx(as) -> Ctx(a -> as) data ApplyT(kind::Type) :: kind -> Ctx(kind) -> Type where AO :: a -> ApplyT(Type) a E AS :: ApplyT(ks) (f a) ctx -> ApplyT(k -> ks) f (a:&:ctx) foo :: ApplyT(Type -> Type -> Type) Either a -> () foo (ASSO (Left a)) = () pattern ASSO a = AS (AS (AO a)) }}} but then you might think, let's give a name (pattern synonym) to `ASSO (Left a)` This '''fails''' {{{#!hs {-# Language DataKinds, TypeOperators, PolyKinds, PatternSynonyms, GADTs #-} import Data.Kind data Ctx :: Type -> Type where E :: Ctx(Type) (:&:) :: a -> Ctx(as) -> Ctx(a -> as) data ApplyT(kind::Type) :: kind -> Ctx(kind) -> Type where AO :: a -> ApplyT(Type) a E AS :: ApplyT(ks) (f a) ctx -> ApplyT(k -> ks) f (a:&:ctx) pattern ASSO a = AS (AS (AO a)) pattern ASSOLeft a = ASSO (Left a) }}} {{{ $ ghci -ignore-dot-ghci 464.hs GHCi, version 8.7.20180828: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( hs/464.hs, interpreted ) hs/464.hs:16:22: error: • Couldn't match type ‘k1’ with ‘*’ ‘k1’ is a rigid type variable bound by the signature for pattern synonym ‘ASSOLeft’ at hs/464.hs:16:1-34 Expected type: ApplyT kind a b Actual type: ApplyT (* -> * -> *) Either (a1 ':&: (a20 ':&: 'E)) • In the expression: ASSO (Left a) In an equation for ‘ASSOLeft’: ASSOLeft a = ASSO (Left a) | 16 | pattern ASSOLeft a = ASSO (Left a) | ^^^^^^^^^^^^^ hs/464.hs:16:28: error: • Could not deduce: k1 ~ * from the context: (kind ~ (k -> ks), a ~~ f, b ~~ (a2 ':&: ctx), ks ~ (k1 -> ks1), f a2 ~~ f1, ctx ~~ (a3 ':&: ctx1), ks1 ~ *, f1 a3 ~~ a4, ctx1 ~~ 'E) bound by a pattern with pattern synonym: ASSO :: forall kind (a :: kind) (b :: Ctx kind). () => forall ks k (f :: k -> ks) (a1 :: k) (ctx :: Ctx ks) ks1 k1 (f1 :: k1 -> ks1) (a2 :: k1) (ctx1 :: Ctx ks1) a3. (kind ~ (k -> ks), a ~~ f, b ~~ (a1 ':&: ctx), ks ~ (k1 -> ks1), f a1 ~~ f1, ctx ~~ (a2 ':&: ctx1), ks1 ~ *, f1 a2 ~~ a3, ctx1 ~~ 'E) => a3 -> ApplyT kind a b, in a pattern synonym declaration at hs/464.hs:16:22-34 ‘k1’ is a rigid type variable bound by a pattern with pattern synonym: ASSO :: forall kind (a :: kind) (b :: Ctx kind). () => forall ks k (f :: k -> ks) (a1 :: k) (ctx :: Ctx ks) ks1 k1 (f1 :: k1 -> ks1) (a2 :: k1) (ctx1 :: Ctx ks1) a3. (kind ~ (k -> ks), a ~~ f, b ~~ (a1 ':&: ctx), ks ~ (k1 -> ks1), f a1 ~~ f1, ctx ~~ (a2 ':&: ctx1), ks1 ~ *, f1 a2 ~~ a3, ctx1 ~~ 'E) => a3 -> ApplyT kind a b, in a pattern synonym declaration at hs/464.hs:16:22-34 When matching types a3 :: k1 b0 :: * Expected type: a4 Actual type: Either a1 b0 • In the pattern: Left a In the pattern: ASSO (Left a) In the declaration for pattern synonym ‘ASSOLeft’ | 16 | pattern ASSOLeft a = ASSO (Left a) | ^^^^^^ Failed, no modules loaded. Prelude> }}} ---- Can I, as a user, assume that any valid pattern `foo (ASSO (Left a)) = ...` can be abstracted into a pattern synonym? There error message is too scary for me to sensibly know what to expect -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15693> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9136: Constant folding in Core could be better
by GHC 02 Oct '18

02 Oct '18

#9136: Constant folding in Core could be better ------------------------------+-------------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- Constant folding in Core is still a bit feeble. For example, when staring at the code for `nofib/shootout/k-nucleotide` I saw this expression: {{{ (x +# 8) -# 1 }}} which would be relatively easy to optimise. The difficulty is knowing where to stop. What about `(8 +# x) -# 1`? Anyway, this ticket is to record the issue. Currently constant folding is done by the built-in RULES in `compiler/prelude/PrelRules`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9136> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 31

[GHC] #10791: Add a --disable-large-memory-space configure option
by GHC 02 Oct '18

02 Oct '18

#10791: Add a --disable-large-memory-space configure option -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: feature | Status: new request | Priority: normal | Milestone: 7.12.1 Component: Build | Version: 7.11 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- GHC recently started using large (1TB) address space on 64 bit systems. This feature is enabled by default but does not work on arm64-linux or amd64-solaris. Even just for testing, it would be nice to be able to disable this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10791> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10793: Incorrect blocked on MVar detection
by GHC 02 Oct '18

02 Oct '18

#10793: Incorrect blocked on MVar detection -------------------------------------+------------------------------------- Reporter: | Owner: simonmar NeilMitchell | Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.1 System | Keywords: | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Given the code: {{{#!hs import Control.Concurrent main = do v <- newEmptyMVar forkFinally (putStrLn $ let x = x in x) (putMVar v) print =<< takeMVar v }}} The spawned thread should raise a {{{NonTermination}}} exception (assuming idle GC), then put it in the MVar {{{v}}}, which should cause the main thread to abort printing {{{Left <<loop>>}}}. However, in reality, the main thread aborts with {{{Exception: thread blocked indefinitely in an MVar operation}}}. My debugging shows that the spawned thread raises {{{NonTermination}}} and at the same time the main thread raises {{{BlockedIndefinitelyOnMVar}}}. Of course, the main thread is not really blocked on the exception, and after the finally bit runs, the MVar is filled. Adding tracing shows that the {{{putMVar}}} is called. Hypothesis is that the GC notices it can raise the non-termination exception, and then opportunistically excludes that thread from further GC scanning, and detects the MVar is unreferenced, raising the subsequent exception. Of course, given you can catch the exception, that isn't safe. Roman Leshchinskiy worries that in the wrong circumstances the MVar might really be being GC'd and thus could corrupt memory. This issue was detected while debugging an error in the Shake build system for GHC itself. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10793> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #15287: T11627[ab] fail on some Darwin environments
by GHC 02 Oct '18

02 Oct '18

#15287: T11627[ab] fail on some Darwin environments -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- As of d6216443c61cee94d8ffc31ca8510a534d9406b9 I am seeing `T11627a` and `T11627b` fail in the `prof_hr` way on Darwin under CircleCI (but not Harbormaster!): {{{ Wrong exit code for T11627b(prof_hr)(expected 0 , actual 139 ) Stderr ( T11627b ): /bin/sh: line 1: 73247 Segmentation fault: 11 ./T11627b +RTS -hr -RTS +RTS -i0 -RTS *** unexpected failure for T11627b(prof_hr) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15287> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12146: syntax repair suggestion is too eager to suggest TemplateHaskell
by GHC 01 Oct '18

01 Oct '18

#12146: syntax repair suggestion is too eager to suggest TemplateHaskell -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- On input `ipmort Data.Monoid`, ghc's suggestion is {{{ Parse error: naked expression at top level Perhaps you intended to use TemplateHaskell }}} Apart from the nudity: the suggestion is unreasonable for beginners, and unnecessary for experts. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12146> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #8226: Remove the old style -- # Haddock comments.
by GHC 01 Oct '18

01 Oct '18

#8226: Remove the old style -- # Haddock comments. ------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: task | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Haddock 0.x supported -- # style comments for Haddock pragma and while this seems to have been long forgotten and not documented, it's still kicking in the lexer. I think this is a good time to get rid of these all together. Relevant Haddock ticket http://trac.haskell.org/haddock/ticket/171 I'll hopefully send in patches removing these from the lexer/parser tomorrow, if all goes well (unless anyone feels eager to do it, then please, you're most welcome to do so!). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8226> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11