- ghc-tickets - Haskell.org

[GHC] #13721: posix004 test succeeds but then I get an Apple problem report window that says: "posix004 quit unexpectedly"
by GHC 18 May '17

18 May '17

#13721: posix004 test succeeds but then I get an Apple problem report window that says: "posix004 quit unexpectedly" -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.2.1-rc2 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- make TEST=posix004 {{{ results in ... cd "../../libraries/unix/tests/libposix/posix004.run" && ./posix004 SUMMARY for test run started at Thu May 18 18:21:52 2017 ADT 0:00:03 spent to go through 1 total tests, which gave rise to 10 test cases, of which 9 were skipped 0 had missing libraries 1 expected passes 0 expected failures 0 caused framework failures 0 caused framework warnings 0 unexpected passes 0 unexpected failures 0 unexpected stat failures }}} but then I get an Apple problem report window that says: "posix004 quit unexpectedly" Problem details and system configuration attached. This my be Mac specifc but leaving as unknown for now until we have more details -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13721> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #13720: INLINE pragma semantics changed since 8.0.2
by GHC 18 May '17

18 May '17

#13720: INLINE pragma semantics changed since 8.0.2 -------------------------------------+------------------------------------- Reporter: mpickering | 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: -------------------------------------+------------------------------------- It now seems that unfoldings for INLINE things are optimised slightly. This causes different interactions with `RULES` than before. {{{#!hs module A where {-# INLINE f #-} f x = h x h x = x {-# RULES "h x" forall x . h x = error "REWRITE" #-} }}} {{{#!hs module B where import A qux = f 5 }}} Then running {{{ > ghc-8.0.2 B.hs -O2 -fforce-recomp -ddump-simpl | grep qux -A5 qux :: Integer [GblId, Str=DmdType x] qux = error .... }}} {{{ > ghc-8.2.0.20170507 B.hs -O2 -fforce-recomp -ddump-simpl | grep qux -A5 qux :: Integer [GblId, Caf=NoCafRefs, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 100 0}] qux = 5 }}} Inspecting the unfoldings, we see that 8.2 optimises the unfoldings to inline `h` before the rule can apply. {{{ d61439f58ce9c5a268304423a43b9b44 f :: p -> p {- Arity: 1, HasNoCafRefs, Strictness: <S,1*U>, Inline: (sat-args=1), Unfolding: InlineRule (1, False, True) (\ @ p (x :: p) -> x) -} }}} Is this new behaviour intentional? It seems possible that it will break some programs which use rewrite rules. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13720> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8721: Testsuite not reporting errors for DYN way on OS X
by GHC 18 May '17

18 May '17

