- ghc-devs - Haskell.org

Windows testsuite failures
by Ben Gamari 17 Jan '20

17 Jan '20

Hi all, Currently Windows CI is a bit flaky due to some unfortunately rather elusive testsuite driver bugs. Progress in resolving this has been a bit slow due to travel over the last week but I will be back home tomorrow and should be able to resolve the issue soon thereafter. Cheers, - Ben

5 10

Find constraints over type
by Alejandro Serrano Mena 17 Jan '20

17 Jan '20

Dear GHC devs, I am trying to figure out a way to obtain the constraints that hold over a type. Let me give you an example: suppose that I write the following function: f :: Eq a => [a] -> Bool f xs = xs == [] If I ask for the type of the Var ' xs', I get back '[a]'. This is correct, but I am missing the crucial information that '[a]' must be Eq. Is there an easy way to get it? It seems that 'varType' doesn't give me enough information. Regards, Alejandro

3 4

Linking stage 2 compiler with non-threaded RTS using Make?
by Ömer Sinan Ağacan 15 Jan '20

15 Jan '20

Anyone know how to link stage 2 with non-threaded RTS using Make build system? There's a variable GhcThreaded, but setting it "NO" makes no difference, stage 2 compiler is still threaded. So far the only way I could find is to redirect build system output to a file, find the step that linked ghc-stage2, repeat that command but without -threaded. It's really painful as I have to repeat this step after every rebuild. Any tips? Thanks, Ömer

4 5

gitlab.haskell.org spam issues
by Ryan Scott 12 Jan '20

12 Jan '20

There appears to be an account [1] that is submitting spam as GitLab issues. I've noticed the following spam issues so far: * https://gitlab.haskell.org/ghc/ghc/issues/17664 * https://gitlab.haskell.org/ghc/ghc/issues/17666 * https://gitlab.haskell.org/haskell/ghcup/issues/125 * https://gitlab.haskell.org/haskell/ghcup/issues/127 * https://gitlab.haskell.org/haskell/ghcup/issues/129 Best, Ryan S. ----- [1] https://gitlab.haskell.org/nunikonaza88

5 6

Superclasses of type families returning constraints?
by Alexis King 12 Jan '20

12 Jan '20

Hello all, I recently noticed that GHC rejects the following program: type family F a b :: Constraint where F a a = () eq :: F a b => a :~: b eq = Refl This is certainly not shocking, but it is a little unsatisfying: as far as I can tell, accepting this program would be entirely sound. That is, `a ~ b` is morally a “superclass” of `F a b`. In this example the type family is admittedly rather pointless, as `a ~ b` could be used instead, but it is possible to construct more sophisticated examples that cannot be so straightforwardly expressed in other ways. I am therefore curious: has this kind of scenario ever been discussed before? If yes, is there a paper/GitLab issue/email thread somewhere that discusses it? And if no, is there any fundamental reason that GHC does not propagate such information (i.e. it’s incompatible with some aspect of the type system or constraint solver), or is it simply something that has not been explored? (Maybe you think the above program is horrible and *shouldn’t* be accepted even if it were possible, but that is a different question entirely. :)) Thanks, Alexis

3 12

Extension.hs ForallXXX constraints
by Alan & Kim Zimmerman 09 Jan '20

09 Jan '20

I have got back into some GHC dev, and noticed that the various ForallXXX type synonyms in Extension.hs are unused in GHC. In the early iteration, they were needed, but it seems not any more. Is there any reason they should not be removed? Alan

2 1

Code generation/SRT question
by Ömer Sinan Ağacan 07 Jan '20

07 Jan '20

