- ghc-tickets - Haskell.org

[GHC] #13923: Add a suppression flag to stop Typeable bindings being emitted with -ddump-simpl
by GHC 11 Oct '18

11 Oct '18

#13923: Add a suppression flag to stop Typeable bindings being emitted with -ddump- simpl -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: low | 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: -------------------------------------+------------------------------------- When reading core output, it is very distracting to always have to wade through a large number of bindings generated by `Typeable`. In most cases I don't care about any of these so it would be easier if there was some way to stop them being printed or being generated in the first place. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13923> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15332: lintIdUnfolding could be simpler
by GHC 11 Oct '18

11 Oct '18

#15332: lintIdUnfolding could be simpler -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new 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: Differential Rev(s): Phab:D4919 | Wiki Page: -------------------------------------+------------------------------------- I think that `lintIdUnfolding` could use `maybeUnfoldingTemplate` rather than the complicated linting of `DFunUnfolding`. Seeing as `maybeUnfoldingTemplate` is the thing which is used when inlining, it makes sense to use that rather than some ad-hoc reconstruction. See https://phabricator.haskell.org/D4919 for the patch -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15332> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15734: ghc-heap package is not on hackage
by GHC 10 Oct '18

10 Oct '18

#15734: ghc-heap package is not on hackage -------------------------------------+------------------------------------- Reporter: mpickering | 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: -------------------------------------+------------------------------------- The documentation for ghc-heap is quite hidden away here: https://downloads.haskell.org/~ghc/latest/docs/html/libraries/ghc- heap-8.6.1/GHC-Exts-Heap.html It would be useful if it was on hackage so that it had better discoverability and was easier to browse the documentation like the normal `ghc` package. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15734> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #13128: Refactor AvailInfo to be more sensible
by GHC 10 Oct '18

10 Oct '18

#13128: Refactor AvailInfo to be more sensible -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: task | Status: new Priority: low | 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: -------------------------------------+------------------------------------- `AvailInfo` has been the bane of my life for the last 12 months and I want to tame it. There are two main problems with it. 1. There is this horrible invariant where if the parent is also exported then it is the first element of the list of children. 2. The set of children and field labels are represented as lists which means many expensive calls to functions from `ListSetOps`. 1 Is easy enough to solve by adding a flag which says whether the parent is exported or not. My naive attempt to solve the second problem was to replace the list by a `NameSet`. At the interface file boundary, the `NameSet` is converted into a list using `nameSetElemsStable` to maintain determinism and only pay the cost of using this expensive function once. This ran into problems in `RnModIface` where there are several functions which map over the list of children. NameSets don't support mapping and so this is difficult to implement in a satisfactory way. The next plan of attack is to distinguish between `IfaceAvailInfo` and `AvailInfo`. The former will use the old representation (lists) in order to maintain determinism but the latter will use sets. Distinguishing the two modes is useful conceptually and practically. The data type is used in quite a few different ways in lots of places which makes writing a nice interface hard. This ticket is to record my trail in case I don't make it to the end. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13128> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11368: Pattern synonym name is mangled when patterns are non-exhaustive
by GHC 10 Oct '18

10 Oct '18

#11368: Pattern synonym name is mangled when patterns are non-exhaustive ---------------------------------------+--------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.1 Keywords: PatternSynonyms | Operating System: Linux Architecture: x86 | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: #11367 Differential Rev(s): | Wiki Page: ---------------------------------------+--------------------------- {{{ pattern A n <- ... where A 0 = ... }}} When a pattern synonym is non-exhaustive its name is mangled: {{{ >>> A 3 "*** Exception: /tmp/tmp.t0h0pMgwWb.hs:(4,1)-(5,14): Non-exhaustive patterns in function $bA }}} “Non-exhaustive patterns in pattern synonym A” [https://ghc.haskell.org/trac/ghc/ticket/11367?replyto=5#comment:1 Comment] from ticket #11367. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11368> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10783: Partial type signatures should work with pattern synonym signatures
by GHC 10 Oct '18

10 Oct '18

#10783: Partial type signatures should work with pattern synonym signatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE PatternSynonyms #-} pattern MyJust :: _ pattern MyJust a = Just a }}} GHC can correctly infer the type for the pattern without the type signature so (to me) it is unexpected that this inferred type is not reported to me when using partial type signatures. It just seems to not be implemented currently. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10783> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15735: ghc-heap doesn't support profiling
by GHC 10 Oct '18

