July 2017 - ghc-tickets

[GHC] #13430: Can't scope type variables when pattern matching on GADTs
by GHC 27 Jul '17

27 Jul '17

#13430: Can't scope type variables when pattern matching on GADTs -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I was very surprised that the following doesn't compile: {{{ {-# LANGUAGE GADTs, ScopedTypeVariables #-} data Foo x where A :: Foo Bool B :: Foo Int foo :: Foo x -> () foo (A :: Foo Bool) = () }}} GHC says that it couldn't match the type `y` with `Bool`. See [this question](http://stackoverflow.com/questions/42824949/type-inference-with- gadts) for a simple motivating example. As someone there pointed out, the situation would be improved with type application (#11350), but this ticket is about bringing the output type in scope with `ScopedTypeVariables`. This most closely reminds me of #1823 (!), but that was resolved many moons ago. This behavior also exists in 7.10.3. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13430> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13940: Reduce duplicate implementations of argument handling on Windows
by GHC 27 Jul '17

27 Jul '17

#13940: Reduce duplicate implementations of argument handling on Windows ----------------------------------------+--------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: low | Milestone: Component: Runtime System | Version: Keywords: unicode windows | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #12870 Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- On windows we currently ignore arguments to hs_init/main's argv and instead get the arguments from the windows api when they are requested from the Haskell side. This means * Passing custom arguments to hs_init when not using hs_main might behave unexpected (The haskell und RTS side see different arguments). * Duplication of code to simulate filtering of Arguments by the RTS on the Haskell side. * Behavior between Linux and Windows might differ as result of the above (eg #13287) Instead we can get the UTF16 encoded arguments inside of hs_main from the windows API and pass them along to the RTS UTF8-encoded. This allows argument handling to be fairly uniform between Linux and Windows and enables us to accept hs_init arguments on Windows. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13940> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12369: data families shouldn't be required to have return kind *, data instances should
by GHC 27 Jul '17

27 Jul '17

#12369: data families shouldn't be required to have return kind *, data instances should -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 (Type checker) | 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'd like to be able to define {{{#!hs {-# language PolyKinds, KindSignatures, GADTs, TypeFamilies #-} data family Fix :: (k -> *) -> k newtype instance Fix f = In { out :: f (Fix f) } }}} But currently this is disallowed: {{{ Fix.hs:2:1: error: • Kind signature on data type declaration has non-* return kind (k -> *) -> k • In the data family declaration for ‘Fix’ }}} Ultimately I think the issue here is that data __instances__ should be required to end in kind *, not the families, but this generalization didn't mean anything until we had `PolyKinds`. As an example of a usecase, with the above, I could define a bifunctor fixed point such as {{{#!hs newtype instance Fix f a = In2 { out2 :: f (Fix f a) a } }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12369> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #14031: Linker paths carry substantial N*M overhead when many libaries are used
by GHC 27 Jul '17

27 Jul '17

