- ghc-devs - Haskell.org

globalRegMaybe and ARM
by Ben Gamari 04 Aug '14

04 Aug '14

Hello Simon, b0534f7 [1] and the subsequent reversion f0fcc41d7 touched `includes/CodeGen.Platform.hs`, the former removing a panic in the case of `globalRegMaybe` being undefined for a platform and replacing it with `Nothing`. Recently I've found that my ARM builds (with -fllvm) crash at this panic whereas they did not as of the 7.8 release. Given that b0534f7 was reverted this is no doubt due to another change that I haven't identified yet. Do you have any idea what is happening here? I'm currently attempting to build with a workaround setting `globalRegMaybe _ = Nothing`, although this smells suspicously like what would happen in the unregisterized case. My other hypothesis is that MACHREGS_arm should be added to the #if MACHREGS_i386 || MACHREGS_x86_64 || MACHREGS_sparc || MACHREGS_powerpc which smells more like what a registerised architecture should do and it seems the requisite macros are defined for ARM in `stg/MachRegs.h`. Whatever happens for ARM should probably also happen for AArch64. How should `globalRegMaybe` and `freeReg` be defined for platforms that rely exclusively on the LLVM backend? Both ARM and AArch64 appear to be doing the wrong thing at present. Cheers, - Ben [1] https://github.com/ghc/ghc/commit/b0534f78a73f972e279eed4447a5687bd6a8308e#…

2 1

RE: [commit: ghc] master: Dont allow hand-written Generic instances in Safe Haskell. (578fbec)
by Simon Peyton Jones 04 Aug '14

04 Aug '14

