February 2018 - ghc-tickets

[GHC] #14705: ghc-iserv sometimes segfaults in profiled way
by GHC 26 Mar '18

26 Mar '18

#14705: ghc-iserv sometimes segfaults in profiled way -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.5 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have seen a few testsuite failures due to `ghc-iserv` crashes like these, {{{ --- ./profiling/should_run/T5363.run/T5363.stdout.normalised 2018-01-22 18:57:49.401773263 +0000 +++ ./profiling/should_run/T5363.run/T5363.run.stdout.normalised 2018-01-22 18:57:49.401773263 +0000 @@ -1 +1 @@ -1250030000000 +ghc-stage2: ghc-iserv terminated (-7) *** unexpected failure for T5363(ghci-ext-prof) Actual stdout output differs from expected: --- ./profiling/should_run/scc001.run/scc001.stdout.normalised 2018-01-22 18:57:45.177724120 +0000 +++ ./profiling/should_run/scc001.run/scc001.run.stdout.normalised 2018-01-22 18:57:45.177724120 +0000 @@ -1,3 +1,3 @@ True 3 -'a' +ghc-stage2: ghc-iserv terminated (-11) *** unexpected failure for scc001(ghci-ext-prof) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14705> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #14660: Improve +RTS -t --machine-readable
by GHC 26 Mar '18

26 Mar '18

#14660: Improve +RTS -t --machine-readable -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.3 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: -------------------------------------+------------------------------------- The output of +RTS -t --machine-readable is a shown Haskell list, so we can easily add fields. Let's add everything shown by +RTS -s . I've posted a rough patch that does that at Phab:D4303. If this is a good idea, I'd like to also add the following: * a data structure and parsing function to GHC.Stats in base. * The ghc version as a field in the --machine-readable output * The rts ways as a field in the --machine-readable output -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14660> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10536: Clear up how to turn off dynamic linking in build.mk
by GHC 26 Mar '18

26 Mar '18

#10536: Clear up how to turn off dynamic linking in build.mk -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Build | Version: 7.10.1 System | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- See https://mail.haskell.org/pipermail/ghc-devs/2014-December/007725.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10536> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #11188: Confusing "parse error in pattern" for missing indentation.
by GHC 26 Mar '18

26 Mar '18

#11188: Confusing "parse error in pattern" for missing indentation. -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following problem exists at least in ghc 7.4.2 through 7.10.1: {{{#!hs main = do putStrLn "Hello, lots of crap" $ do a <- return 3 -- The following line is mis-indented, the error is incomprehensible c <- do return 5 }}} Error: {{{ <file>:2:3: Parse error in pattern: putStrLn Possibly caused by a missing 'do'? }}} The hint about "missing do" exists from ghc 7.8, but is wrong in this case. Problematic about this bug is that the wrong indentation can be arbitrary many lines from where ghc reports the (totally incomprehensible) error. My original problem is to find the syntax error here: {{{#!hs -- | Type check a function clause. checkClause :: Type -> A.SpineClause -> TCM Clause checkClause t c(a)(A.Clause (A.SpineLHS i x aps withPats) rhs0 wh) = do unless (null withPats) $ do typeError $ UnexpectedWithPatterns withPats traceCall (CheckClause t c) $ do aps <- expandPatternSynonyms aps checkLeftHandSide (CheckPatternShadowing c) (Just x) aps t $ \ (LHSResult delta ps trhs perm) -> do -- Note that we might now be in irrelevant context, -- in case checkLeftHandSide walked over an irrelevant projection pattern. -- As we will be type-checking the @rhs@ in @delta@, but the final -- body should have bindings in the order of the pattern variables, -- we need to apply the permutation to the checked rhs @v@. let mkBody v = foldr (\ x t -> Bind $ Abs x t) b xs where b = Body $ applySubst (renamingR perm) v xs = [ stringToArgName $ "h" ++ show n | n <- [0..permRange perm - 1] ] -- introduce trailing implicits for checking the where decls TelV htel t0 <- telViewUpTo' (-1) (not . visible) $ unArg trhs (body, with) <- do let n = size htel addCtxTel htel $ checkWhere (size delta + n) wh $ -- for the body, we remove the implicits again escapeContext n $ handleRHS aps (unArgs trhs) rhs0 escapeContext (size delta) $ checkWithFunction with reportSDoc "tc.lhs.top" 10 $ escapeContext (size delta) $ vcat [ text "Clause before translation:" , nest 2 $ vcat [ text "delta =" <+> prettyTCM delta , text "perm =" <+> text (show perm) , text "ps =" <+> text (show ps) , text "body =" <+> text (show body) , text "body =" <+> prettyTCM body ] ] return $ Clause { clauseRange = getRange i , clauseTel = killRange delta , clausePerm = perm , namedClausePats = ps , clauseBody = body , clauseType = Just trhs } }}} {{{ src/full/Agda/TypeChecking/Rules/Def.hs:328:5: Parse error in pattern: checkLeftHandSide Possibly caused by a missing 'do'? }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11188> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #14821: -O2 forces -optlo-O3 in a way that cannot be overridden at command line
by GHC 26 Mar '18

26 Mar '18

#14821: -O2 forces -optlo-O3 in a way that cannot be overridden at command line -------------------------------------+------------------------------------- Reporter: joeyhess | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (LLVM) | 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: -------------------------------------+------------------------------------- I would expect -O2 -optlo-O2 to pass -O2 to the llvm optimiser. However, it seems that -O2 implies -optlo-O3, overriding the command-line's -optlo-O2. The workaround seems to be to use -O1 -optlo-O2, but of course this misses some ghc optimizations. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14821> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13324: Allow PartialTypeSignatures in the instance context of a standalone deriving declaration
by GHC 23 Mar '18