#8721: Testsuite not reporting errors for DYN way on OS X ------------------------------------+---------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.6.3 Keywords: dynamic linking | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+---------------------------- Using GHC 7.6.3, on OS X 10.8.5, for the program: `main = putStrLn "Hello World"`, compiling with `ghc --make -dynamic Main.hs`, I get: {{{ ~/Documents/devel/test$ ./Main dyld: Library not loaded: /usr/local/lib/ghc-7.6.3/base-4.6.0.1/libHSbase-4.6.0.1-ghc7.6.3.dylib Referenced from: /Users/christiaan/Documents/devel/test/./Main Reason: image not found Trace/BPT trap: 5 }}} The reason for this is that: * I installed GHC in: `/opt/ghc/7.6.3` instead of the default `/usr/local`. * GHC-bundled libraries get an OS X `install_name` with a prefix of `/usr/local/` instead of `/opt/ghc/7.6.3/`, meaning that the runtime linker will be looking in the wrong place. So, I wondered why this bug never showed in the testsuite and decided to test: {{{ /opt/ghc/7.6.3/src/ghc/testsuite (ghc-7.6)$ make WAY=dyn TEST=10queens … =====> 10queens(dyn) 1834 of 3403 [0, 0, 0] cd ./programs/10queens && '/opt/ghc/7.6.3/src/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package- db -rtsopts -fno-ghci-history --make -o 10queens Main -O -dynamic >10queens.comp.stderr 2>&1 cd ./programs/10queens && ./10queens </dev/null >10queens.run.stdout 2>10queens.run.stderr OVERALL SUMMARY for test run started at Fri Jan 31 09:42:45 CET 2014 3403 total tests, which gave rise to 13561 test cases, of which 0 caused framework failures 13560 were skipped 1 expected passes 0 had missing libraries 0 expected failures 0 unexpected passes 0 unexpected failures }}} However, when I run the `10queens` program myself: {{{ /opt/ghc/7.6.3/src/ghc/testsuite (ghc-7.6)$ tests/programs/10queens/10queens dyld: Library not loaded: /usr/local/lib/ghc-7.6.3.20130421/base-4.6.0.1/libHSbase-4.6.0.1-ghc7.6.3.20130421.dylib Referenced from: /opt/ghc/7.6.3/src/ghc/testsuite/tests/programs/10queens/10queens Reason: image not found Trace/BPT trap: 5 }}} I get a similar error as the one reported above. Due to commit f7be53ac9dac85b83e7fe5ecede01b98a572ba48, these errors will no longer show in GHC 7.8. However, I feel that the testsuite is now giving a false sense of security in terms of dynamic linking. Obviously dynamic linking was broken in 7.6, but the testsuite did not catch it! Sadly, this behaviour can now only be verified in the 7.6 branch, and not in 7.8 or HEAD. Hopefully somebody more knowledgeable of the testsuite can comment why dynamic linking worked when an executable was run "within" the testsuite, whilst being broken when run normally. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8721> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13717: Pattern synonym exhaustiveness checks don't play well with EmptyCase
by GHC 18 May '17

18 May '17

#13717: Pattern synonym exhaustiveness checks don't play well with EmptyCase -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1-rc1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms, | PatternMatchWarnings | Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In #8779, mpickering added a `COMPLETE` pragma to allow exhaustiveness checking for matches involving pattern synonyms. Unfortunately, there is still one piece missing: the interaction with `EmptyCase`. Suppose I write {{{#!hs newtype Fin (n :: Nat) = Fin Natural -- constructor not exported pattern FZ :: () => forall m. n ~ 'S m => Fin n pattern FS :: () => n ~ 'S m => Fin m -> Fin n {-# COMPLETE FZ, FS #-} }}} I would very much like to be able to write {{{#!hs finZAbsurd :: Fin 'Z -> Void finZAbsurd x = case x of }}} but this gives me a pattern coverage warning! That's certainly not what we want. I believe what we actually want is this: When checking empty case, check that ''at least one'' complete pattern set is impossible. In this case, it would see two complete pattern sets: the built-in `{Fin}` and the user-decreed `{FZ, FS}`. Since neither `FZ` nor `FS` have matching types, we should conclude that the empty case is fine. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13717> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13714: Guard pages instead of Heap/Stack limit checks in Cmm
by GHC 18 May '17

18 May '17

#13714: Guard pages instead of Heap/Stack limit checks in Cmm -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- Recently I have debugged a small program and I saw that there are a lot of Heap/Stack limit checks on function entrances ([https://ghc.haskell.org/trac/ghc/browser/ghc/rts/HeapStackCheck.cmm] This is not cheap and introduce more branch mispredictions and instructions. What you think if we use guard OS pages (that trigger exceptions when someone try to read/write on them) around Stack and Heap? Stack and Heap sizes should be aligned on page size (usually 4K) and with sizes that fits 4K pages. We could handle such exceptions so we could do GC if needed. This trick is usually found in some memory managers for finding out-of- bounds bugs. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13714> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13713: fdefer-type-errors makes missing import errors disappear
by GHC 18 May '17

18 May '17

