- ghc-devs - Haskell.org

Fixing type synonyms to Uniq(D)FM newtypes
by Andreas Klebinger 23 Jun '20

23 Jun '20

There was a discussion about making UniqFM typed for the keys here a while ago. (https://mail.haskell.org/pipermail/ghc-devs/2020-January/018451.html and following) I wrote up an MR for one possible approach here: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3577 It implements solution 2 from that discussion. Just while getting the patch to typecheck I've already seen a number of cases where this increased readability of the code quite a bit so I think it's a good improvement. If there are strong objections to this solution let me know. In that case I'm happy to abandon the patch. If not I will clean it up and get it ready for merging.

2 2

Re: GitLab status
by Ryan Scott 22 Jun '20

22 Jun '20

Just as an FYI, there appears to be some data loss from this migration. For example, I pushed a commit to !3536 [1] that appears to have been dropped, leading to confusion here [2]. To make things worse, I never received an e-mail notification for this comment—I only discovered it by chance. I also opened an issue about FUN, but that appears to have been lost. I could try to resubmit it, but perhaps the data still exists somewhere on servers somewhere? Ryan S. ----- [1] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3536 [2] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3536#note_283322

2 1

Introducing GHC whole program compiler (GHC-WPC)
by Csaba Hruska 22 Jun '20

22 Jun '20

Hello, I've created a whole program compilation pipeline for GHC via STG. Please read my blog post for the details: Introducing GHC whole program compiler (GHC-WPC) <https://www.patreon.com/posts/introducing-ghc-38173710> Regards, Csaba Hruska

3 5

RE: GHC/ | GHC doesn't inline small type class method marked as INLINE with profiling enabled (#18372)
by Simon Peyton Jones 22 Jun '20

22 Jun '20

I get a 404 for https://gitlab.haskell.org/ghc/ghc/-/issues/18372 You may need to re-submit this… s From: Andrzej Rybczak <gitlab(a)gitlab.haskell.org> Sent: 21 June 2020 15:44 To: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: GHC/ | GHC doesn't inline small type class method marked as INLINE with profiling enabled (#18372) Andrzej Rybczak<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha…> created an issue: Summary When profiling is enabled, GHC doesn't inline small type class methods which prevents further optimizations and specialization from happening. Steps to reproduce When the following module: module Main where import Optics.Core data T = T { _t1 :: Int , _t2 :: Int } t1 :: Lens' T Int t1 = lensVL $ \f s -> (\n -> s { _t1 = n}) <$> f (_t1 s) {-# INLINE t1 #-} t2 :: Lens' T Int t2 = lensVL $ \f s -> (\n -> s { _t2 = n}) <$> f (_t2 s) {-# INLINE t2 #-} t_val :: T t_val = T 1 2 {-# NOINLINE t_val #-} main :: IO () main = putStrLn . show $ view t1 t_val + view t2 t_val is compiled with profiling enabled, here's how core of main looks: main1 = case ((($fStrongForget_$clinear main_l1) (id `cast` <Co:41>)) `cast` <Co:42>) t_val of { I# x_a2c8 -> case ((($fStrongForget_$clinear main_l2) (id `cast` <Co:41>)) `cast` <Co:42>) t_val of { I# y_a2cb -> case $wshowSignedInt 0# (+# x_a2c8 y_a2cb) [] of { (# ww5_a277, ww6_a278 #) -> : ww5_a277 ww6_a278 } } } So linear doesn't get inlined even though it's a small function that is even explicitly marked INLINE<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…>. This prevents further optimizations from happening and leaves optics-related code in semi-optimized state, making looking at cost centers unreliable (see well-typed/optics#324<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…>). When profiling is disabled, everything inlines and optimizes away as expected: main1 = case t_val of { T ds_d25F ds1_d25G -> case ds_d25F of { I# x_a2c7 -> case ds1_d25G of { I# y_a2ca -> case $wshowSignedInt 0# (+# x_a2c7 y_a2ca) [] of { (# ww5_a276, ww6_a277 #) -> : ww5_a276 ww6_a277 } } } } I'm attaching archive with cabal project that contains above module for easy reproduction: prof_test.tar.gz<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha…> Profiling build was tested with profiling: True in cabal.project.local. Expected behavior GHC should inline class methods marked as INLINE when profiling is enabled. Environment * GHC version used: 8.10.1 Optional: * Operating System: Arch Linux * System Architecture: x86_64 — Reply to this email directly or view it on GitLab<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha…>. You're receiving this email because of your account on gitlab.haskell.org. If you'd like to receive fewer emails, you can unsubscribe<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha…> from this thread or adjust your notification settings.

1 0

Merge window logistics and relaxation of submodule policy
by Ben Gamari 22 Jun '20

22 Jun '20

Hi everyone, At this point we are in the home stretch of the GHC 8.12 preparation phase. The merge queue has progressed a bit more slowly than I would have liked over the last few weeks but nevertheless I think we are converging. Regardless, if you have a patch which you believe should go in to 8.12 and doesn't already bear the %8.12 GitLab milestone, please do let me know. # Submodule policy One matter that is currently holding us up is a few submodules which haven't yet had necessary patches merged upstream. As there hasn't yet been much motion on the part of maintainer, I propose that we temporarily relax our policy that GHC submodules refer to upstream commits. That is, we allow GHC to temporarily track a non-upstream branch, ensuring that the branch is merged upstream before the final GHC release. Are there any objections to this policy relaxation? It will require a bit more care on our part, but I think it is a sensible compromise way to give upstream maintainers the time they need while ensuring that GHC isn't subject to unpredictable schedules. Cheers, - Ben

2 1

GitLab status
by Ben Gamari 21 Jun '20

21 Jun '20

Hi everyone, As you may have noticed, yesterday was marked by rather consistent CI failures. I believe I have now fixed the root cause but do let me know if you see any further issues. Below I have included a brief post-mortem describing the incident and what we plan to do to prevent it recurring in the future. Cheers, - Ben # Post-mortem Early Friday morning our storage provider experienced a hiccup which rendered the volume which backed our GitLab repositories unavailable for a few minutes. The interruption was long enough that the filesystem remounted as read-only. This caused a bit of filesystem damage affecting a handful of objects in the ghc/perf-notes repository. This resulted in CI failures when attempts to `git push` to this repository failed. To address this I started by ensuring we had an up-to-date backup of our data and began sorting through the various observed errors. Once I had established that the storage volume had been interrupted I went looking for additional corruption. A integrity check of all GitLab repositories revealed no further corruption. This isn't terribly surprising given that the perf notes repository sees the most commit traffic of all repositories hosted on GitLab. While it would likely be possible to recover the corrupted perf-notes objects from clones on the CI builders, I deemed this to be not worth the effort given that these commits hold replaceable performance metric data and the last good commit appears to have been produced mere hours prior to the corrupted HEAD commit. Consequently, I rather reverted the ghc-notes repository to the last-known-good commit (8154013bfdce86fedf2863cb96ccbb723f1144f8). # Planned changes for future mitigation While this incident didn't result in any significant data loss, it was nevertheless a significant headache and resulted in CI failing for the better part of a day. Moreover, this isn't the first time that the network block storage backing GitLab has let us down. At this point, I have lost confidence that network block storage can be trusted. For this reason, in the future we will eliminate this failure mode by adjusting our deployment to avoid relying on network block storage for any deployment-critical data. We hope that we will be able to carry out this change in the coming weeks.

1 2

[ghc-lib] internal error after removal of integer-simple
by Shayne Fletcher 20 Jun '20

20 Jun '20

With the recent MR that removes integer-simple in favor of ghc-bignum, I find that I get a runtime failure when I try to use ghc-lib to generate core: ``` # Running: stack --no-terminal exec -- mini-compile examples/mini-compile/test/MiniCompileTest.hs examples/mini-compile/test/MiniCompileTest.hs:66:5: error: * GHC internal error: `One' is not in scope during type checking, but it passed the renamer tcl_env of environment: [628 :-> ATcTyCon TrName :: *, 62b :-> APromotionErr RecDataConPE, 62e :-> APromotionErr RecDataConPE] * In the definition of data constructor `TrNameS' In the data declaration for `TrName' | 66 | = TrNameS Addr# -- Static | ^^^^^^^^^^^^^ mini-compile: GHC internal error: `One' is not in scope during type checking, but it passed the renamer tcl_env of environment: [628 :-> ATcTyCon TrName :: *, 62b :-> APromotionErr RecDataConPE, 62e :-> APromotionErr RecDataConPE] ``` Anyone have any pointers on what is going wrong and what I should be looking at? -- *Shayne Fletcher* Language Engineer */* +1 917 699 7663 *Digital Asset* <https://digitalasset.com/>, creators of *DAML <https://daml.com/>* -- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html <http://www.digitalasset.com/emaildisclaimer.html>. If you are not the intended recipient, please delete this message.

4 9

Gitlab is stuck
by Simon Peyton Jones 19 Jun '20

19 Jun '20

Something is badly wrong with gitlab. I'm trying to push a branch. Is some disk full? I am fully stalled. Thanks Simon bash$ git push --force Counting objects: 79, done. Delta compression using up to 20 threads. Compressing objects: 100% (65/65), done. Writing objects: 100% (79/79), 46.21 KiB | 3.55 MiB/s, done. Total 79 (delta 68), reused 16 (delta 14) error: remote unpack failed: unable to create temporary object directory remote: warning: The last gc run reported the following. Please correct the root cause remote: and remove gc.log. remote: Automatic cleanup will not be performed until the file is removed. remote: remote: warning: There are too many unreachable loose objects; run 'git prune' to remove them. remote: To gitlab.haskell.org:ghc/ghc.git ! [remote rejected] wip/T18282 -> wip/T18282 (unpacker error) error: failed to push some refs to 'git@gitlab.haskell.org:ghc/ghc.git'

2 3

Gitlab corrupt
by Simon Peyton Jones 19 Jun '20

19 Jun '20

Ben Something is amiss. "corrupt" sounds bad! Simon bash$ git fetch error: garbage at end of loose object '62be92e5be07b34fc25c77e36223268c4a6eadec' fatal: loose object 62be92e5be07b34fc25c77e36223268c4a6eadec (stored in ./objects/62/be92e5be07b34fc25c77e36223268c4a6eadec) is corrupt fatal: The remote end hung up unexpectedly

2 1

Receiving type information from environment instead of hardcoding.
by Rinat Stryungis 19 Jun '20

19 Jun '20

Hi. I have a question about a possible way of unification of Nat and Natural. I've almost done that, but only in case of using integer-gmp. If I use integer-simple there is a completely different definition of Natural. How I construct now naturalTyCon (to make `naturalTy` to use it instead of `typeNatKind`) : ```naturalTyCon :: TyCon naturalTyCon = pcTyCon naturalTyConName Nothing [] [natSDataCon,natJDataCon] natSDataCon :: DataCon natSDataCon = pcDataCon natSDataConName [] [wordPrimTy] naturalTyCon etc... ``` Now I have to check`DynFlags` in a few places to reimplement `naturalTyCon` in case of using `integer-simple`. Is there a way to avoid hardcoding of `naturalTy`? My colleague said that it would be nice to get `naturalTy` from an environment by something like `lookupTyCon`, but there are many functions whose don't use any environment like functions from `typeNatTyCons` list in `GHC.Builtin.Types.Literals`. Now I am going to use `DynFlags` checking, but it looks like an ugly way... -- Best regards. Rinat Striungis

3 3