December 2018 - ghc-tickets

[GHC] #13322: Pattern synonyms in hs-boot files
by GHC 24 Dec '18

24 Dec '18

#13322: Pattern synonyms in hs-boot files -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: hs-boot | Operating System: Unknown/Multiple backpack | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Pattern synonyms are not permitted in hs-boot files: {{{ ezyang@sabre:~/bun$ ghc-head -c A.hs-boot A.hs-boot:3:5: error: Misplaced pattern synonym signature: pattern X :: Bool | 3 | pattern X :: Bool | ^^^^^^^^^^^^^^^^^ A.hs-boot:3:13: error: The pattern synonym signature for ‘X’ lacks an accompanying binding | 3 | pattern X :: Bool | }}} There isn't really any reason why they shouldn't be supported. One thing to check closely: if we bundle a pattern synonym declared in an hs-boot file with another type, in an hs-boot file, what happens? In particular, does an hs file which doesn't bundle the pattern synonym and the type valid? If we add support for them, make sure that Backpack signatures handle it properly. In particular, suppose we have: {{{ signature A(T(X)) where data T pattern X :: T }}} Then, when we instantiate A, we must be careful to NOT blindly reuse the implementing module of T for X (as we do today in `uAvailInfo` in `NameShape`), since T and X may be defined in different modules. I'm not likely to implement this unless someone asks. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13322> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #16070: Better inferred signatures
by GHC 24 Dec '18

24 Dec '18

#16070: Better inferred signatures -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- Consider this (taken from [https://github.com/ghc-proposals/ghc- proposals/pull/158#issuecomment-448549030 here]) {{{ class FieldType x r ~ a => HasField (x :: k) r a where type FieldType x r getField :: r -> a setField :: r -> a -> r f r = setField @"bar" r (getField @"foo" r) }}} We get this type inferred for `f`: {{{ f :: forall r. (HasField "bar" r (FieldType "bar" r), HasField "foo" r (FieldType "bar" r)) => r -> r }}} But actually this signature is equivalent {{{ f :: forall r a. (HasField "bar" r a, HasField "foo" r a) => r -> r }}} and it's quite a bit shorter. Similarly, from this definition {{{ g r = setField r }}} We get this inferred type {{{ g :: forall r p. HasField "bar" r (FieldType "bar" r) => p -> r -> FieldType "bar" r -> r }}} where again we might prefer {{{ g :: forall r a. HasField "bar" r a => r -> a -> r }}} '''Question''': could we make GHC infer the briefer types? After all, it does some similar abbreviation with type classes. Where we could infer `(Ord a, Eq a)` we collapse out the `Eq a` and just infer the context `(Ord a)`. There is nothing record-specific about this ticket. It's just about using inferred equality constraints to simplify the inferred signature. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16070> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #15298: Support spliced function names in type signatures in TH declaration quotes
by GHC 24 Dec '18

24 Dec '18

#15298: Support spliced function names in type signatures in TH declaration quotes -------------------------------------+------------------------------------- Reporter: ntc2 | Owner: (none) Type: feature | Status: new request | Priority: normal | 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: #11129 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There doesn't seem to be a way to splice function names into type signatures in Template Haskell declaration quotes `[d|...|]`. For example, `fDecl1` below does not work. According to [https://stackoverflow.com/a/32279198/470844 this StackOverflow answer], the approach in `fDecl2` below used to work, but it doesn't work with recent GHCs and is much less readable than `fDecl1`. {{{#!hs {-# LANGUAGE TemplateHaskell #-} import Language.Haskell.TH fName :: Name fName = mkName "f" fTy :: TypeQ fTy = [t| Int |] fBody :: ExpQ fBody = [e| 3 |] -- | Not allowed: -- -- @ -- error: -- Invalid type signature: $fName :: ... -- Should be of form <variable> :: <type> -- @ -- -- Similarly, using @$(varP fName) :: $fTy@ fails with an analogous -- error. fDecl1 :: DecsQ fDecl1 = [d| $fName :: $fTy $(varP fName) = $fBody |] -- | Not allowed: -- -- @ -- error: -- Splices within declaration brackets not (yet) handled by Template Haskell -- @ fDecl2 :: DecsQ fDecl2 = [d| $((:[]) <$> sigD fName fTy) $(varP fName) = $fBody |] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15298> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #3379: GHC should use the standard binary package
by GHC 23 Dec '18