#14031: Linker paths carry substantial N*M overhead when many libaries are used -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- **"The linker search path problem"** It's common these days to have 400 (transitive) Hackage dependencies (even my hobby projects have that many). When linking, statically or dynamically, GHC passes `-L /path/to/foo/dir` and `-L HSfoo...` to the linker for each Haskell package `foo`. That results in `N` many linker search paths (`-L`) and `M` many library names. That will translate in `N * M` many `stat()` syscalls (file existence checks) in the linker to check where each file is. For 400 package dependencies, that translates to 160k `stat()` syscalls. On my machine (on SSD and hot file system cache in RAM), that takes `0.7 seconds` (measured with `strace -c -w`). That is a substantial overhead for linking (for example, the executable with 400 dependencies with which I found this problem can be linked with `ld.gold` in just 1.5 seconds). If there is tooling in between GHC and the linker that also parses linker flags and checks for file existence (for example Nix's `cc-wrapper` and `ld-wrapper` scripts, or other instrumentation or build system tooling, which are often not written in compiled languages and thus [https://github.com/NixOS/nixpkgs/issues/27609 much slower] at stat()ing than the linker is), then the problem can be easily blown up another 10x. As a result, you may be waiting a lot longer for your link to finish than necessary. For static linking, this could be resolved by passing the archive files (`libHSfoo....a`) directly to the linker instead of the `-L`/`-l` combination. For this we would need to check that passing files directly really have the same semantics as `-L` and `-l`, but the man pages suggest so (and I'll check it with the binutils authors). For dynamic linking, it cannot be fixed this way. It can be fixed at compile time, but with dynamic linking the same problem exists at run-time (startup): Here all the `-L`s become `RPATH`s if not installed in a global location (for example, nix has an `RPATH` for each package), and thus program startup can take up to those 0.7 seconds I mentioned. To solve the runtime problem, the only solution seems to be to place the libraries into the same directory (i.e. to have `M = 1` essentially). This approach (putting all libs into 1 directory) would also solve it for the static linking case, with the drawback of this being not compatible with how cabal sandboxes, stack build and snapshot dirs, nix, Debian and other distributions deliver and build libraries. And for some of them this approach goes straight against their nature. **Detail discussion:** See below the relevant discussion on #ghc: {{{ nh2: bgamari-: do you know why ghc uses -L and -l for linking libHS... things instead of passing the .a file directly? hvr: nh2: btw, fun fact: on IBM AIX, both static and DSOs are stored in .a archives bgamari-: nh2, I suspect just since it makes the dynamic and static linking codepaths consistent hvr: nh2: and if you use .a for linking, you end up hardwiring the DSO path into your executable nh2: bgamari-: I'm looking into whether it would make sense to change it, at least for the platforms that would support it, because the (-L * -l) searching that it does currently seems to dominate link times here nh2: cc hvr hvr: nh2: sounds reasonable; but then you end up with longer CLI arguments hvr: nh2: it could be a problem for when the tools don't support @ bgamari-: nh2, seriously? bgamari-: the search is really that long? bgamari-: nh2, it seems like that's a linker bug hvr: bgamari-: I guess it depends on how many -L there are bgamari-: nh2, how many libraries are you linking against? hvr: bgamari-: as each -L and -l multiply w/ each other requiring several stat() calls iirc bgamari-: hvr, yes hvr: but otoh, I wouldn't expect this to *dominate* linker times bgamari-: right bgamari-: hvr, this is the compile-time equivalent to #11587 bgamari-: which I still think we should do hvr: right bgamari-: hmm bgamari-: although comment:9 sort of suggests that this is already the case for user-installed libraries ***bgamari- forgot about that hvr: I mean, if you have really *many* -L-paths hvr: then the quadratic effect becomes probably significant bgamari-: right bgamari-: nh2, how many libraries are you linking against? nh2: bgamari-: I have approximately L=450 and l=350. There is some notoriously slow tooling "in between" that I'm currently investigating, namely nix's ld-wrapper, which does does the stat'ing in bash, where statting that many files easily takes 1 second, but I did a quick test with `xargs ls -1` on the "$DIR/lib${name}.a" expansion, an that too takes 1 second, so it might not be entirely its fault hvr: ok, ~400 is quite a bit bgamari-: sheesh bgamari-: yes, that is... impressive geekosaur: next they'll want this to work on macOS >.. geekosaur: >.> hvr: and then windows! nh2: even my hobby projects have 300 recursive deps by now nh2: bgamari-: my strace says that `ls` did the 160k stat()s in 0.7 seconds, which is half of the time that `gold` needs to link my binary nh2: bgamari-: I have now strace'd `ld` itself, that does it slightly faster, 0.5 seconds, but this is just because it's my hobby project and has "only" that many deps; for a real project that'd be 2 seconds just stat()ing bgamari-: nh2, sheesh nh2: bgamari-: of course nix's ld wrapper, being written in bash, does the same thing but at least 5x slower bgamari-: nh2, do you just add all of Hackage to your build-depends? ;) bgamari-: nh2, Instead of passing explicit paths I think I would rather just put all of the archives in LIBDIR nh2: bgamari-: I blame it on my dependees ;) also, "Haskell has high-quality libraries and encourages code reuse" comes back at us here bgamari-: although, admittedly, I haven't really thought through the consequences of this yet bgamari-: this does sound like a worthwhile thing to fix though bgamari-: that is a significant amount of time nh2: bgamari-: personally I'd WAY prefer explicit args vs env vars because then I can see them in ps, I can easily replay the specific command myself to debug it etc hvr: nh2: not every library on Hackage is "high-quality" ;-) bgamari-: I had always assumed that our large linking times we due to, well, the "linking" bgamari-: not just the stating bgamari-: nh2, fair enough, but I'd rather not have to add even more platform-dependent behavior to our interaction with the system toolchain bgamari-: oh, wait bgamari-: nh2, I didn't mean to pass via env var bgamari-: nh2, I just meant pass one -L bgamari-: nh2, where the static and dynamic libraries can both be bgamari-: found nh2: bgamari-: I don't know that, where can I read about that? Is it a flag? bgamari-: nh2, -L? bgamari-: it's just the usual --library-path flag nh2: bgamari-: I got confused by LIBDIR in caps bgamari-: ah bgamari-: right, I should have been more specific nh2: bgamari-: so what do you mean by that, somehow put all the libraries into a single dir? bgamari-: nh2, treat static archives the same way we treat dynamic libraries bgamari-: which is to place them in, e.g., $HOME/.cabal/lib/$ghc_version/ bgamari-: instead of where they are currently, $HOME/.cabal/lib/$ghc_version/$library_abi_name bgamari-: then you can just pass -L$HOME/.cabal/lib/$ghc_version to ld bgamari-: and a -l for each library bgamari-: I think this is probably as much a Cabal change as it is a GHC change nh2: bgamari-: that doesn't seem to go well with approaches that package separately, like debian, nix, cabal sandboxes and stack work dirs hvr: which includes new-build bgamari-: I'm not sure it's fundamentally incompatible hvr: yeah, but it's a lot of work to change everyone :-) bgamari-: to take the case of new-build, all that matters AFAIK is that the packages are registered in separate package dbs bgamari-: there's nothing stopping you from throwing all of the libraries into one directory hvr: bgamari-: well, I kinda exploit that new-build has nicely self-contained folders hvr: this makes it easier to atomically move around artifacts nh2: bgamari-: do you have a dislike for passing them explicitly as files beyond cross-platform worries? Because I really find explicit arguments the cleanest, easiest and most debuggable approach hvr: as I can stage the new artifact, and then move it into place hvr: atomically hvr: by simply renaming/moving the folder which contains everyting bgamari-: nh2, I'm just currently really not sure that passing libraries by path is really equivalent to passing via -l hvr: unfortauntely filesytems don't offer many other facilities for atomic transactions bgamari-: I would need to run some experiments nh2: bgamari-: gcc's and ld's man pages suggest that to me, looking at their respective `-l`; we certainly should double check (or maybe simpler, ask the linker authors) bgamari-: if we can really show that the linker treats explicit paths no differently then I'd be okay with it nh2: suggests that they are equivalent) bgamari-: but I'm rather weary bgamari-: nh2, are you only suggesting this for static libraries? geekosaur: it's supposed to be equivalent. but shared objects have the added issue of runtime discoverability (i.e. passing by full path at link time does not install a full path for runtime access) geekosaur: except on macos or older aix where it's always a full path) nh2: bgamari-: no, at least the stat()-taking-time problem is the same problem for .so's (though I'm using static linking in many places and would be appreciate an improvement even if limited to static linking) bgamari-: nh2, the problem is that your approach doesn't help dynamic linkage at all bgamari-: since the runtime linker still needs to search N paths bgamari-: so I would argue that new-build, stack, etc. really should be putting libraries in the same directory regardless bgamari-: more work or not bgamari-: it's the only way to truly solve the problem mpickering: Wonders if David saw this issue https://github.com/haskell/cabal/issues/4550 alanz: mpickering: what are you planning to use the source plugins for? nh2: bgamari-: yeah you're right, the start-up cost of the executable will always be there for dynamic linking, I was purely talking from the compiler's perspective bgamari-: nh2, my point was that I would prefer to solve the problem once and for all bgamari-: rather than have another sharp edge that we then still need to solve bgamari-: given that moving the libraries solves both problems, it feels like the right solution mpickering: alanz: haskell-indexer was the plan nh2: bgamari-: I agree that for dynamic linking that is the only solution. But I'm not sure there exist a fits-it-all solution across static and dynamic. At least for my work, I'd prefer to have static libs that can be anywhere, in nix-style immutable locations, and give up on dynamic linking (of Haskell libs) to get that. It seems that hvr's thoughts are going in the same direction on the cabal side, and lots of build system and OS movements these days seem to converge away from global shared dirs to dir-prefixes. nh2: I also suspect that static linking will be even more attractive now that sensible -split-sections is in place, which can give smaller code sizes, which .so's can't deliver. nh2: So I'm not sure that a big shift to the fits-it-all solution that satisfies dynamic linking needs would be the most practical or used; it'd certainly be nice to have it for dynamic linking, but I'm not sure all the downstreams can be forced to do it that way for non-static if it quite fundamentally dictates how they have to work. If they can, it would probably take pretty long. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14031> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14039: Add ability to install libraries bundled with ghc into separate prefixes
by GHC 27 Jul '17