#13713: fdefer-type-errors makes missing import errors disappear -------------------------------------+------------------------------------- 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: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #12529 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have this code {{{#!hs {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} import Data.Type.Equality ((:~:)(Refl)) import GHC.TypeLits import qualified Numeric.LinearAlgebra as LA import Numeric.LinearAlgebra.Static toVec :: forall n . (KnownNat n) => LA.Vector Double -> R n toVec vec = withVector vec $ \(v :: R n2) -> case sameNat (Proxy @n) (Proxy @n2) of Just Refl -> v Nothing -> error "wrong dimensions" }}} Notably I forgot to import `Proxy`. Without `-fdefer-type-errors` I get this error: {{{ ➤ nix-shell -p "haskellPackages.ghcWithPackages (pkgs:[pkgs.hmatrix])" --pure --run 'ghci ghc-8.0.2-proxy-confusing-error.hs' GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( ghc-8.0.2-proxy-confusing-error.hs, interpreted ) ghc-8.0.2-proxy-confusing-error.hs:12:60: error: Data constructor not in scope: Proxy ghc-8.0.2-proxy-confusing-error.hs:12:60: error: * Cannot apply expression of type `t1' to a visible type argument `n' * In the first argument of `sameNat', namely `(Proxy @n)' In the expression: sameNat (Proxy @n) (Proxy @n2) In the expression: case sameNat (Proxy @n) (Proxy @n2) of { Just Refl -> v Nothing -> error "wrong dimensions" } Failed, modules loaded: none. }}} but with `-fdefer-type-errors` the `Data constructor not in scope: Proxy` is gone! {{{ ➤ nix-shell -p "haskellPackages.ghcWithPackages (pkgs:[pkgs.hmatrix])" --pure --run 'ghci ghc-8.0.2-proxy-confusing-error.hs -fdefer-type-errors' GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( ghc-8.0.2-proxy-confusing-error.hs, interpreted ) ghc-8.0.2-proxy-confusing-error.hs:12:60: error: * Cannot apply expression of type `t1' to a visible type argument `n' * In the first argument of `sameNat', namely `(Proxy @n)' In the expression: sameNat (Proxy @n) (Proxy @n2) In the expression: case sameNat (Proxy @n) (Proxy @n2) of { Just Refl -> v Nothing -> error "wrong dimensions" } Failed, modules loaded: none. }}} This is probably related to #12529. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13713> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13712: Attach size to ForeignPtr
by GHC 17 May '17

17 May '17

#13712: Attach size to ForeignPtr -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- In some types of programs the dominant memory consumer is foreign objects whose lifetime is controlled by `ForeignPtr`s. In these cases the heuristics used by the GC don't reflect the true heap size of the process, meaning that garbage collection doesn't happen as often as it should. One suggested approach to alleviating this is to allow users to tell the GC about the size of the object represented by a `ForeignPtr`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13712> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7395: DefaultSignatures conflict with default implementations
by GHC 17 May '17

17 May '17

#7395: DefaultSignatures conflict with default implementations -------------------------------------+------------------------------------- Reporter: cgaebel | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: | DefaultSignatures Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: 7346 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Replying to [comment:19 aspiwack]: > I found myself, today, in a situation where I wanted to have two default signatures, something like: You might be interested in [https://gist.github.com/Icelandjack/e1ddefb0d5a79617a81ee98c49fbbdc4 an idea] I'm developing, {{{#!hs newtype WrapInt = WrapInt Int newtype WrapBool = WrapBool Bool instance Foo WrapInt where foo :: WrapInt foo = WrapInt 0 instance Foo WrapBool where foo :: WrapBool foo = WrapBool False }}} and you should be able to derive {{{#!hs newtype I = MkI Int deriving as WrapInt (Foo) newtype B = MkB Bool deriving as WrapBool (Foo) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7395#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11439: Request for comments: Allow duplicate type signatures
by GHC 17 May '17

17 May '17