David Thanks for doing this. I'm a bit concerned, though, that there is quite a bit of Safe-Haskell special-casing in GHC, but no single place to look for a list of what the choices are, and why they are made. Even the paragraph you wrote as a commit comment would make a helpful Note to accompany the code changes. The worry is that in five years time someone will look at this code and wonder "why exactly is this special case there?". They may look in the paper, but Generics post-dates it. Would it be worth Wiki page to collect the choices? Or more detailed Notes with the individual tests? Thanks Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of | git(a)git.haskell.org | Sent: 02 August 2014 03:06 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Dont allow hand-written Generic | instances in Safe Haskell. (578fbec) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | http://ghc.haskell.org/trac/ghc/changeset/578fbeca31dd3d755e24e910c3a73 | 27f92bc4ee3/ghc | | >--------------------------------------------------------------- | | commit 578fbeca31dd3d755e24e910c3a7327f92bc4ee3 | Author: David Terei <code(a)davidterei.com> | Date: Thu Dec 5 17:27:17 2013 -0800 | | Dont allow hand-written Generic instances in Safe Haskell. | | While they aren't strictly unsafe, it is a similar situation to | Typeable. There are few instances where a programmer will write | their | own instance, and having compiler assurance that the Generic | implementation is correct brings a lot of benefits. | | | >--------------------------------------------------------------- | | 578fbeca31dd3d755e24e910c3a7327f92bc4ee3 | compiler/prelude/PrelNames.lhs | 3 +++ | compiler/typecheck/TcInstDcls.lhs | 31 +++++++++++++++++++++---------- | 2 files changed, 24 insertions(+), 10 deletions(-) | | diff --git a/compiler/prelude/PrelNames.lhs | b/compiler/prelude/PrelNames.lhs index 2c84e40..b2dec88 100644 | --- a/compiler/prelude/PrelNames.lhs | +++ b/compiler/prelude/PrelNames.lhs | @@ -1084,6 +1084,9 @@ datatypeClassName = clsQual gHC_GENERICS | (fsLit "Datatype") datatypeClassK | constructorClassName = clsQual gHC_GENERICS (fsLit "Constructor") | constructorClassKey | selectorClassName = clsQual gHC_GENERICS (fsLit "Selector") | selectorClassKey | | +genericClassNames :: [Name] | +genericClassNames = [genClassName, gen1ClassName] | + | -- GHCi things | ghciIoClassName, ghciStepIoMName :: Name ghciIoClassName = clsQual | gHC_GHCI (fsLit "GHCiSandboxIO") ghciIoClassKey diff --git | a/compiler/typecheck/TcInstDcls.lhs b/compiler/typecheck/TcInstDcls.lhs | index c3ba825..6ff8a2b 100644 | --- a/compiler/typecheck/TcInstDcls.lhs | +++ b/compiler/typecheck/TcInstDcls.lhs | @@ -51,8 +51,8 @@ import VarEnv | import VarSet | import CoreUnfold ( mkDFunUnfolding ) | import CoreSyn ( Expr(Var, Type), CoreExpr, mkTyApps, mkVarApps ) | -import PrelNames ( tYPEABLE_INTERNAL, typeableClassName, | oldTypeableClassNames ) | - | +import PrelNames ( tYPEABLE_INTERNAL, typeableClassName, | + oldTypeableClassNames, genericClassNames ) | import Bag | import BasicTypes | import DynFlags | @@ -415,13 +415,16 @@ tcInstDecls1 tycl_decls inst_decls deriv_decls | -- hand written instances of old Typeable as then unsafe casts | could be | -- performed. Derived instances are OK. | ; dflags <- getDynFlags | - ; when (safeLanguageOn dflags) $ | - mapM_ (\x -> when (typInstCheck x) | - (addErrAt (getSrcSpan $ iSpec x) | typInstErr)) | - local_infos | + ; when (safeLanguageOn dflags) $ forM_ local_infos $ \x -> case | x of | + _ | typInstCheck x -> addErrAt (getSrcSpan $ iSpec x) | (typInstErr x) | + _ | genInstCheck x -> addErrAt (getSrcSpan $ iSpec x) | (genInstErr x) | + _ -> return () | + | -- As above but for Safe Inference mode. | - ; when (safeInferOn dflags) $ | - mapM_ (\x -> when (typInstCheck x) recordUnsafeInfer) | local_infos | + ; when (safeInferOn dflags) $ forM_ local_infos $ \x -> case x | of | + _ | typInstCheck x -> recordUnsafeInfer | + _ | genInstCheck x -> recordUnsafeInfer | + _ -> return () | | ; return ( gbl_env | , bagToList deriv_inst_info ++ local_infos @@ -442,8 | +445,16 @@ tcInstDecls1 tycl_decls inst_decls deriv_decls | else (typeableInsts, i:otherInsts) | | typInstCheck ty = is_cls_nm (iSpec ty) `elem` | oldTypeableClassNames | - typInstErr = ptext $ sLit $ "Can't create hand written instances | of Typeable in Safe" | - ++ " Haskell! Can only derive them" | + typInstErr i = hang (ptext (sLit $ "Typeable instances can only be | " | + ++ "derived in Safe Haskell.") $+$ | + ptext (sLit "Replace the following | instance:")) | + 2 (pprInstanceHdr (iSpec i)) | + | + genInstCheck ty = is_cls_nm (iSpec ty) `elem` genericClassNames | + genInstErr i = hang (ptext (sLit $ "Generic instances can only be | " | + ++ "derived in Safe Haskell.") $+$ | + ptext (sLit "Replace the following | instance:")) | + 2 (pprInstanceHdr (iSpec i)) | | instMsg i = hang (ptext (sLit $ "Typeable instances can only be | derived; replace " | ++ "the following instance:")) | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

1 0

GHC.Event.Unique vs Data.Unique
by Michael Schröder 02 Aug '14

02 Aug '14

Is there a reason GHC.Event.Unique exists, since we also have Data.Unique? Or is this just a historical artifact? It looks like they used to have the same implementation, but have now diverged, with Data.Unique being the more recent one. GHC.Event.Unique still uses STM internally, and is as far as I can see the only part of the base library to do so. Which wouldn't really matter, except that now basic IO stuff like threadDelay and even putStr (sometimes, especially in ghci) cannot be used inside unsafeIOToSTM. Which is somewhat annoying…

2 1

Overlapping and incoherent instances
by Simon Peyton Jones 02 Aug '14

02 Aug '14

Friends One of GHC's more widely-used features is overlapping (and sometimes incoherent) instances. The user-manual documentation is here<http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class-extensio…>. The use of overlapping/incoherent instances is controlled by LANGUAGE pragmas: OverlappingInstances and IncoherentInstances respectively. However the overlap/incoherent-ness is a property of the *instance declaration* itself, and has been for a long time. Using LANGUAGE OverlappingInstances simply sets the "I am an overlapping instance" flag for every instance declaration in that module. This is a Big Hammer. It give no clue about *which* particular instances the programmer is expecting to be overlapped, nor which are doing the overlapping. It brutally applies to every instance in the module. Moreover, when looking at an instance declaration, there is no nearby clue that it might be overlapped. The clue might be in the command line that compiles that module! Iavor has recently implemented per-instance-declaration pragmas, so you can say instance {-# OVERLAPPABLE #-} Show a => Show [a] where ... instance {-# OVERLAPPING #-} Show [Char] where ... This is much more precise (it affects only those specific instances) and it is much clearer (you see it when you see the instance declaration). This new feature will be in GHC 7.10 and I'm sure you will be happy about that. But I propose also to deprecate the LANGUAGE pragmas OverlappingInstances and IncoherentInstances, as way to encourage everyone to use the new feature instead of the old big hammer. The old LANGUAGE pragmas will continue to work, of course, for at least another complete release cycle. We could make that two cycles if it was helpful. However, if you want deprecation-free libraries, it will entail a wave of library updates. This email is just to warn you, and to let you yell if you think this is a bad idea. It would actually not be difficult to retain the old LANGUAGE pragmas indefinitely - it just seems wrong not to actively push authors in the right direction. These deprecations of course popped up in the test suite, so I've been replacing them with per-instance pragmas there too. Interestingly in some cases, when looking for which instances needed the pragmas, I found...none. So OverlappingInstances was entirely unnecessary. Maybe library authors will find that too! Simon

3 3

Build broken: Forall'd constraint ‘Ix i’ is not bound in RULE lhs
by Joachim Breitner 01 Aug '14

01 Aug '14

Hi SPJ, it seems as if your latest commit “Improve the desugaring of RULES, esp those from SPECIALISE pragmas” broke the build (when building with -Werror and -dcore-lint): libraries/array/Data/Array/Base.hs:476:1: Warning: Forall'd constraint ‘Ix i’ is not bound in RULE lhs showsIArray @ UArray @ i @ e $dIArray_a4L0 $dIx_a4L9 $dShow_a4L2 $dShow_a4L3 <no location info>: Failing due to -Werror. make[1]: *** [libraries/array/dist-install/build/Data/Array/Base.o] Error 1 Full build log at https://api.travis-ci.org/jobs/31427050/log.txt?deansi=true Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

2 3

RE: Failing ASSERT in ghci044 and ghci047
by Simon Peyton Jones 01 Aug '14

01 Aug '14

Thanks. These are tests that over-ride one instance declaration with another, something that really wasn't working before. I have no idea what is going on in Linker.hs It's the weekend so I'm not going to have a chance to look at this for a bit -- and oddly it seems to work anyway. But asserts should not fail. If someone had time to make it an ASSERT2 and print out the relevant entrails (toplev_only, nms, and the context of ce_in (not the HValue component, obviously)), that would be helpful. Simon | -----Original Message----- | From: Edward Z.Yang [mailto:ezyang@cs.stanford.edu] | Sent: 01 August 2014 18:41 | To: ghc-devs | Cc: Simon Peyton Jones | Subject: Failing ASSERT in ghci044 and ghci047 | | CC'd Simon because you were touching these test-cases recently. | | You'll need to run with -DDEBUG, which is probably why validate didn't | catch these. Maybe the ASSERT is out of date? | | =====> ghci044(ghci) 1719 of 4065 [0, 0, 0] | [72/1822] | cd ./ghci/scripts && HC='/home/hs01/ezyang/ghc-validate/inplace/bin/ghc- | stage2' HC_OPTS='-dcore-lint - | dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci- | history ' '/home/hs01/ezyang/ghc-va | lidate/inplace/bin/ghc-stage2' --interactive -v0 -ignore-dot-ghci -dcore- | lint -dcmm-lint -dno-debug-ou | tput -no-user-package-db -rtsopts -fno-ghci-history <ghci044.script | >ghci044.run.stdout 2>ghci044. | run.stderr | Actual stderr output differs from expected: | --- ./ghci/scripts/ghci044.stderr 2014-07-31 11:00:16.433141666 - | 0700 | +++ ./ghci/scripts/ghci044.run.stderr 2014-08-01 10:38:17.352234466 - | 0700 | @@ -6,3 +6,12 @@ | instance C a => C [a] -- Defined at <interactive>:8:10 | In the expression: f [4 :: Int] | In an equation for ‘it’: it = f [4 :: Int] | +*** Exception: ASSERT failed! file compiler/ghci/Linker.lhs, line 907 | +*** Exception: ASSERT failed! file compiler/ghci/Linker.lhs, line 907 | +*** Exception: ASSERT failed! file compiler/ghci/Linker.lhs, line 907 | +*** Exception: ASSERT failed! file compiler/ghci/Linker.lhs, line 907 | + | +<interactive>:15:1: | + No instance for (C Bool) arising from a use of ‘f’ | + In the expression: f [True] | + In an equation for ‘it’: it = f [True] | Actual stdout output differs from expected: | | =====> ghci047(ghci) 1723 of 4065 [0, 1, 0] | cd ./ghci/scripts && HC='/home/hs01/ezyang/ghc-validate/inplace/bin/ghc- | stage2' HC_OPTS='-dcore-lint - | dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci- | history ' '/home/hs01/ezyang/ghc-va | lidate/inplace/bin/ghc-stage2' --interactive -v0 -ignore-dot-ghci -dcore- | lint -dcmm-lint -dno-debug-ou | tput -no-user-package-db -rtsopts -fno-ghci-history <ghci047.script | >ghci047.run.stdout 2>ghci047. | run.stderr | Actual stderr output | Actual stderr output differs from expected: | --- ./ghci/scripts/ghci047.stderr 2014-05-28 15:38:19.608946057 - | 0700 | +++ ./ghci/scripts/ghci047.run.stderr 2014-08-01 10:38:17.658906746 - | 0700 | @@ -1,16 +1,14 @@ | +*** Exception: ASSERT failed! file compiler/ghci/Linker.lhs, line 907 | +*** Exception: ASSERT failed! file compiler/ghci/Linker.lhs, line 907 | | | Cheers, | Edward

1 0

Failing ASSERT in ghci044 and ghci047
by Edward Z. Yang 01 Aug '14

01 Aug '14

CC'd Simon because you were touching these test-cases recently. You'll need to run with -DDEBUG, which is probably why validate didn't catch these. Maybe the ASSERT is out of date? =====> ghci044(ghci) 1719 of 4065 [0, 0, 0] [72/1822] cd ./ghci/scripts && HC='/home/hs01/ezyang/ghc-validate/inplace/bin/ghc-stage2' HC_OPTS='-dcore-lint - dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history ' '/home/hs01/ezyang/ghc-va lidate/inplace/bin/ghc-stage2' --interactive -v0 -ignore-dot-ghci -dcore-lint -dcmm-lint -dno-debug-ou tput -no-user-package-db -rtsopts -fno-ghci-history <ghci044.script >ghci044.run.stdout 2>ghci044. run.stderr Actual stderr output differs from expected: --- ./ghci/scripts/ghci044.stderr 2014-07-31 11:00:16.433141666 -0700 +++ ./ghci/scripts/ghci044.run.stderr 2014-08-01 10:38:17.352234466 -0700 @@ -6,3 +6,12 @@ instance C a => C [a] -- Defined at <interactive>:8:10 In the expression: f [4 :: Int] In an equation for ‘it’: it = f [4 :: Int] +*** Exception: ASSERT failed! file compiler/ghci/Linker.lhs, line 907 +*** Exception: ASSERT failed! file compiler/ghci/Linker.lhs, line 907 +*** Exception: ASSERT failed! file compiler/ghci/Linker.lhs, line 907 +*** Exception: ASSERT failed! file compiler/ghci/Linker.lhs, line 907 + +<interactive>:15:1: + No instance for (C Bool) arising from a use of ‘f’ + In the expression: f [True] + In an equation for ‘it’: it = f [True] Actual stdout output differs from expected: =====> ghci047(ghci) 1723 of 4065 [0, 1, 0] cd ./ghci/scripts && HC='/home/hs01/ezyang/ghc-validate/inplace/bin/ghc-stage2' HC_OPTS='-dcore-lint - dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history ' '/home/hs01/ezyang/ghc-va lidate/inplace/bin/ghc-stage2' --interactive -v0 -ignore-dot-ghci -dcore-lint -dcmm-lint -dno-debug-ou tput -no-user-package-db -rtsopts -fno-ghci-history <ghci047.script >ghci047.run.stdout 2>ghci047. run.stderr Actual stderr output Actual stderr output differs from expected: --- ./ghci/scripts/ghci047.stderr 2014-05-28 15:38:19.608946057 -0700 +++ ./ghci/scripts/ghci047.run.stderr 2014-08-01 10:38:17.658906746 -0700 @@ -1,16 +1,14 @@ +*** Exception: ASSERT failed! file compiler/ghci/Linker.lhs, line 907 +*** Exception: ASSERT failed! file compiler/ghci/Linker.lhs, line 907 Cheers, Edward --- End forwarded message ---

1 0

Changing the -package dependency resolution algorithm
by Edward Z. Yang 01 Aug '14

01 Aug '14

Right now, GHC has a very complex and hard to explain algorithm for picking packages from the package database when you give it a pile of -package/-package-id/-{hide,ignore,trust,distrust}-package flags. Roughly, it currently does something like this. 1. Concatenate all of the package databases into a giant list, with system packages first and then user packages later, removing duplicate entries with the same installed package ID (preferring later packages). Call this PACKAGES. 2. Take all the -package-id flags and compute their transitive closure (call this set P). 3. Calculate the set of shadowed packages--the set of installed packages for which there exists another package with the same package ID (foo-0.1) which is in P or is later in the package stack. 4. Calculate the set of ignored packages---the set of packages which match all -ignore-package flags 5. Filter out shadowed and ignored packages from the list of packages, calling the result ALL_PACKAGES. 6. Calculate the set of broken packages---the set of packages not contained in the least fixed point of the relation that takes a set of packages, and adds all packages whose dependencies are satisfied, from ALL_PACKAGES. 7. Process the package flags in order, operating on PACKAGES (not ALL_PACKAGES). For -package/-hide-package, take the package with the *latest* version that matches the flag and are not broken (since this includes shadowed packages, the result is unique) and toggle it to be exposed/unexposed, and hide all the other packages. For -trust-package/-distrust-package, toggle the trusted bit for all instances in the database. 8. If we have exposed multiple versions of the same package name, hide all the older versions What a mouthful! I have no idea, given a set of flags, how this works. So here is an alternate proposal for an alternate way of handling these flags *when starting from an empty database* (e.g. -hide-all-packages) Suppose we maintain a set of selected packages, which starts off empty. Process each package flag in turn. For -package and -package-id, get the set of installed packages which match the flag. (If multiple package names apply, process each in turn as if it were a separate flag.) Compute the transitive closure of dependencies for all of them, and filter out all choices which have dependencies which are inconsistent with the current set of selected packages. Consistency without multi-instances is a mapping of a package name to an installed package. If there is still more than one choice, tiebreak by version, which database and time of install. (The latter tiebreak should not be necessary until we allow multiple instances of a package with the same package ID.) For -hide-package, get the set of packages which match and hide them all; for -ignore-package, hide the transitive closure of dependencies of it. For -trust,distrust-package, toggle for all matching packages as before. Here are some differences in behavior between this and the previous scheme: - It's no longer valid to indirectly depend on two different versions of the same package. Most of the time, users didn't want this anyway. Note that the current scheme prevents directly depending on two different versions by shadowing the old ones. - We can easily extend it to handle multi-instances by relaxing the consistency check. - It assumes *-hide-all-packages* at the beginning. This scheme probably works less well without that: now we need some consistent view of the database to start with. What do people think? Cheers, Edward

4 7

Multiple imports on single line
by eng. Vassil Ognyanov Keremidchiev 31 Jul '14

31 Jul '14

Hello, dear GHC developers! Is it possible to add such constructions in next GHCs: import Data.List, Data.Array, Data.Aeson, Network.HTTP.Conduit on a single line. This will simplify source code and clear the space before the actual code. Best regards, Vassil Keremidchiev

2 1

pthread.h missing
by Simon Peyton Jones 31 Jul '14

31 Jul '14

On Windows rts/T8124 is failing thus: T8124_c.c:4:21: fatal error: pthread.h: No such file or directory compilation terminated. *** unexpected failure for T8124(threaded1) Simon

2 1