February 2017 - ghc-tickets

[GHC] #10343: Make Typeable track kind information better
by GHC 22 Feb '17

22 Feb '17

#10343: Make Typeable track kind information better -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: 9858 Test Case: typeOf :: | Typeable (a::k) => Proxy a -> | TypeRep | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- With all the apparent exploitable bugs now fixed, #9858 seems to be settling down. Simon P.J. asked me to make a new ticket for some quibbles I still have with limitations of the new design. These started with some examples that I discussed there pre-implementation with Richard Eisenberg, and which he concluded could be supported by a "sufficently smart solver". In the new (current) design, a `TypeRep` ''does'' contain kind information, which as I understand it is a list of `KindRep`s for the explicit kind parameters applied to the type constructor after type inference. This is sufficient to prevent confusing the same type constructor used at different kinds, and also easily supports type application ''provided'' the `TypeRep`s of the parts are known. For this, the internal `Typeable` constraint solver only ever needs to combine `TypeRep`s, never decompose them. Since no one else complained in #9858, I assume this is enough for what people are currently using `Typeable` for. However: I think the current `TypeRep` representation for `Typeable (a :: k)` doesn't contain enough information to generally extract the `KindRep` for `k` itself, much less to decompose it, even if the internal `Typeable` solver were to try. This prevents some polykinded code that is intuitively sound, and which "worked" in the old system, although if only because it didn't try to track kinds at all. For example, the following expression, with `PolyKinds` enabled: {{{#!hs typeOf :: Typeable a => Proxy a -> TypeRep }}} In the old system, this worked simply by combining the `TypeRep` for `Proxy` with the `TypeRep` for `a`. But in the new system, it fails, because the `TypeRep` for `Proxy` needs to know the kind of `a`, which is neither statically known nor available from the `TypeRep` of `a`. You would need to have compile-time information about the type constructor of `a` to even know how to build the `KindRep` from the kind arguments. This problem with constructing `TypeRep`s would arise whenever a polykinded type constructor is applied to a type whose kind is not a known monomorphic one. The second similar one I can think of is {{{#!hs typeRep :: Typeable a => Proxy (Typeable a) -> TypeRep }}} In an ideal system, we can also find use cases that require not just extracting the `KindRep` for a type, but also decomposing it. Here is my very hypothetical kitchen sink example from [comment:46:ticket:9858] (this example was made up as a test case before I knew what the new solver would support): {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE AutoDeriveTypeable #-} import Data.Typeable newtype C a b = C () step :: Proxy (a :: [k] -> *) -> Proxy (C a :: [k -> *] -> *) step Proxy = Proxy nest :: Typeable (a :: [k] -> *) => Int -> Proxy a -> TypeRep nest 0 x = typeRep x nest n x = nest (n-1) (step x) main = print $ nest 10 (Proxy :: Proxy (C () :: [()] -> *)) }}} Here, to make this compile, the solver would need to derive `Typeable (C a :: [k -> *] -> *]` from `Typeable (a :: [k] -> *)`, which at runtime requires first extracting the `KindRep` of `k` from the `TypeRep` of `a`, and then building the `TypeRep` for the correctly kinded `C`. At least the former part seems essentially impossible with the current `TypeRep` representation, even with a more clever solver. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10343> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 38

[GHC] #13163: Make type import/export API Annotation friendly
by GHC 22 Feb '17

22 Feb '17

#13163: Make type import/export API Annotation friendly -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect API Unknown/Multiple | annotation Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- At the moment an export of the form {{{#!hs type C(..) }}} is parsed by the rule {{{ | 'type' oqtycon {% amms (mkTypeImpExp (sLL $1 $> (unLoc $2))) [mj AnnType $1,mj AnnVal $2] } }}} This means that the origiinal `oqtycon` loses its location which is then retained in the `AnnVal` annotation. The problem is if the `oqtycon` has its own annotations, these get lost. e.g. in {{{#!hs type (?)(..) }}} the parens annotations for `(?)` get lost. This can be solved by introducing a new `IE` constructor `IEVarType`, treated exactly the same as `IEVar` in the rest of the processing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13163> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13221: OccurAnal fails to rediscover join points
by GHC 22 Feb '17