23 Dec '18

#3379: GHC should use the standard binary package -------------------------------------+------------------------------------- Reporter: igloo | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ulysses4ever): Hey, Ben, I missed the second part of your last post, unfortunately (read the email notification where it only shows the first version). I think there is an interesting design task here. You see, `Data.Binary` deals solely with serialization while GHC's Binary has serialization to the particular type of storage (`BinHandle` structure). As the first step, I think, we could factorize `GHC.Binary` to just use `Data.Binary` instead of trying to completely remove the former at once. For that, something like {{{#!haskell instance Data.Binary a => GHC.Binary a where ... }}} could work? My impression is that most of the instances of `GHC.Binary` are really boring, and all clever business is done directly with `BinHandle`s inside `Iface`-related modules. Discalaimer: I'm not totally sure what this `BinHandle`-related business is about. I read some Notes in the sources but didn't get much. The `IORef BinArray` part makes sense, but the rest… For now, I'm stuck with the error I listed above. Strangely enough, when doing `make test` on my brunch with `Data.Binary`-derived instance of `GHC.Binary ArgFlag`, I randomly get either that one error I mentioned above, or 518 errors (including the one above), all are with "bad stderr" or "bad stdout". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3379#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #16090: Typeset Big-O complexities with TeX-style notation in libraries/base
by GHC 23 Dec '18

23 Dec '18

#16090: Typeset Big-O complexities with TeX-style notation in libraries/base -------------------------------------+------------------------------------- Reporter: supersven | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: | Version: 8.6.3 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: -------------------------------------+------------------------------------- In the code review of #15003, @hvr proposed to typeset Big-Os in TeX-style instead of using italic (1). This will lead to a more idiomatic typesetting. See 2 for an example. **Task:** Replace all italic Big-Os in libraries/base with TeX-style notation. 1. - https://github.com/ghc/ghc/pull/239#discussion_r242167454 1. - https://hackage.haskell.org/package/text-containers-0.1.0.0/docs /Data-TextSet-Unboxed.html#v:size -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16090> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #16064: Improving Placement of Heap Checks - Avoiding Slowdowns in Hot Code
by GHC 23 Dec '18

23 Dec '18

#16064: Improving Placement of Heap Checks - Avoiding Slowdowns in Hot Code -------------------------------------+------------------------------------- Reporter: _recursion | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.9 Component: Compiler | Version: Keywords: CodeGen, | Operating System: Unknown/Multiple Performance | Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: #16040, #14791, | #8326, #12231, #1498 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When generating both heap and stack checks in Cmm, GHC can sometimes be fairly obtuse about their placement. As a result, they can be generated for paths in hot code that actually do not perform any allocation. Examples can be found in the related tickets, particularly #14791 and #16040. This ticket exists to track the work [https://ghc.haskell.org/trac/ghc/ticket/16040#comment:5 proposed] by Simon to detect such code patterns. They are described as follows: 1. A primitive case with no allocation upstream from it. 2. One alternative that performs no allocation. Under such circumstances the stack/heap checks can be moved from being performed on every iteration to being performed just prior to the allocation itself. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16064> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #16040: Unboxing-Related Performance Issue with Polymorphic Functions
by GHC 23 Dec '18

23 Dec '18

