November 2017 - ghc-devs

Cutting the GHC 8.4 branch
by Ben Gamari 09 Nov '17

09 Nov '17

Hello everyone, As described earlier in the fall, with the GHC 8.4 release we will be trying to hold to a more reliable six-month release cycle. Towards this end we will be generally try to cut major release branches three months before the release date. As GHC 8.4 is slated to be released in February 2018, we are quickly approaching that three-month mark. Consequently I'd like to try cutting a branch next week. There are a few things that need to happen in the interim: * Hadrian needs to be merged (this should be done by the end of the day today) * Tamar's patches bumping our Windows toolchain need to be merged (they are in my merge queue) * A bunch of submodule bumps The remainder of the Trees That Grow work may not be entirely merged by the time we branch but Alan and I will arrange that things are merged after the fact. If you have work that you would like to see merged, please do let me know. If things go according to plan, we will produce our first alpha release shortly after the branch. Cheers, - Ben

1 0

GHC 8.2 GC time stats going negative
by Harendra Kumar 09 Nov '17

09 Nov '17

Hi, I am trying to use the mutator_cpu_ns and mutator_elapsed_ns from GHC 8.2 RTSStats structure retrieved using getRTSStats API documented here - https://hackage.haskell.org/package/base-4.10.0.0/docs/GHC-Stats.html . I am seeing that the values of these stats retrieved about 30 ms later are lower than the values retrieved earlier. Sometimes even after 100 ms the values decrease from the previous ones. However, as the time duration between two calls increase this becomes less and less likely. Is this an expected behavior or am I using it incorrectly? If it is expected, why does it happen, what is the underlying mechanism that makes it happen? Thanks, harendra

2 3

T14394 output
by Ben Gamari 08 Nov '17

08 Nov '17

Hi Simon, It seems that your recent commit 30058b0e45e9 may not be quite right. Specifically, the expected output for T14394 is empty, whereas the test is almost certainly going to produce output. The current output is, pattern Foo :: () => (b ~ a) => a :~~: b -- Defined at <interactive>:5:1 pattern Bar :: forall k2 k1 (a :: k1) (b :: k2). () => (k2 ~ k1, (b :: k2) ~~ (a :: k1)) => a :~~: b -- Defined at <interactive>:11:1 pattern Bam :: () => Ord a => a -> a -> (S a, S a) -- Defined at <interactive>:21:1 Does this look right to you? Cheers, - Ben

2 1

Building on limited memory environments (or does -M really work?)
by Saurabh Nanda 08 Nov '17

08 Nov '17

Hi, We're struggling to get our build pipeline working on CircleCI, which has a 4GB RAM limit. Here are some project stats to set the context: - 1,200+ modules - 36,315 LoC of Haskell - On the local machine with -O1 -j the build takes approx 5.2 GB of RAM [1] Trying to build on CircleCI with -O1 -j fails consistently, as expected. However, the behaviour of -M -j -O1 is erratic, at best. Sometimes it magically works, sometimes it fails. A number of times we've seen GHC take 3.5 GB (as reported by `top`), even though the limit was set to 2.5GB. Here are flags that we've tried in various combinations we've tried. None of them is consistent in building / failing: * -O1 * -j * +RTS -M2621440000 -RTS * +RTS -A32m -RTS * +RTS -n2m -RTS What is the **real** behaviour of the -M option? How does it interact with -j and -A? [1] If I'm reading this correctly - https://gist.github.com/saurabhnanda/c8f8654a7f29c1adb753b357b897b5f3#file-… -- Saurabh.

4 5

tcSubsumes
by Richard Eisenberg 07 Nov '17

07 Nov '17

Hi Simon, Could you take a look at TcSimplify.tcSubsumes? This relatively new function pushes the TcLevel when calling tcSubType, but then doesn't set the TcLevel when calling the solver. Inexplicably, this sometimes works -- even passing the testsuite. Somehow, my work caused this to fail. I fixed it by setting the TcLevel before calling the solver. Two questions: 1. Is this a reasonable fix? 2. (optional) How is it possible that this didn't fail drastically often? Note (to author / reviewers of this function): my astonishment isn't that this error crept into the codebase -- I've done similar many many times. My astonishment is how the testsuite didn't find this error forthwith. Thanks, Richard

2 1

valid substitutions for holes
by Richard Eisenberg 07 Nov '17