#11439: Request for comments: Allow duplicate type signatures -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- Interested in feedback (Code inspired by [http://www.cs.ox.ac.uk/projects/utgp/school/idris-tutorial.pdf Idris tutorial]) {{{#!hs sum :: SBool single -> IsSingleton single -> Natural sum STrue x = x sum SFalse [] = 0 sum SFalse (x : xs) = x + sum SFalse xs }}} Allow duplicate type signatures: {{{#!hs sum :: SBool single -> IsSingleton single -> Natural sum :: SBool True -> Natural -> Natural sum STrue x = x sum :: SBool False -> [Natural] -> Natural sum SFalse [] = 0 sum SFalse (x : xs) = x + sum SFalse xs }}} Where {{{#!hs data SBool b where STrue :: SBool True SFalse :: SBool False type family IsSingleton (b :: Bool) :: Type where IsSingleton True = Natural IsSingleton False = [Natural] }}} ---- == Behaviour == You could do something fancy but I would be happy with a check that any duplicate type signature is a specialization of the ''top'' top-level one, this would allow something like this: {{{#!hs length :: [a] -> Int length :: [()] -> Int length [] = 0 length (_:xs) = 1 + length xs }}} Which isn't very useful, hah what ever. ---- == Benefits == Mainly compiler-checked documentation, for the `sum` function we make it clearer that a `STrue` gives you `Natural -> Natural` while `SFalse` gives you `[Natural] -> Natural`. This is most apparent in the final syntax idea: {{{#!hs sum :: SBool single -> IsSingleton single -> Natural @True :: _ -> Natural -> Natural @False :: _ -> [Natural] -> Natural }}} Reader need not look at definition of `IsSingleton`, it is fully described by the duplicate signatures. See ''lens'' where most functions have some kind of type specialisation declared in comments: [https://hackage.haskell.org/package/lens-4.13/docs /Control-Lens-Fold.html#v:-94--63- (^?)] whose type is `(^?) :: s -> Getting (First a) s a -> Maybe a`: {{{#!hs (^?) :: s -> Getter s a -> Maybe a (^?) :: s -> Fold s a -> Maybe a (^?) :: s -> Lens' s a -> Maybe a (^?) :: s -> Iso' s a -> Maybe a (^?) :: s -> Traversal' s a -> Maybe a }}} ---- == Alternative syntax == Throwing it out there, regardless of ambiguity: {{{#!hs sum :: SBool single -> IsSingleton single -> Natural :: SBool True -> Natural -> Natural sum STrue x = x :: SBool False -> [Natural] -> Natural sum SFalse [] = 0 sum SFalse (x : xs) = x + sum SFalse xs }}} or {{{#!hs sum :: SBool single -> IsSingleton single -> Natural ... :: SBool True -> Natural -> Natural sum STrue x = x ... :: SBool False -> [Natural] -> Natural sum SFalse [] = 0 sum SFalse (x : xs) = x + sum SFalse xs }}} or {{{#!hs sum :: SBool single -> IsSingleton single -> Natural ... @True :: _ -> Natural -> Natural sum STrue x = x ... @False :: _ -> [Natural] -> Natural sum SFalse [] = 0 sum SFalse (x : xs) = x + sum SFalse xs }}} or {{{#!hs sum :: SBool single -> IsSingleton single -> Natural @True :: _ -> Natural -> Natural sum STrue x = x @False :: _ -> [Natural] -> Natural sum SFalse [] = 0 sum SFalse (x : xs) = x + sum SFalse xs }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11439> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

Re: [GHC] #7395: DefaultSignatures conflict with default implementations
by GHC 17 May '17

17 May '17

#7395: DefaultSignatures conflict with default implementations -------------------------------------+------------------------------------- Reporter: cgaebel | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: | DefaultSignatures Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: 7346 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by aspiwack): I found myself, today, in a situation where I wanted to have two default signatures, something like: {{{#!haskell {-# LANGUAGE DefaultSignatures #-} module Test where class Foo a where foo :: a default foo :: (a~Int) => a foo = 0 default foo :: (a~Bool) => a foo = False }}} The practical situation was that the second default implementation requires an extra `MonadIO m` constraint and is more efficient. My proposal is to resolve default implementation like overlapping instances: the default with the most specific type amongst the well-typed ones is used. The compiler can check, when creating the class that default implementations of a same method either don't unify or are strictly ordered with the specialisation order. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7395#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0