#16040: Unboxing-Related Performance Issue with Polymorphic Functions -------------------------------------+------------------------------------- Reporter: _recursion | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Keywords: | 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: -------------------------------------+------------------------------------- My team has observed a 2x performance degradation in code that makes use of `StateT` that appears to be related to strictness and unboxing, even when built with `-O2`. Our code makes heavy use of the state monad, and when GHC fails to optimise this performance We've managed to minimise the behaviour to the following reproducer (that ignores state entirely), consisting of two files. It depends on `criterion` `Lib.hs`: {{{#!hs {-# LANGUAGE BangPatterns #-} module Lib where -- A type to take the place of state data X a = X { runX :: !a } test1 :: Int -> Int test1 = \(!i) -> go i where go = \(!i) -> if i > 0 then go $! i - 1 else i {-# NOINLINE test1 #-} test2 :: Int -> Int test2 = \(!i) -> runX (go i) where go = \(!i) -> if i > 0 then go $! i - 1 else X i {-# NOINLINE test2 #-} }}} `Main.hs`: {{{#!hs {-# LANGUAGE Strict #-} module Main where import Lib import Criterion import Criterion.Main main :: IO () main = defaultMain [ bgroup "main" [ bgroup "small" [ bench "without state" $ whnf test1 100000000 , bench "with state" $ whnf test2 100000000 ] ] ] }}} Run as above, the code takes twice as long to execute `test2` as it does `test1`. However, when the signature for `runX` is changed to `runX :: !Int`, the code in `test2` exhibits identical performance to `test1`. It has been reproduced across multiple linux64 machines, but not tested on any other architecture or operating system. Please find the full (stack - yes, I know) project as an attachment. You can simply `stack run` to observe the issue. If you have any further queries please let me know. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16040> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #15274: Numerous validation failures when building GHC with LLVM
by GHC 23 Dec '18

23 Dec '18

#15274: Numerous validation failures when building GHC with LLVM -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (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: -------------------------------------+------------------------------------- The CircleCI x86_64/Linux LLVM way exhibits numerous testsuite failures: {{{ TEST="ClosedFam1TH T10508_api T10828 T10891 T11341 T11345 T11463 T11721_TH T11797 T12403 T12478_1 T12646 T12962 T13642 T13887 T14060 T1835 T2222 T2552 T2700 T3920 T4135 T4188 T5037 T5358 T5362 T5363 T5559 T680 T7477 T8761 T8884 T8953 T9064 T9262 T9692 TH_PromotedList TH_RichKinds TH_RichKinds2 TH_Roles3 TH_TyInstWhere2 TH_foreignCallingConventions TH_reifyDecl1 TH_reifyDecl2 TH_reifyInstances TH_repGuard TH_repPrim TH_repPrim2 TH_repUnboxedTuples posix002 prof-doc-fib prof-doc-last profinline001 prog001 scc001 scc002 scc003 scc005" }}} Unfortunately, most of these appear to be segmentation faults and similar, suggesting miscompilation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15274> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #12913: Port SplitSections to Windows
by GHC 22 Dec '18

22 Dec '18

#12913: Port SplitSections to Windows -------------------------------------+------------------------------------- Reporter: olsner | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8405 #13939 | Differential Rev(s): Phab:D3382 Wiki Page: | Phab:D3383 Phab:D3523 -------------------------------------+------------------------------------- Comment (by bgamari): I have opened #16084 to track the issue of link speed on Windows. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12913#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #16083: objcpp-hi test appears to be broken on Mojave builder
by GHC 22 Dec '18

22 Dec '18

#16083: objcpp-hi test appears to be broken on Mojave builder --------------------------------------+--------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- It appears that something has changed in the Darwin toolchain such that `<iostream>` is no longer found by default: {{{ cd "driver/recomp001/recomp001.run" && $MAKE -s --no-print-directory recomp001 Compile failed (exit code 1) errors were: warning: include path for stdlibc++ headers not found; pass '-std=libc++' on the command line to use the libc++ standard library instead [-Wstdlibcxx-not-found] objcpp-hi.mm:2:9: error: fatal error: 'iostream' file not found #import <iostream> ^~~~~~~~~~ 1 warning and 1 error generated. `gcc' failed in phase `C Compiler'. (Exit code: 1) *** unexpected failure for objcpp-hi(normal) }}} Marking as broken. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16083> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4