07 Nov '17

Hi all, GHC HEAD currently suggests valid in-scope single-identifier substitutions for typed holes (underscores in terms). Some unrelated work somehow changed the output, and I'm wondering if this is a change for the better or for the worse. The test case is this: > f :: Int -> Int -> Int > f x y = _ x y With my patch, GHC now suggests `pure` and `return` as replacements for _ (along with the other top contenders of (-), asTypeOf, and const). (You can also increase the number of suggestions, which will then include (+) and (*) among others.) It's true that `pure` and `return` fit the bill, noting that ((->) Int) is an Applicative. But I doubt these suggestions will help the user. I'm not keen to make fixing this "valid suggestions" feature (which I do really like) a dependency of finishing my patch, but I also don't want the change to output to go unnoticed. So, I'm asking: when I merge my patch, should I post a bug asking for perhaps a priority ordering of suggestions? Thanks, Richard

2 1

Re: [Haskell-cafe] [ANNOUNCE] GHC 8.2.2 release candidate 2
by Sven Panne 06 Nov '17

06 Nov '17

2017-11-05 15:37 GMT+01:00 <jpaugh(a)gmx.com>: > A better approach might be to develop a "machine-readable" output format > which then is kept stable, and can be enabled with a flag. Git has a > similar solution. > Without doubt, this is definitely the better approach, but this is hardly what can be achieved for 8.2.2. Adding some flag to get the old behavior back when wanted *is* achievable. > It would be a shame to avoid changes which make the user experience better > simply because other projects cannot sync their development cycle, > Don't get me wrong: I'm all for improving user experience, but making ad hoc changes without enough thought or even a chance to get the old behavior back is probably not the right way to proceed. All SW lives in some kind of ecosystem, so it should behave well in that. And for Emacs users, the user experience has been made much worse. > especially if those projects are not universally used or required. > This is highly a matter of personal taste: No project is "universally used", so this is tautological statement. The question is: Is a minor cosmetic change really worth breaking things in one of the major IDEs? Cheers, S.

3 3

GHC build broken
by Simon Peyton Jones 06 Nov '17

06 Nov '17

Ben: I'm getting this from a clean build on Linux. Any ideas? I'm up to date on master git branch -v data-kind-syntax 4174458178 Add IfacePromotionInfo * master 436b3ef01e Clean up comments about match algorithm a bit. tc-untouchables b737a45391 More simplifications to the constraint solver type-nats 87d2a63b8d [behind 1491] Fix uses of (<=?) as a function to reduce properly. wip/pattern-synonyms e54d396752 [ahead 6, behind 4569] Comments and tracing only wip/spj-T13397 43540c8c6b Improve code generation for conditionals wip/spj-early-inline 8515fcfa91 Mark non-recursive join lambdas as one-shot simonpj@cam-05-unx:~/code/HEAD/compiler$ Simon libraries/ghc-prim/cbits/atomic.c:311:54: error: error: '__ATOMIC_SEQ_CST' undeclared (first use in this function) | 311 | __atomic_store_n((StgWord16 *) x, (StgWord16) val, __ATOMIC_SEQ_CST); | ^ libraries/ghc-prim/cbits/atomic.c: In function 'hs_atomicwrite32': make[1]: *** [libraries/ghc-prim/dist-install/build/cbits/atomic.o] Error 1 make[1]: *** Waiting for unfinished jobs.... libraries/ghc-prim/cbits/atomic.c:318:54: error: error: '__ATOMIC_SEQ_CST' undeclared (first use in this function) | 318 | __atomic_store_n((StgWord32 *) x, (StgWord32) val, __ATOMIC_SEQ_CST); | ^ libraries/ghc-prim/cbits/atomic.c: In function 'hs_atomicwrite64': libraries/ghc-prim/cbits/atomic.c:325:54: error: error: '__ATOMIC_SEQ_CST' undeclared (first use in this function) | 325 | __atomic_store_n((StgWord64 *) x, (StgWord64) val, __ATOMIC_SEQ_CST); | ^ libraries/ghc-prim/cbits/atomic.c: In function 'hs_atomicread64': libraries/ghc-prim/cbits/atomic.c:294:1: error: error: control reaches end of non-void function [-Werror=return-type] | 294 | } | ^ libraries/ghc-prim/cbits/atomic.c: In function 'hs_atomicread32': libraries/ghc-prim/cbits/atomic.c:287:1: error: error: control reaches end of non-void function [-Werror=return-type] | 287 | } | ^ libraries/ghc-prim/cbits/atomic.c: In function 'hs_atomicread16': libraries/ghc-prim/cbits/atomic.c:280:1: error: error: control reaches end of non-void function [-Werror=return-type] | 280 | } | ^ libraries/ghc-prim/cbits/atomic.c: In function 'hs_atomicread8': libraries/ghc-prim/cbits/atomic.c:273:1: error: error: control reaches end of non-void function [-Werror=return-type] | 273 | } | ^ cc1: all warnings being treated as errors `gcc' failed in phase `C Compiler'. (Exit code: 1) make[1]: *** [libraries/ghc-prim/dist-install/build/cbits/atomic.dyn_o] Error 1 <<ghc: 14960944 bytes, 10 GCs, 194012/240680 avg/max bytes residency (2 samples), 54M in use, 0.000 INIT (0.000 elapsed), 0.024 MUT (0.187 elapsed), 0.012 GC (0.033 elapsed) :ghc>> make: *** [all] Error 2 simonpj@cam-05-unx:~/5builds/HEAD$ dirs ~/5builds/HEAD ~/5builds/HEAD/testsuite/tests/typecheck/should_fail simonpj@cam-05-unx:~/5builds/HEAD$