22 Feb '17

#13221: OccurAnal fails to rediscover join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: JoinPoints | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Not clear why the warning from `OccurAnal` about rediscovering join points is ever firing. There's one circumstance I can think of, namely the special typing rule allowing jumps from β-redexes, but the warning fires repeatedly and β-redexes don't survive the simplifier. This isn't hard evidence of something wrong, but it indicates the occurrence analyzer may be missing something. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13221> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #11526: unsafeLookupStaticPtr should not live in IO
by GHC 22 Feb '17

22 Feb '17

#11526: unsafeLookupStaticPtr should not live in IO -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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.StaticPtr` provides {{{#!hs unsafeLookupStaticPtr :: StaticKey -> IO (Maybe (StaticPtr a)) }}} I don't think this function should live in IO. It is morally pure (the SPT that it needs to access is static for the duration of the program after all) and when this lives in IO this function cannot be used in `Binary` instances (without using `unsafePerformIO`, obviously). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11526> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #11817: Add proper support for weak symbols to the runtime linker
by GHC 22 Feb '17

22 Feb '17

#11817: Add proper support for weak symbols to the runtime linker -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Runtime | Version: 8.1 System (Linker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11223 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently weak symbols support is only partially supported by the runtime linker. The current support is mostly there to provide `COMDAT` support. In #11223 this support has been extended but there is still some work needed to finish weak symbols support. Also there needs some investigation into how this support should look like. E.g. are we only supporting linking weak symbols in C or do we want to support it in Haskell as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11817> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11011: Type-indexed TypeReps, Static Pointers and Distributed Closures
by GHC 22 Feb '17

22 Feb '17

#11011: Type-indexed TypeReps, Static Pointers and Distributed Closures -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 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: -------------------------------------+------------------------------------- There is a mock-up of a new API for type indexed type representations, basic Dynamic functionality, static pointers and distributed closures (https://github.com/brprice/typeableT) based on https://ghc.haskell.org/trac/ghc/wiki/TypeableT. We would like to invite comments and discussion from the community using this ticket as a more permenant home that email. One particular point that would benefit from more eyes is the polymorphic static pointers support. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11011> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 52

Re: [GHC] #11445: Turn on SplitSections by default
by GHC 22 Feb '17

22 Feb '17

#11445: Turn on SplitSections by default -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Build System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11285 Related Tickets: | Differential Rev(s): Phab:D1800 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: To get any further on this we would need to fix the Windows situation which won't be happening for 8.2. Bumping. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11445#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13312: GHC fatal error building Stack
by GHC 22 Feb '17

22 Feb '17