27 Jul '17

#14039: Add ability to install libraries bundled with ghc into separate prefixes -------------------------------------+------------------------------------- Reporter: shlevy | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Build System | 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: -------------------------------------+------------------------------------- Currently, if I build an executable dynamically linked to 'base' and 'rts' with nix, I am forced to bring the ghc binary and, say, 'hoopl' along at runtime because these are all installed into the same prefix. Having options to indpendently specify output prefixes for each of the libraries would allow us to significantly decrease closure sizes. Ben Gamari suggests this may be doable in the new Hadrian build. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14039> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13610: Unhelpful error messages about lifted and unlifted types
by GHC 27 Jul '17

27 Jul '17

#13610: Unhelpful error messages about lifted and unlifted types -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | 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 wrote this code: {{{ {-# LANGUAGE MagicHash #-} import GHC.Prim import GHC.Types main = do let primDouble = 0.42## :: Double# let double = 0.42 :: Double IO (\s -> mkWeakNoFinalizer# double () s) }}} and I get this error message: {{{ WeakDouble.hs:8:15: error: • Couldn't match a lifted type with an unlifted type Expected type: (# State# RealWorld, Weak# () #) Actual type: (# State# RealWorld, Weak# () #) • In the expression: mkWeakNoFinalizer# double () s In the first argument of ‘IO’, namely ‘(\ s -> mkWeakNoFinalizer# double () s)’ In a stmt of a 'do' block: IO (\ s -> mkWeakNoFinalizer# double () s) }}} with `-fprint-explicit-kinds`. (Without the flag, it looks the same, but tells me to use this flag…). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13610> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #11560: panic: isInjectiveTyCon sees a TcTyCon
by GHC 27 Jul '17