2 2

[ANNOUNCE] GHC 8.2.2 release candidate 2
by Ben Gamari 05 Nov '17

05 Nov '17

Hello everyone, The GHC team is very pleased to announce the second candidate of the 8.2.2 release of the Glasgow Haskell Compiler. Source and binary distributions are available at https://downloads.haskell.org/~ghc/8.2.2-rc2/ This is the second and hopefully last of two release candidates leading up the final 8.2.2 release. This release fixes approximately fifty bugs present in 8.2.1. These most notably include, * A correctness issue resulting in segmentation faults in some FFI-users (#13707, #14346) * A correctness issue resulting in undefined behavior in some programs using STM (#14171) * A bug which may have manifested in segmentation faults in out-of-memory condition (#14329) * clearBit of Natural no longer bottoms (#13203) * A specialisation bug resulting in exponential blowup of compilation time in some specialisation-intensive programs (#14379) * ghc-pkg now works even in environments with misconfigured NFS mounts (#13945) * GHC again supports production of position-independent executables (#13702) * Better error messages around kind mismatches (#11198, #12373, #13530, #13610) See [1] for the full list. As always, please report any issues you encounter. Happy testing, - Ben [1] https://ghc.haskell.org/trac/ghc/query?status=closed&milestone=8.2.2&col=id…

4 3

Re: [ANNOUNCE] GHC 8.2.2 release candidate 2
by Ben Gamari 04 Nov '17

04 Nov '17

Peter Trommler <Peter.Trommler(a)th-nuernberg.de> writes: > Hi Ben, > > Building and packaging RC2 on openSUSE works on all openSUSE platforms. > I noticed, however, that versions of Cabal and process were downgraded > from the respective versions in ghc 8.2.1: > > Cabal 2.0.0.2 -> 2.0.0.0 > process 1.6.1.0 -> 1.6.0.0 > Thanks for pointing this out, Peter. It seems that my source distribution script cleans submodules, but doesn't actually run `git submodule update`, hence the issue. Quite unfortunate and yet another argument for building these artifacts via CI. I suppose at this point we have two options: 1. invalidate the release, cut an -rc3 and try again, or 2. make the issue known but continue testing under the assumption that the submodule issues won't interact with any of the other changes and eventually and move directly to 8.2.2 final Unfortunately at the moment I'm rather deep in debugging a codegen bug, so I don't have the bandwidth to handle either of these at the moment. Cheers, - Ben > Peter >> On 31. Oct 2017, at 19:15, Ben Gamari <ben(a)well-typed.com> wrote: >> >> >> Hello everyone, >> >> The GHC team is very pleased to announce the second candidate of the >> 8.2.2 release of the Glasgow Haskell Compiler. Source and binary >> distributions are available at >> >> https://downloads.haskell.org/~ghc/8.2.2-rc2/ >> >> [...] >> As always, please report any issues you encounter. >> >> Happy testing, >> >> - Ben

1 0