#13312: GHC fatal error building Stack -------------------------------------+------------------------------------- Reporter: Saish | Owner: (none) Type: bug | Status: new Priority: normal | 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: -------------------------------------+------------------------------------- stack upgrade --install-ghc Fetching package index ...remote: Counting objects: 11, done. remote: Compressing objects: 100% (9/9), done. remote: Total 11 (delta 3), reused 9 (delta 2), pack-reused 0 Unpacking objects: 100% (11/11), done. From https://github.com/commercialhaskell/all-cabal-hashes + 3568d98...c0c0122 hackage -> origin/hackage (forced update) t [tag update] current-hackage -> current-hackage Fetched package index. Populated index cache. aeson-1.0.2.1: configure aeson-1.0.2.1: build http-client-0.5.3.3: configure http-client-0.5.3.3: build pid1-0.1.0.0: configure pid1-0.1.0.0: build optparse-applicative-0.13.0.0: configure optparse-applicative-0.13.0.0: build pid1-0.1.0.0: copy/register store-core-0.3: configure store-core-0.3: build store-core-0.3: copy/register text-metrics-0.1.0: configure text-metrics-0.1.0: build text-metrics-0.1.0: copy/register th-orphans-0.13.1: configure th-orphans-0.13.1: build optparse-applicative-0.13.0.0: copy/register optparse-simple-0.0.3: configure optparse-simple-0.0.3: build th-orphans-0.13.1: copy/register th-utilities-0.2.0.1: configure th-utilities-0.2.0.1: build optparse-simple-0.0.3: copy/register http-client-0.5.3.3: copy/register http-client-tls-0.3.3: configure http-client-tls-0.3.3: build http-client-tls-0.3.3: copy/register th-utilities-0.2.0.1: copy/register store-0.3: configure store-0.3: build store-0.3: copy/register aeson-1.0.2.1: copy/register aeson-compat-0.3.6: configure aeson-compat-0.3.6: build binary-tagged-0.1.4.1: configure binary-tagged-0.1.4.1: build path-0.5.9: configure path-0.5.9: build http-conduit-2.2.3: configure aeson-compat-0.3.6: copy/register http-conduit-2.2.3: build persistent-2.6: configure persistent-2.6: build path-0.5.9: copy/register path-io-1.1.0: configure http-conduit-2.2.3: copy/register path-io-1.1.0: build yaml-0.8.20: configure yaml-0.8.20: build binary-tagged-0.1.4.1: copy/register path-io-1.1.0: copy/register yaml-0.8.20: copy/register hpack-0.15.0: configure hpack-0.15.0: build persistent-2.6: copy/register persistent-template-2.5.1.6: configure persistent-template-2.5.1.6: build persistent-sqlite-2.6: configure persistent-sqlite-2.6: build hpack-0.15.0: copy/register persistent-template-2.5.1.6: copy/register persistent-sqlite-2.6: copy/register stack-1.3.2: configure [1 of 1] Compiling Main ( /private/var/folders/g8/2ssh5dld40s209dhvk17hxlsx0b760/T/stack- upgrade32684/stack-1.3.2/Setup.hs, /private/var/folders/g8/2ssh5dld40s209dhvk17hxlsx0b760/T/stack- upgrade32684/stack-1.3.2/.stack- work/dist/x86_64-osx/Cabal-1.22.5.0/setup/Main.o ) Linking /private/var/folders/g8/2ssh5dld40s209dhvk17hxlsx0b760/T/stack- upgrade32684/stack-1.3.2/.stack- work/dist/x86_64-osx/Cabal-1.22.5.0/setup/setup ... Configuring stack-1.3.2... stack-1.3.2: build Preprocessing library stack-1.3.2... [ 1 of 121] Compiling Text.PrettyPrint.Leijen.Extended ( src/Text/PrettyPrint/Leijen/Extended.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Text/PrettyPrint/Leijen/Extended.o ) [ 2 of 121] Compiling Stack.Ghci.Script ( src/Stack/Ghci/Script.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/Ghci/Script.o ) [ 3 of 121] Compiling Stack.FileWatch ( src/Stack/FileWatch.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/FileWatch.o ) [ 4 of 121] Compiling System.Process.PagerEditor ( src/System/Process/PagerEditor.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/PagerEditor.o ) [ 5 of 121] Compiling System.Process.Log ( src/System/Process/Log.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/Log.o ) [ 6 of 121] Compiling Paths_stack ( .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/autogen/Paths_stack.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Paths_stack.o ) [ 7 of 121] Compiling Path.Find ( src/Path/Find.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Path/Find.o ) [ 8 of 121] Compiling Path.Extra ( src/Path/Extra.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Path/Extra.o ) [ 9 of 121] Compiling System.Process.Read ( src/System/Process/Read.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/Read.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/g8/2ssh5dld40s209dhvk17hxlsx0b760/T/ghc34708_0/libghc_57.dylib, 5): no suitable image found. Did find: /var/folders/g8/2ssh5dld40s209dhvk17hxlsx0b760/T/ghc34708_0/libghc_57.dylib: malformed mach-o: load commands size (48264) > 32768 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Completed 22 action(s). -- While building package stack-1.3.2 using: /private/var/folders/g8/2ssh5dld40s209dhvk17hxlsx0b760/T/stack- upgrade32684/stack-1.3.2/.stack- work/dist/x86_64-osx/Cabal-1.22.5.0/setup/setup --builddir=.stack- work/dist/x86_64-osx/Cabal-1.22.5.0 build lib:stack exe:stack --ghc- options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13312> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13289: Terrible loss of optimisation in presence of ticks
by GHC 22 Feb '17