27 Jul '17

#11560: panic: isInjectiveTyCon sees a TcTyCon -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I typed this into ghci and it panicked. Not sure whether the declaration is really valid anyways, but ghci shouldn't panic on it. {{{ rwbarton@morphism:~/ghc-newest$ ./inplace/bin/ghc-stage2 --interactive GHCi, version 8.1.20160201: http://www.haskell.org/ghc/ :? for help Prelude> :set -XTypeFamilies -XTypeInType Prelude> :m +Data.Kind Prelude Data.Kind> type family T (l :: *) (k :: l) :: * where { T * Int = * } ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20160201 for x86_64-unknown-linux): isInjectiveTyCon sees a TcTyCon T Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11560> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #11672: Poor error message
by GHC 27 Jul '17

27 Jul '17

#11672: Poor error message -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: adamgundry Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 (Type checker) | Keywords: ErrorMessages | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: #11198 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- [https://mail.haskell.org/pipermail/haskell-cafe/2016-February/123262.html Daniel Díaz recently pointed out] a particularly terrible error message. Here's a reduced example: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE KindSignatures #-} module BadError where import GHC.TypeLits import Data.Proxy f :: Proxy (a :: Symbol) -> Int f _ = f (Proxy :: Proxy (Int -> Bool)) }}} With GHC 8.0 RC2, this leads to the following error: {{{ • Expected kind ‘Proxy ((->) Int Bool)’, but ‘Data.Proxy.Proxy :: Proxy (Int -> Bool)’ has kind ‘Proxy (Int -> Bool)’ • In the first argument of ‘f’, namely ‘(Proxy :: Proxy (Int -> Bool))’ In the expression: f (Proxy :: Proxy (Int -> Bool)) In an equation for ‘f’: f _ = f (Proxy :: Proxy (Int -> Bool)) }}} or with `-fprint-explicit-kinds -fprint-explicit-coercions`: {{{ • Expected kind ‘Proxy Symbol (((->) |> <*>_N -> <*>_N -> U(hole:{aCy}, *, Symbol)_N) Int Bool)’, but ‘(Data.Proxy.Proxy) @ k_aCv @ t_aCw :: Proxy (Int -> Bool)’ has kind ‘Proxy * (Int -> Bool)’ }}} As Iavor, Richard and I discussed, this message has at least three separate problems: * It says `kind` when it should say `type`. * `((->) Int Bool)` is printed instead of `Int -> Bool` (because there is a coercion hiding in the type). * The real error is the insoluble constraint `Symbol ~ *`, which is not reported at all! The first two should be fairly easy to fix. For the third, when reporting insoluble constraints, we should prefer to report those on which no other constraints depend. (In this case, the presence of `hole:{aCy}` in the constraint is an explicit dependency on the other constraint.) I'll try to take a look at this. It is no doubt related to #11198. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11672> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13530: Horrible error message due to TypeInType
by GHC 27 Jul '17

