November 2018 - ghc-tickets

[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

[GHC] #15958: Missing documentation for '-fno-ghci-sandbox'
by GHC 27 Nov '18

27 Nov '18

#15958: Missing documentation for '-fno-ghci-sandbox' -------------------------------------+------------------------------------- Reporter: andregrigon | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Documentation | 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: -------------------------------------+------------------------------------- The option '-fno-ghci-sandbox' is mentioned in https://downloads.haskell.org/~ghc/7.0.2/docs/html/users_guide/release-7-0-… with the following explanation: There is a new -fno-ghci-sandbox flag, which stops GHCi running computations in a separate thread. In particular, this is useful for GLUT on OS X, which only works if being run on the main thread. However, it doesn't seem to be documented on the GHC user's guide (search box didn't find anything). Sorry if I just couldn't find it! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15958> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0