- ghc-tickets - Haskell.org

[GHC] #15414: Why both gen and gen_no in bdescr?
by GHC 29 Nov '18

29 Nov '18

#15414: Why both gen and gen_no in bdescr? -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime | Version: 8.4.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: -------------------------------------+------------------------------------- Block descriptors currently contain both `gen` (a `generation *`) and `gen_no` (a `uint16_t, which is `gen->no` cached). I wonder whether it would be worthwhile to drop the former and always use `generations[bd->gen_no]`. Afterall, this would save an entire word per descriptor which may improve our caches' coverage of the bdescr region appreciably. Presumably the `generations` array would be hot enough to stay in cache in such a scheme, so I would guess that the cost would be small-ish. Simon, have you measured this in the past? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15414> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8177: Roles for type families
by GHC 29 Nov '18

29 Nov '18

#8177: Roles for type families ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | 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: | ------------------------------------+------------------------------------- Now that we have [wiki:Roles roles], it might be helpful to be able to give a role signature for a data/type family. At the moment, data/type family constructors have all parameters conservatively assigned to be role `N`. Thus {{{ data family D a -- Parameter conservatively assumed to be N class C a where op :: D a -> a instance C Int where .... newtype N a = MkN a deriving( C ) -- Rejected }}} The generalised-newtype-deriving clause `deriving( C )` is rejected because `D` might use its parameter at role `N` thus: {{{ data instance D [b] = MkD (F b) -- F is a type function }}} It would be strictly more expressive if we could * '''Declare''' the roles of D's arguments (as we can declare their kinds). E.g. {{{ data family D a@R }}} * '''Check''' that each family instance obeys that role signature. E.g. given the preceding role signature, reject this instance: {{{ data instance D [b] = MkD (F b) -- F is a type function }}} I think there is no technical difficulty here. Just a question of doing it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8177> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 41

[GHC] #15969: Generic1 deriving should use more coercions
by GHC 29 Nov '18

29 Nov '18

#15969: Generic1 deriving should use more coercions -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.2 Keywords: Generics | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider {{{#!hs newtype Foo a = Foo (Maybe [a]) deriving (Generic1) }}} This produces some rather unsatisfactory Core: {{{ -- to1 worker Travv.$fGeneric1Foo1 :: forall a. Rep1 Foo a -> Maybe [a] Travv.$fGeneric1Foo1 = \ (@ a_a7RL) (ds_d9dZ :: Rep1 Foo a_a7RL) -> case ds_d9dZ `cast` <Co:103> of { Nothing -> GHC.Maybe.Nothing @ [a_a7RL]; Just a1_a9fD -> GHC.Maybe.Just @ [a_a7RL] (a1_a9fD `cast` <Co:5>) } -- from1 worker Travv.$fGeneric1Foo2 :: forall a. Foo a -> Maybe (Rec1 [] a) Travv.$fGeneric1Foo2 = \ (@ a_a7R6) (x_a7GJ :: Foo a_a7R6) -> case x_a7GJ `cast` <Co:2> of { Nothing -> GHC.Maybe.Nothing @ (Rec1 [] a_a7R6); Just a1_a9fD -> GHC.Maybe.Just @ (Rec1 [] a_a7R6) (a1_a9fD `cast` <Co:6>) } }}} Both of these functions could be implemented as safe coercions, but neither of them is! Similarly, if I define {{{#!hs data Bar a = Bar (Maybe [a]) deriving Generic1 }}} I get a `to1` worker that looks like {{{ Travv.$fGeneric1Bar_$cto1 :: forall a. Rep1 Bar a -> Bar a Travv.$fGeneric1Bar_$cto1 = \ (@ a_a7UA) (ds_d9ho :: Rep1 Bar a_a7UA) -> Travv.Bar @ a_a7UA (case ds_d9ho `cast` <Co:103> of { Nothing -> GHC.Maybe.Nothing @ [a_a7UA]; Just a1_a9iK -> GHC.Maybe.Just @ [a_a7UA] (a1_a9iK `cast` <Co:5>) }) }}} That `case` expression should really just be a cast. I think the basic trick is probably to inspect the role of the type argument of each type in a composition, using that to work out whether to coerce that step. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15969> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15846: Re-examine mkResidualConstraints
by GHC 29 Nov '18

29 Nov '18

