- ghc-devs - Haskell.org

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

.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 05 Jan '20

05 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

[ANNOUNCE] GHC 8.8.2-rc1 is now available
by Ben Gamari 02 Jan '20

02 Jan '20

Hello everyone, The GHC team is proud to announce the first release candidate of GHC 8.8.2. The source distribution, binary distributions, and documentation are available at https://downloads.haskell.org/~ghc/8.8.2-rc1 Release notes are also available [1]. This release fixes a handful of issues affecting 8.8.1: - A bug (#17088) in the compacting garbage collector resulting in segmentations faults under specific circumstances. Note that this may affect user programs even if they did not explicitly request the compacting GC (using the -c RTS flag) since GHC may fallback to compacting collection during times of high memory pressure. - A code generation bug (#17334) resulting in GHC panics has been fixed. - A bug in the `process` library causing builds using `hsc2hs` to fail non-deterministically on Windows has been fixed (Trac #17480) - A typechecker bug (#12088) resulting in programs being unexpectedly rejected has been fixed. - A bug in the implementation of compact normal forms resulting in segmentation faults in some uses (#17044) has been fixed. - A bug causing GHC to incorrectly complain about incompatible LLVM versions when using LLVM 7.0.1 has been fixed (#16990). As always, if anything looks amiss do let us know. Happy compiling! Cheers, - Ben [1] https://downloads.haskell.org/ghc/8.8.2-rc1/docs/html/users_guide/8.8.2-not…

4 3

[ANNOUNCE] Glasgow Haskell Compiler 8.10.1-alpha2 released
by Ben Gamari 02 Jan '20

02 Jan '20

Hello all, The GHC team is happy to announce the availability of the first alpha release in the GHC 8.10 series. Source and binary distributions are available at the usual place: https://downloads.haskell.org/ghc/8.10.1-alpha2/ GHC 8.10.1 will bring a number of new features including: * The new UnliftedNewtypes extension allowing newtypes around unlifted types. * The new StandaloneKindSignatures extension allows users to give top-level kind signatures to type, type family, and class declarations. * A new warning, -Wderiving-defaults, to draw attention to ambiguous deriving clauses * A number of improvements in code generation, including changes * A new GHCi command, :instances, for listing the class instances available for a type. * An upgraded Windows toolchain lifting the MAX_PATH limitation * A new, low-latency garbage collector. * Improved support profiling, including support for sending profiler samples to the eventlog, allowing correlation between the profile and other program events This release is the second alpha of the 8.10 pre-release cycle. The release will be a release candidate in roughly three weeks. If all goes well the final release will be cut roughly two weeks after the candidate, in mid-January. This being an alpha release, there are a few issues that are still outstanding: * The new Alpine Linux binary distribution is not present due to an apparent correctness issue [1]; any help Alpine users can offer here would be greatly appreciated. * We have yet to sort out compliance with Apple's notarization requirements [2] which will be likely be necessary for users of macOS Catalina. However, until this has been sorted out Catalina users can exempt the current macOS binary distribution from the notarization requirement themselves by running `xattr -cr .` on the unpacked tree before running `make install`. * There is one remaining non-regression correctness issue which we plan to fix for the final 8.10.1 but that is not fixed in this release. Please do test this release and let us know if you encounter any other issues. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/issues/17508 [2] https://gitlab.haskell.org/ghc/ghc/issues/17418

3 2