23 Mar '18

#13324: Allow PartialTypeSignatures in the instance context of a standalone deriving declaration -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #10607 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently, if you try to use a wildcard anywhere in an instance context, it will fail immediately: {{{ $ ghci GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> instance _ => Show (Maybe a) <interactive>:1:10: error: Wildcard ‘_’ not allowed in an instance declaration for ‘Show’ }}} But there's one situation where we could lift this restriction: the context of a standalone, derived instance declaration. That is, something like this: {{{#!hs deriving instance _ => Show (Maybe a) }}} Why? Because GHC already has the machinery needed to infer what the context should be (see [http://git.haskell.org/ghc.git/blob/8a6b8c5fb96472d7c2e2cd1918950dd50f2fef7… this part] of `TcDerivInfer`), so if a user turned on `PartialTypeSignatures`, GHC could just fill in the wildcard with the inferred constraints. The implementation won't be //that// easy, however, since we'd also have to watch out for trickery such as: {{{#!hs deriving instance (C a, _) => C (T a b c) }}} I only mentioned putting wildcards in a derived instance //context//, because I think allowing the use of wildcards elsewhere in the instance head might be too difficult to deal with. I mean, how would you fill in this, for example? {{{#!hs instance (_ a) }}} This mini-feature has a very practical application: it would allow users to wield the flexibility of `StandaloneDeriving` without having to manually type in the instance context every time. That is, users could type in these instances: {{{#!hs deriving instance _ => Data (T a b c) deriving instance _ => Eq (T a b c) }}} Instead of their fully spelled-out, more laborious counterparts. This would be crucial for Template Haskell, as its ability to infer these contexts is quite limited (see #10607 for an example where this cropped up). Idle thought: could this be generalized to work for the instance context of //any// instance declaration (and not just derived ones)? From an outside perspective, it seems like typechecking other instances would require inferring constraints in a fashion quite similar to that of derived instances. But I am not at all familiar with that part of the typechecker, so I might be totally off here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13324> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #14731: Document alignment invariants for array types in GHC.Prim
by GHC 21 Mar '18

21 Mar '18

#14731: Document alignment invariants for array types in GHC.Prim -------------------------------------+------------------------------------- Reporter: jberryman | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #2917 #9806 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Through a combination of reading some of the wiki entries on the RTS, some trac tickets, and experimentation I've inferred that the payloads for bytearray types will always be aligned to the machine word size, even after GC. I guess this is obvious in retrospect since otherwise non-pinned arrays would be pretty useless. I'm not sure what the promises are for all the `Foreign` stuff. It can be frustrating to use `GHC.Prim` in particular due to this sort of lack of commitment in the docs, and these compound. Usually I end up trying to find an example in `text` or `bytestring` that would be horribly broken if some undocumented behavior changed, and hang my hat on that with a sad comment in the code I'm writing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14731> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14869: Documentation for isLiftedTypeKind is incorrect
by GHC 21 Mar '18

21 Mar '18

#14869: Documentation for isLiftedTypeKind is incorrect -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I [https://github.com/ghc-proposals/ghc- proposals/pull/32#issuecomment-369252383 noticed recently] that Template Haskell reifies `Constraint` as `Type`: {{{#!hs $ ~/Software/ghc2/inplace/bin/ghc-stage2 --interactive GHCi, version 8.5.20180221: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> :set -XTypeFamilies -XTemplateHaskell λ> :m + Data.Kind Language.Haskell.TH λ> type family Foo :: Constraint λ> putStrLn $(reify ''Foo >>= stringE . pprint) type family Ghci1.Foo :: * }}} The root of the issue can be traced back to the `isLiftedTypeKind` function, which `TcSplice` uses to distinguish `Type` from `Constraint`. At least, that's what its [http://git.haskell.org/ghc.git/blob/df2c3b3364834d2fd038192c89348fc50a2e047… documentation] claims: {{{ -- | This version considers Constraint to be distinct from *. Returns True -- if the argument is equivalent to Type and False otherwise. isLiftedTypeKind :: Kind -> Bool isLiftedTypeKind = is_TYPE is_lifted where is_lifted (TyConApp lifted_rep []) = lifted_rep `hasKey` liftedRepDataConKey is_lifted _ = False }}} However, in practice this claim about treating `Constraint` and `Type` as distinct is false: {{{ $ ~/Software/ghc2/inplace/bin/ghc-stage2 --interactive -package ghc GHCi, version 8.5.20180221: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> :m + TyCoRep TysWiredIn λ> isLiftedTypeKind liftedTypeKind True λ> isLiftedTypeKind constraintKind True }}} Either we should change the implementation of `isLiftedTypeKind` to match the documentation's claim, or change the documentation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14869> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14598: 32-bit Linux environment
by GHC 21 Mar '18

21 Mar '18

#14598: 32-bit Linux environment -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.2.1 Integration | 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: -------------------------------------+------------------------------------- Currently we lack any 32-bit test environment on CircleCI. This will need to change as we still provide 32-bit binary distributions and Harbormaster currently does have a 32-bit test target. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14598> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14844: SpecConstr also non-recursive function
by GHC 20 Mar '18

20 Mar '18

#14844: SpecConstr also non-recursive function -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 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: -------------------------------------+------------------------------------- In order to fix the regressions introduced by loopification (#14068), we probably need to get !SpecConstr also do something about non-recursive functions. In a first iteration, we might want to enable it for non-recursive functions straight-away, and see if it fixes the regressions introduced by Loopification. But if this turns out to be too slow/too expensive, we should try specializing non-recursive ''local'' functions ''if there is only one call-patterns''. That ought to be a straight win in all cases anyways. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14844> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10