22 Feb '17

#13289: Terrible loss of optimisation in presence of ticks -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: Profiling | 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 {{{ case (error "blah") of BIG }}} You'd expect that to simplify to `error "blah"`, or more precisely to `case error "blah" of {}`. And usually it does. But if there are ticks around it, it does not, and we retain {{{ case (tick x (error "blah")) of BIG }}} The problem is in `Simpify.simplTick`. It calls `splitCont` which implements semantics I do not understand. The Right Thing is surely this. * Always push the tick onto the continuation {{{ simplTick env tickish expr cont = simplExprF env expr (mkTickIt tickish cont) }}} * Implement a suitable `mkTickIt` that pushes a tick past a continuation where possible. For example I think {{{ mkTickIt t (ApplyTo arg cont) = ApplyTo arg (mkTickIt t cont) }}} That is `(tick t e) a` becomes `tick t (e a)`. It's probably conditioned on what sort of tick, but that's fine. * The comments from `7bb0447d` (simonmar) say {{{ -- XXX: we cannot do this, because the simplifier assumes that -- the context can be pushed into a case with a single branch. e.g. -- scc<f> case expensive of p -> e -- becomes -- case expensive of p -> scc<f> e -- -- So I'm disabling this for now. It just means we will do more }}} But that's wrong. All we need to do is to ensure that `prepareCaseCont` always stops at the kind of tick we don't want to push inside. * Finally, the bottom case of `rebuildCall` should retain ticks from the continuation. Not too hard, but requires understanding of the semantics of ticks, which I do not have. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13289> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13292: panic! (the 'impossible' happened): corePrepPgm
by GHC 22 Feb '17

22 Feb '17

#13292: panic! (the 'impossible' happened): corePrepPgm --------------------------------------+--------------------------------- Reporter: jeiea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- It doesn't seem like a serious problem, but I report it anyway. With stack's project template, I just removed `main` and `someFunc`'s type signature and changed `someFunc`'s definition to `return ()`. `stack build` worked well, but `stack repl` emitted this error message. {{{ D:\ghc-corePrepPgm\app\Main.hs:6:1: warning: [-Wdeferred-type-errors] • Couldn't match type ‘ghc-prim-0.5.0.0:GHC.Prim.Any’ with ‘IO’ Expected type: IO () Actual type: ghc-prim-0.5.0.0:GHC.Prim.Any () • In the expression: main When checking the type of the IO action ‘main’ ghc.EXE: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-mingw32): corePrepPgm [False] cobox_r1bo = typeError @ 'VoidRep @ (Any :: (* -> *)) ~# (IO :: (* -> *)) "D:\\ghc-corePrepPgm\\app\\Main.hs:6:1: error:\n\ \ \\226\\128\\162 Couldn't match type \\226\\128\\152ghc-prim-0.5.0.0:GHC.Prim.Any\\226\\128\\153 with \\226\\128\\152IO\\226\\128\\153\n\ \ Expected type: IO ()\n\ \ Actual type: ghc- prim-0.5.0.0:GHC.Prim.Any ()\n\ \ \\226\\128\\162 In the expression: main\n\ \ When checking the type of the IO action \\226\\128\\152main\\226\\128\\153\n\ \(deferred type error)"# Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13292> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9