27 Jul '17

#13530: Horrible error message due to TypeInType -------------------------------------+------------------------------------- Reporter: simonpj | 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: -------------------------------------+------------------------------------- Consider this {{{ {-# LANGUAGE MagicHash, UnboxedTuples #-} module Foo where import GHC.Exts g :: Int -> (# Int#, a #) g (I# y) = (# y, undefined #) f :: Int -> (# Int#, Int# #) f x = g x }}} With GHC 8 we get {{{ Foo.hs:11:7: error: • Couldn't match a lifted type with an unlifted type Expected type: (# Int#, Int# #) Actual type: (# Int#, Int# #) }}} What a terrible error message!! It was much better in GHC 7.10: {{{ Foo.hs:11:7: Couldn't match kind ‘*’ with ‘#’ When matching types a0 :: * Int# :: # Expected type: (# Int#, Int# #) Actual type: (# Int#, a0 #) }}} What's going on? The constraint solver sees {{{ [W] alpha::TYPE LiftedRep ~ Int#::TYPE IntRep }}} So it homogenises the kinds, ''and unifies alpha'' (this did not happen in GHC 7.10), thus {{{ alpha := Int# |> TYPE co [W] co :: LiftedRep ~ IntRep }}} Of course the new constraint fails. But since we have unified alpha, when we print out the types are are unifying they both look like `(# Int#, Int# #)` (there's a suppressed cast in the second component). I'm not sure what to do here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13530> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12373: Type error but types match
by GHC 27 Jul '17

27 Jul '17

#12373: Type error but types match -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | 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: -------------------------------------+------------------------------------- {{{ > unboxedsums git:(prim_sums_rebase_5) x cat primop_bug.hs {-# LANGUAGE MagicHash, ScopedTypeVariables, UnboxedTuples #-} module Main where import GHC.MVar import GHC.Prim import GHC.Types main :: IO () main = IO (\rw -> newMVar# rw) >> return () > unboxedsums git:(prim_sums_rebase_5) x ghc-stage1 primop_bug.hs -ddump- stg -ddump-cmm -ddump-to-file -fforce-recomp -dumpdir primop_fails -O -fprint-explicit-kinds [1 of 1] Compiling Main ( primop_bug.hs, primop_bug.o ) primop_bug.hs:10:19: error: • Couldn't match a lifted type with an unlifted type Expected type: (# State# RealWorld, MVar# RealWorld a0 #) Actual type: (# State# RealWorld, MVar# RealWorld a0 #) • In the expression: newMVar# rw In the first argument of ‘IO’, namely ‘(\ rw -> newMVar# rw)’ In the first argument of ‘(>>)’, namely ‘IO (\ rw -> newMVar# rw)’ }}} Tried with HEAD, 8.0.1. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12373> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5