10 Oct '18

#15735: ghc-heap doesn't support profiling -------------------------------------+------------------------------------- Reporter: mpickering | 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: -------------------------------------+------------------------------------- ghc-heap should show an accurate representation of what's on the heap. When profiling is enabled the profiling header is just completely ignored and not represented in the `StgInfoTable`. https://downloads.haskell.org/~ghc/latest/docs/html/libraries/ghc- heap-8.6.1/GHC-Exts-Heap.html#t:StgInfoTable A new field should be added to `StgInfoTable` with type `Maybe ProfilingHeader` just like we already have for tables next to code. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15735> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15731: Add sortOn/coerce rule
by GHC 10 Oct '18

10 Oct '18

#15731: Add sortOn/coerce rule -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.8.1 Component: Core | Version: 8.6.1 Libraries | 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: -------------------------------------+------------------------------------- When the argument to `sortOn` is very cheap, we're better off ''not'' decorating the list. Detecting this is not easy in general, but it's trivial for coercions. We should probably offer something like {{{#!hs {-# RULES "sortOn/coerce" forall b xs. sortOn @_ @b coerce xs = sortWith (coerce @_ @b) xs #-} }}} As far as I can tell, we can't use type application directly like that, but we can go via `Proxy#`. `PrelRules` could do better, of course, catching selector functions, but I don't think we want to go that far. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15731> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15728: Program with safe array operations triggers debug runtime assertion
by GHC 10 Oct '18

10 Oct '18

#15728: Program with safe array operations triggers debug runtime assertion -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.6.1 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: -------------------------------------+------------------------------------- I'll try to minimize later. Main.hs: {{{ {-# LANGUAGE ForeignFunctionInterface #-} import Control.Monad import Control.Monad.ST import Data.Primitive.Array import Data.Primitive.ByteArray import Data.Primitive.SmallArray import System.Environment import System.Mem import Foreign.C data A arr = A !Int arr enumSmallArray :: Int -> A (SmallArray Int) enumSmallArray n = runST $ do arr <- newSmallArray n 0 forM_ [1..n] $ \i -> writeSmallArray arr i i iarr <- freezeSmallArray arr 0 n return (A n iarr) consumeSmallArray :: A (SmallArray a) -> a consumeSmallArray (A n arr) = indexSmallArray arr (n - 1) enumArray :: Int -> A (Array Int) enumArray n = runST $ do arr <- newArray n 0 forM_ [1..n] $ \i -> writeArray arr i i iarr <- freezeArray arr 0 n return (A n iarr) consumeArray :: A (Array a) -> a consumeArray (A n arr) = indexArray arr (n - 1) foreign import ccall "printInt" printInt :: CInt -> IO () main :: IO () main = do n <- (\[s] -> read s) <$> getArgs ints <- forM [1..n] $ \i -> do let x = consumeSmallArray (enumSmallArray 12) y = consumeArray (enumArray i) case x+y of r -> when (i `mod` 5000 == 0) performMajorGC >> return r printInt (fromIntegral (sum ints)) }}} print.c: {{{ #include <stdio.h> void printInt(int i) { printf("Result: %d\n", i); } }}} Compile: {{{ $ ghc Main.hs print.c -debug Linking Main ... }}} Run: {{{ array_bug $ ./Main 1000 +RTS -DS Main: internal error: ASSERTION FAILED: file rts/sm/Storage.c, line 960 (GHC version 8.6.1 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./Main 1000 +RTS -DS }}} Tried with: 8.4.3, 8.6.1. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15728> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #15730: SCC/HPC/CORE annotation can change the meaning of an expression
by GHC 10 Oct '18

10 Oct '18

#15730: SCC/HPC/CORE annotation can change the meaning of an expression -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.6.1 (Parser) | 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: -------------------------------------+------------------------------------- Consider this GHCi session: {{{ Prelude> 1 / 2 / 2 0.25 Prelude> 1 / {-# SCC ann #-} 2 / 2 1.0 }}} Adding an SCC annotation changed the meaning of the expression. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15730> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6