January 2020 - ghc-devs

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 11 Jan '20

11 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 06 Jan '20

06 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

.hie files for pre-installed GHC libraries
by Csaba Hruska 05 Jan '20

05 Jan '20

Hi, Is it planned to include the .hie files of the base and other libraries in the GHC binary download package? Regards, Csaba Hruska

2 1

Fix for ticket 8095 in ghc-8.10.1
by Rene 05 Jan '20

05 Jan '20

Hello, I wondering if the fix for https://gitlab.haskell.org/ghc/ghc/issues/8095 is going to make it into ghc-8.10.1 ? Rene.

2 1

A small but useful tool for performance characterisation
by Ben Gamari 04 Jan '20

04 Jan '20

Hi everyone, I have recently been doing a fair amount of performance characterisation and have long wanted a convenient means of collecting GHC runtime statistics for later analysis. For this I quickly developed a small wrapper utility [1]. To see what it does, let's consider an example. Say we made a change to GHC which we believe might affect the runtime performance of Program.hs. We could quickly check this by running, $ ghc-before/_build/stage1/bin/ghc -O Program.hs $ ghc_perf.py -o before.json ./Program $ ghc-before/_build/stage1/bin/ghc -O Program.hs $ ghc_perf.py -o after.json ./Program This will produce two files, before.json and after.json, which contain the various runtime statistics emitted by +RTS -s --machine-readable. These files are in the same format as is used by my nofib branch [2] and therefore can be compared using `nofib-compare` from that branch. In addition to being able to collect runtime metrics, ghc_perf is also able to collect performance counters (on Linux only) using perf. For instance, $ ghc_perf.py -o program.json \ -e instructions,cycles,cache-misses ./Program will produce program.json containing not only RTS statistics but also event counts from the perf instructions, cycles, and cache-misses events. Alternatively, passing simply `ghc_perf.py --perf` enables a reasonable default set of events (namely instructions, cycles, cache-misses, branches, and branch-misses). Finally, ghc_perf can also handle repeated runs. For instance, $ ghc_perf.py -o program.json -r 5 --summarize \ -e instructions,cycles,cache-misses ./Program will run Program 5 times, emit all of the collected samples to program.json, and produce a (very basic) statistical summary of what it collected on stdout. Note that there are a few possible TODOs that I've been considering: * I chose JSON as the output format to accomodate structured data (e.g. capture experimental parameters in a structured way). However, in practice this choice has lead to significantly more inconvenience than I would like, especially given that so far I've only used the format to capture basic key/value pairs. Perhaps reverting to CSV would be preferable. * It might be nice to also add support for cachegrind. Anyways, I hope that others find this as useful as I have. Cheers, - Ben [1] https://gitlab.haskell.org/bgamari/ghc-utils/blob/master/ghc_perf.py [2] https://gitlab.haskell.org/ghc/nofib/merge_requests/24

2 2