#15846: Re-examine mkResidualConstraints -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- Simon and I spent some time debating `TcSimplify.mkResidualConstraints`. Here is what we learned: * The current code handles covars at the top level only. At one point, we were worried about covars in nested implications. But I conjecture this can't happen, because these would necessarily be instances of skolem- escape, prevented elsewhere. (Why skolem-escape? Because the covar would mention local skolems, and yet appears in the type of the variable(s) we're trying to infer.) * We think that any covars that come through `mkResidualConstraints` will ''never'' be solved. That's because there can't be given equality from an outer context -- if there were, we'd be in the "let should not be generalized" case and wouldn't be in `simplifyInfer`. * The `promoteTyVarSet` call in `mkResidualConstraints` appears to be entirely redundant, because anything that gets caught there should also have been caught in `decideMonoTyVars`. * So the only time that we should do work in `mkResidualConstraints` is when we have deferred type errors. Perhaps with that insight, it can be simplified. This ticket is to track our understanding of this function, settle on a way to improve it, and then execute that change. At the minimum, we should figure out whether that `promoteTyVarSet` is necessary. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15846> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14506: Configure Harbormaster to trigger CircleCI commits
by GHC 28 Nov '18

28 Nov '18

#14506: Configure Harbormaster to trigger CircleCI commits -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14506> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #15293: Set up staging branch
by GHC 28 Nov '18

28 Nov '18

#15293: Set up staging branch -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: highest | Milestone: 8.6.1 Component: Continuous | Version: 8.4.3 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: -------------------------------------+------------------------------------- Goal: Keep commits that would break CI out of `master`. Approach: Introduce a staging branch where commits will first land to go through the full CI workup. When a commit passes on `staging`, merge it into `master`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15293> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14950: GHC 8.2.2: GHCi duplicates breakpoint range prompt
by GHC 28 Nov '18

28 Nov '18

#14950: GHC 8.2.2: GHCi duplicates breakpoint range prompt -------------------------------------+------------------------------------- Reporter: lierdakil | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I think breakpoint range is being printed twice, once as part of prompt, and the second time by itself. To reproduce, create `test.hs` file like this: {{{#!hs module Test where test :: IO () test = putStrLn "Hello, World!" }}} Then run the following GHCi session: {{{ $ ghci test.hs GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Test ( test.hs, interpreted ) Ok, one module loaded. *Test> :break test Breakpoint 0 activated at test.hs:4:8-31 *Test> :trace test Stopped in Test.test, test.hs:4:8-31 _result :: IO () = _ [test.hs:4:8-31] [test.hs:4:8-31] *Test> :set prompt "" [test.hs:4:8-31] }}} Notice `[test.hs:4:8-31]` is printed twice, and is even printed when prompt is set to `""`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14950> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15965: readv and pread support
by GHC 28 Nov '18

28 Nov '18

#15965: readv and pread support -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.10.1 Component: | Version: 8.6.2 libraries/base | 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: -------------------------------------+------------------------------------- dcoutts mentioned that `readv` and `pread` are supported by Windows and all modern BSDs, and even POSIX. Perhaps we should expose this in `base`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15965> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15964: PartialTypeSignatures warnings should be turned off with -Wno-partial-type-signatures
by GHC 28 Nov '18

28 Nov '18

#15964: PartialTypeSignatures warnings should be turned off with -Wno-partial-type- signatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- {{{ Foo.hs:638:18: warning: [-Wpartial-type-signatures] }}} The warning when using `PartialTypeSignatures` suggests that the warning is enabled by `-Wpartial-type-signatures`. However, if you try and disable this warning using `-Wno-partial-type-signatures` then GHC complains that it is not a recognised flag. The correct way to turn it off is to use `-fno-warn-partial-signatures`. It seems that for consistency the first way that I tried should also work. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15964> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15963: Test suite should report timeouts as timeouts
by GHC 28 Nov '18

28 Nov '18

#15963: Test suite should report timeouts as timeouts -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: Keywords: newcomer | 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 the test suite reports timeouts as "bad exit code". I think it should instead report timeouts as timeouts. Motivation: Often when working on a change that may make things slower (at least during development) I'm interested in seeing what tests are timing out vs. failing. Currently I have to save the whole test suite log to a file and then grep in the file to manually make a list of such tests. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15963> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0