Hi Simon, In Cmm if I have a recursive group of functions f and g, and I'm using f's closure as the SRT for this group, should f's entry block's info table have f_closure as its SRT? In Cmm syntax f_entry() { { info_tbls: [... (c1vn, label: ... rep: ... srt: ??????] stack_info: ... } {offset c1vn: ... } } Here should I have `f_closure` in the srt field? I'd expect yes, but looking at the current SRT code, in CmmBuildInfoTables.updInfoSRTs, we have this: (newInfo, srtEntries) = case mapLookup (g_entry g) funSRTEnv of Nothing -> -- if we don't add SRT entries to this closure, then we -- want to set the srt field in its info table as usual (info_tbl { cit_srt = mapLookup (g_entry g) srt_env }, []) Just srtEntries -> srtTrace "maybeStaticFun" (ppr res) (info_tbl { cit_rep = new_rep }, res) where res = [ CmmLabel lbl | SRTEntry lbl <- srtEntries ] Here we only update SRT field of the block if we're not adding SRT entries to the function's closure, so in the example above, because we're using the function as SRT (and adding SRT entries to its closure) SRT field of c1vn won't be updated. Am I missing anything? Thanks, Ömer

3 7

How to specify import paths for a frontend plugin
by Derek Lam 07 Jan '20

07 Jan '20

Hi ghc-devs, I’m making a first attempt to make a frontend plugin, to resolve cabal packages in the GHC API. However I’m running into troubles with module resolution in the GHC API, because I can’t control where it will search for modules at all. I've attached a minimal example, with a frontend plugin definition that can’t find modules (Plugin.hs), and an equivalent standalone program that does (Main.hs). Specifically, I'm following a solution Edward Yang published in 2017 (http://blog.ezyang.com/2017/02/how-to-integrate-ghc-api-programs-with-cabal/) where the frontend plugin is called through a helper script that passes flags forwarded from `cabal repl`. To test the plugin directly with GHC, I collected the args through the helper script and filtered them to the minimal set that made the plugin run: ghc --frontend Plugin -itarget -package-db dist-newstyle/packagedb/ghc-8.6.5 Plugin -plugin-package sandbox -hide-all-packages This, as well as the full argument set, would complain that it can't find the target module under `./target/A.hs`: <no location info>: error: module ‘A’ cannot be found locally It does when the import path arg `-itarget` is absolute. Still, its `importPaths` are what I expect: [".", "target"], and the standalone program finds the target module with the same `importPaths`. I've tested this in GHC 8.6.5, 8.4.2 and 8.2.2, making me sure I'm just missing something, but I haven’t found help in the docs yet. I really appreciate some help to draw my hours over this to a close! Thanks, Derek PS the full invocation of the plugin (with absolute paths swapped with relative ones, except `-itarget` which was relative to begin with) is: ghc --frontend Plugin -plugin-package sandbox -fbuilding-cabal-package -O0 -outputdir dist-newstyle/build/x86_64-osx/ghc-8.6.5/sandbox-0.1.0.0/build -odir dist-newstyle/build/x86_64-osx/ghc-8.6.5/sandbox-0.1.0.0/build -hidir dist-newstyle/build/x86_64-osx/ghc-8.6.5/sandbox-0.1.0.0/build -stubdir dist-newstyle/build/x86_64-osx/ghc-8.6.5/sandbox-0.1.0.0/build -i -idist-newstyle/build/x86_64-osx/ghc-8.6.5/sandbox-0.1.0.0/build -i. -itarget -idist-newstyle/build/x86_64-osx/ghc-8.6.5/sandbox-0.1.0.0/build/autogen -idist-newstyle/build/x86_64-osx/ghc-8.6.5/sandbox-0.1.0.0/build/global-autogen -Idist-newstyle/build/x86_64-osx/ghc-8.6.5/sandbox-0.1.0.0/build/autogen -Idist-newstyle/build/x86_64-osx/ghc-8.6.5/sandbox-0.1.0.0/build/global-autogen -Idist-newstyle/build/x86_64-osx/ghc-8.6.5/sandbox-0.1.0.0/build -optP-include -optPdist-newstyle/build/x86_64-osx/ghc-8.6.5/sandbox-0.1.0.0/build/autogen/cabal_macros.h -this-unit-id sandbox-0.1.0.0-inplace -hide-all-packages -Wmissing-home-modules -no-user-package-db -package-db /Users/derek-lam/.cabal/store/ghc-8.6.5/package.db -package-db dist-newstyle/packagedb/ghc-8.6.5 -package-db dist-newstyle/build/x86_64-osx/ghc-8.6.5/sandbox-0.1.0.0/package.conf.inplace -package-id base-4.12.0.0 -package-id ghc-8.6.5 -XHaskell2010 Plugin -hide-all-packages

2 2

help understanding a ghc assert failure wrt coercions
by Carter Schonwald 06 Jan '20

06 Jan '20

Hey all, I've been spending a little bit of time hacking out my own little "erase coercions" branch, and with asserts enabled i'm seeing a very strange panic that seems to be invalid? namely: its stating that the types have changed, BUT the error output indicates that the types are the same on both sides! ghc: panic! (the 'impossible' happened) (GHC version 8.11.0.20200106: ASSERT failed! optCoercion changed types! in_co: Univ(representational Erased :: IO a_a2Pd, State# RealWorld -> (# State# RealWorld, a_a2Pd #)) in_ty1: IO a_a2Pd in_ty2: State# RealWorld -> (# State# RealWorld, a_a2Pd #) out_co: Univ(representational Erased :: IO a_a2Pd, State# RealWorld -> (# State# RealWorld, a_a2Pd #)) out_ty1: IO a_a2Pd out_ty2: State# RealWorld -> (# State# RealWorld, a_a2Pd #) subst: [TCvSubst In scope: InScope {wild_00 augment ++ build foldr eqString bindIO returnIO otherwise assert thenIO breakpoint breakpointCond map $ join f_a19W x_a19X x_a1hI s_a1hZ $c==_a2rD $c/=_a2rM $cp1Ord_a2rY $ccompare_a2s0 $c<_a2se $c<=_a2ss $c>_a2sy $c>=_a2sE $cmax_a2sL $cmin_a2sS $cp1Monoid_a2t4 $cmappend_a2tf $cmconcat_a2tl $c>>=_a2tD $c>>_a2tS $creturn_a2u3 $cpure_a2uo $c<*>_a2uA $cliftA2_a2uN $c*>_a2v0 $c<*_a2vb $c>>=_a2vw $c>>_a2vJ $creturn_a2vU $cpure_a2wd $c<*>_a2wn $cliftA2_a2wy $c*>_a2wL $c<*_a2wW $c>>=_a2xf $c>>_a2xq $creturn_a2xB $c<*>_a2y0 $cliftA2_a2y9 $c*>_a2yj $c<*_a2yu $cmappend_a2yS $cmconcat_a2yY $cmappend_a2ze $cmconcat_a2zk $cp1Monoid_a2zE $cmempty_a2zG $cmappend_a2zU $cmconcat_a2A0 $cp1Monoid_a2Ai $cmempty_a2Ak $cmappend_a2Aw $cmconcat_a2AC $cp1Monoid_a2AS $cmempty_a2AU $cmappend_a2B4 $cmconcat_a2Ba $cp1Monoid_a2Bo $cmempty_a2Bq $cmappend_a2By $cmconcat_a2BE $cmappend_a2BU $cmconcat_a2C0 $cp1Monoid_a2Cb $cmappend_a2Cj $cmconcat_a2Cp $cmappend_a2CH $cmconcat_a2CN $c<>_a2CX $csconcat_a2D8 $cstimes_a2De $c<>_a2Dt $csconcat_a2DA $c<>_a2DV $csconcat_a2DZ $cstimes_a2E5 $c<>_a2Eu $csconcat_a2EI $cstimes_a2EO $c<>_a2Fp $csconcat_a2FB $cstimes_a2FH $c<>_a2Gc $csconcat_a2Gm $cstimes_a2Gs $c<>_a2GR $csconcat_a2GZ $cstimes_a2H5 $c<>_a2Hm $csconcat_a2Hq $cstimes_a2Hu $c<>_a2HG $csconcat_a2HM $cstimes_a2HS $c<>_a2I6 $csconcat_a2Id $cstimes_a2Ij $csconcat_a2IC $cstimes_a2II $c>>=_a2J0 $c>>_a2JO $creturn_a2JZ $cpure_a2Ke $c<*>_a2Kl $cliftA2_a2Kw $c*>_a2KJ $c<*_a2KU $cfmap_a2L7 $c<$_a2Lj $cmzero_a2LF $cmplus_a2LO $cmzero_a2M7 $cmplus_a2Mg $cmzero_a2Mz $cmplus_a2MI $csome_a2Na $cmany_a2Nj $csome_a2NK $cmany_a2NT $c<|>_a2Oe $csome_a2Oj $cmany_a2Os $c>>_a2OP $creturn_a2P0 $cfmap_a2Pb $c<$_a2Ps a_a2Pu b_a2Pv $c>>=_a2PJ $creturn_a2Q2 $c>>=_a2Qh $creturn_a2Qz $c>>=_a2QP $c>>_a2QV $creturn_a2R6 $c<*>_a2Rr $cliftA2_a2RC $c<*_a2RX $cpure_a2Se $c<*>_a2Sj $cliftA2_a2Sr $c*>_a2SA $c<*_a2SI $c<*>_a2T5 $cliftA2_a2Th $c*>_a2Tq $c<*_a2Tx $c<*>_a2TW $cliftA2_a2U2 $c*>_a2U9 $c<*_a2Uk $c<$_a2UF $cfmap_a2US $c<$_a2V0 $cfmap_a2Ve $c<$_a2Vk $c<$_a2VH $cfmap_a2VX $c<$_a2W3 $cfmap_a2Wi $c<$_a2Wo $krep_a37a $krep_a37b $krep_a37c $krep_a37d $krep_a37e $krep_a37f $krep_a37g $krep_a37h $krep_a37i $krep_a37j $krep_a37k $krep_a37l $krep_a37m $krep_a37n $krep_a37o $krep_a37p $krep_a37q $krep_a37r $krep_a37s $sap_d3dm $sap_d3dn $sliftM5_d3ds $sliftM5_d3dt $sliftM4_d3dy $sliftM4_d3dz $sliftM3_d3dE $sliftM3_d3dF $sliftM2_d3dK $sliftM2_d3dL $sliftM_d3dQ $sliftM_d3dR $swhen_d3e3 $swhen_d3e4 $s=<<_d3e9 $sliftA3_d3eh $sliftA3_d3ei $sliftA_d3em $sliftA_d3en $tcMonoid $tcSemigroup $trModule <**> liftA liftA3 =<< when sequence mapM liftM liftM2 liftM3 liftM4 liftM5 ap mapFB unsafeChr ord minInt maxInt id const . flip $! until asTypeOf failIO unIO getTag quotInt remInt divInt modInt quotRemInt divModInt divModInt# shiftL# shiftRL# iShiftL# iShiftRA# iShiftRL# $tcFunctor $dm<$ $fFunctor[] $fFunctorMaybe $fFunctor(,) $fFunctor-> $fFunctor(,,,) $fFunctor(,,) $tcApplicative $dm<*> $dmliftA2 $dm*> $dm<* $fApplicativeIO $fApplicative[] $fApplicativeMaybe $fApplicative-> $tcMonad $dm>> $dmreturn $fMonadIO $fFunctorIO $fMonad[] $fMonadMaybe $fMonad-> $tcAlternative $dmsome $dmmany $fAlternativeIO $fAlternative[] $fAlternativeMaybe $tcMonadPlus $dmmzero $dmmplus $fMonadPlusIO $fMonadPlus[] $fMonadPlusMaybe $tc':| $tcNonEmpty $fMonadNonEmpty $fApplicativeNonEmpty $fFunctorNonEmpty $dmsconcat $dmstimes $fSemigroupIO $fSemigroupMaybe $fSemigroupOrdering $fSemigroup(,,,,) $fSemigroup(,,,) $fSemigroup(,,) $fSemigroup(,) $fSemigroup() $fSemigroup-> $fSemigroupNonEmpty $fSemigroup[] $dmmappend $dmmconcat $tc'C:Monoid $fMonoidIO $fMonad(,,,) $fApplicative(,,,) $fMonad(,,) $fApplicative(,,) $fMonad(,) $fApplicative(,) $fMonoidMaybe $fMonoidOrdering $fMonoid(,,,,) $fMonoid(,,,) $fMonoid(,,) $fMonoid(,) $fMonoid() $fMonoid-> $fMonoid[] $tc'O $tcOpaque $fEqNonEmpty $fOrdNonEmpty returnIO_s3A8 failIO_s3A9 $cempty_s3Ab unIO_s3Ac thenIO_s3Ah bindIO_s3Am $trModule_s3AL $trModule_s3AM $trModule_s3AN $trModule_s3AO $krep_s3AP $tcFunctor_s3AQ $tcFunctor_s3AR $tcApplicative_s3AS $tcApplicative_s3AT $tcMonad_s3AU $tcMonad_s3AV $tcAlternative_s3AW $tcAlternative_s3AX $tcMonadPlus_s3AY $tcMonadPlus_s3AZ $tcNonEmpty_s3B0 $tcNonEmpty_s3B1 $krep_s3B2 $tc':|_s3B3 $tc':|_s3B4 $tcSemigroup_s3B5 $tcSemigroup_s3B6 $krep_s3B7 $tcMonoid_s3B8 $tcMonoid_s3B9 $krep_s3Ba $tc'C:Monoid_s3Bb $tc'C:Monoid_s3Bc $tcOpaque_s3Bd $tcOpaque_s3Be $tc'O_s3Bf $tc'O_s3Bg $cliftA2_s3BL $cfmap_s3BP $c<*>_s3BT $sap_s3BW $sliftM2_s3BZ $sliftM5_s3Cc $sliftM4_s3Ch $sliftM3_s3Cl $sliftM_s3Co f_s3FS} Type env: [a2Pd :-> b_a2Pv, a2Pe :-> a_a2Pu] Co env: []] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1173:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1243:5 in ghc:Outputable assertPprPanic, called at compiler/types/OptCoercion.hs:122:41 in ghc:OptCoercion

3 2

hadrian-util: An experiment in a more usable hadrian UX
by Ben Gamari 06 Jan '20

06 Jan '20

Hi everyone, For the past few months I have been using Hadrian for the majority of my GHC builds. In due course I have encountered a few papercuts: * hadrian/cabal.build.sh is quite wordy (#16250); moreover, you need to be in the source root to invoke it (#16667) * editing hadrian.settings is quite difficult due to the lack of availability of tab-completion in vim * maintaining multiple build roots is quite error-prone since you must remember which build flavour you used for each (#16481, #16638) * there is no equivalent to setting `stage=2` in `mk/build.mk` to make the stage-1-freeze persistent To address these I cobbled together a small wrapper, hadrian-util. I have this installed in my home-manager environment with a shell alias, `hu`, meaning that building GHC is as easy as typing `hu run` anywhere in the tree. As discussed in the README, `hadrian-util` supports multiple build roots, has a moderately convenient interface for manipulating hadrian.settings (with completion!) and has enough persistent state to eliminate most of the error-prone boilerplate from Hadrian invocations without being confusing. There is the question of what the long-term future of hadrian-util should be. Arguably it is merely a hack papering over some of the shortcomings of Hadrian's current UX; perhaps eventually these will be fixed. However, in the meantime, I've found that hadrian-util makes hadrian quite pleasant to use. I hope others also find this useful. Cheers, - Ben

3 2