January 2017 - ghc-devs

[ANNOUNCE] Glasgow Haskell Compiler 8.0.2 is available!
by Ben Gamari 18 Jan '17

18 Jan '17

=============================================== The Glasgow Haskell Compiler -- version 8.0.2 =============================================== The GHC team is happy to at last announce the 8.0.2 release of the Glasgow Haskell Compiler. Source and binary distributions are available at http://downloads.haskell.org/~ghc/8.0.2/ This is the second release of the 8.0 series and fixes nearly two-hundred bugs. These include, * Interface file build determinism (#4012). * Compatibility with macOS Sierra and GCC compilers which compile position-independent executables by default * Compatibility with systems which use the gold linker * Runtime linker fixes on Windows (see #12797) * A compiler bug which resulted in undefined reference errors while compiling some packages (see #12076) * A number of memory consistency bugs in the runtime system * A number of efficiency issues in the threaded runtime which manifest on larger core counts and large numbers of bound threads. * A typechecker bug which caused some programs using -XDefaultSignatures to be incorrectly accepted. * More than two-hundred other bugs. See Trac [1] for a complete listing. * #12757, which lead to broken runtime behavior and even crashes in the presence of primitive strings. * #12844, a type inference issue affecting partial type signatures. * A bump of the `directory` library, fixing buggy path canonicalization behavior (#12894). Unfortunately this required a major version bump in `directory` and minor bumps in several other libraries. * #12912, where use of the `select` system call would lead to runtime system failures with large numbers of open file handles. * #10635, wherein -Wredundant-constraints was included in the -Wall warning set A more detailed list of the changes included in this release can be found in the release notes, https://downloads.haskell.org/~ghc/8.0.2/docs/html/users_guide/8.0.2-notes.… Please note that this release breaks with our usual tendency to avoid major version bumps of core libraries in minor GHC releases by including an upgrade of the `directory` library to 1.3.0.0. Also note that, due to a rather serious bug (#13100) affecting Windows noticed late in the release cycle, the Windows binary distributions were produced using a slightly patched [2] source tree. Users compiling from source for Windows should be certain to include this patch in their build. This release is the result of six months of effort by the GHC development community. We'd like to thank everyone who has contributed code, bug reports, and feedback to this release. It's only due to their efforts that GHC remains a vibrant and exciting project. [1] https://ghc.haskell.org/trac/ghc/query?status=closed&milestone=8.0.2&col=id… [2] http://downloads.haskell.org/~ghc/8.0.2/0001-SysTools-Revert-linker-flags-c… How to get it ~~~~~~~~~~~~~ Both the source tarball and binary distributions for a wide variety of platforms are available at, http://www.haskell.org/ghc/ Background ~~~~~~~~~~ Haskell is a standardized lazy functional programming language. The Glasgow Haskell Compiler (GHC) is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating efficient code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces. GHC is distributed under a BSD-style open source license. Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, can be found on the GHC wiki http://ghc.haskell.org/trac/ghc/wiki/Platforms Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://ghc.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on getting started with hacking on GHC are available from GHC's developer site, http://ghc.haskell.org/trac/ghc/ Community Resources ~~~~~~~~~~~~~~~~~~~ There are mailing lists for GHC users, develpoers, and monitoring bug tracker activity; to subscribe, use the web interfaces at http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets There are several other Haskell and GHC-related mailing lists on www.haskell.org; for the full list, see https://mail.haskell.org/cgi-bin/mailman/listinfo Some GHC developers hang out on the #ghc and #haskell of the Freenode IRC network, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug

3 3

Join points
by Luke Maurer 17 Jan '17

17 Jan '17

Hello all! For your consideration, I present patch D2853: Join points. https://phabricator.haskell.org/D2853 It validates* and it's ready for wider reviewing, so please help me get it to land before the freeze! It's ... sizable. There's not really any way to split it, since there are many interdependencies. I've put up a "tour" as part of the SequentCore page on the wiki: https://ghc.haskell.org/trac/ghc/wiki/SequentCore This should help with where to start. Also included on the wiki are benchmarks and lots of general information. *Modulo a few long URLs and a known bug (D2964). - Luke Maurer University of Oregon maurerl(a)cs.uoregon.edu

2 1

Windows build
by Simon Peyton Jones 17 Jan '17

17 Jan '17

Hi Tamar The current state of a clean Windows build has improved - but still has multiple failures. See below Thanks for your work on this. I can send more details if that'd be helpful Simon Unexpected failures: plugins/plugins07.run plugins07 [bad exit code] (normal) plugins/T10420.run T10420 [bad exit code] (normal) plugins/T10294a.run T10294a [bad exit code] (normal) plugins/T11244.run T11244 [bad stderr] (normal) Framework failures: backpack/cabal/bkpcabal03/bkpcabal03.run bkpcabal03 [runTest] (Unhandled exception: [Errno 90] Directory not empty: 'autogen') plugins/plugins07.run plugins07 [normal] (pre_cmd failed: 2) plugins/T10420.run T10420 [normal] (pre_cmd failed: 2) plugins/T10294a.run T10294a [normal] (pre_cmd failed: 2) plugins/plugins07.run plugins07 [runTest] (Unhandled exception: [Errno 90] Directory not empty: 'rule-defining-plugin-0.1') plugins/T11244.run T11244 [normal] (pre_cmd failed: 2) safeHaskell/check/pkg01/ImpSafeOnly03.run ImpSafeOnly03 [runTest] (Unhandled exception: [Errno 90] Directory not empty: 'safePkg01-1.0-COK8JB4prM8EuKYKd3XaX3')

2 1

recomp001 failing on OSX for Phab:D2853
by Luke Maurer 17 Jan '17

17 Jan '17

Getting an odd test failure from Phab: @@ -1,2 +0,0 @@ - -C.hs:3:11: Module ‘B’ does not export ‘foo’ Actual stderr output differs from expected: *** unexpected failure for recomp001(normal) https://phabricator.haskell.org/harbormaster/build/18499/?l=0 I can't explain how my changes would break module exports *at all,* much less only on OSX. Found a Mac (running Mavericks and GHC 8.0.1) but couldn't reproduce it there. Thoughts? I'd love to nail this as soon as possible so I can get join points in before the feature freeze ... - Luke Maurer University of Oregon maurerl(a)cs.uoregon.edu

2 2

[GHC Proposal] "Constraint to Bool" wired-in type family
by Ben Gamari 17 Jan '17

17 Jan '17

Hello everyone, Sylvain Henry just opened Pull Request #22 [1] against the ghc-proposals repository. This proposal describes a type family which would given users access to type-level evidence of the satisfiability of a constraint. Please feel free to read and discuss the proposal on the pull request. Cheers, - Ben [1] https://github.com/ghc-proposals/ghc-proposals/pull/22

1 1

RE: [Diffusion] [Build Failed] rGHC5a9a1738023a: Refine exprOkForSpeculation
by Simon Peyton Jones 16 Jan '17

16 Jan '17

I'm sorry but I cannot make head or tail of the offending build log here. I validated from scratch at my end. Could it be a Harbormaster error? Simon From: noreply(a)phabricator.haskell.org [mailto:noreply@phabricator.haskell.org] Sent: 16 January 2017 16:52 To: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: [Diffusion] [Build Failed] rGHC5a9a1738023a: Refine exprOkForSpeculation Harbormaster failed to build B13227: rGHC5a9a1738023a: Refine exprOkForSpeculation! BRANCHES master USERS simonpj (Author) O12 (Auditor) O20 (Auditor) COMMIT https://phabricator.haskell.org/rGHC5a9a1738023a EMAIL PREFERENCES https://phabricator.haskell.org/settings/panel/emailpreferences/ To: simonpj, Harbormaster

2 1

Including remote-iserv upstream?
by Shea Levy 16 Jan '17

16 Jan '17

Hi Simon, devs, As part of my work to get TH working when cross-compiling to iOS, I've developed remote-iserv [1] (not yet on hackage), a set of libraries for letting GHC communicate with an external interpreter that may be on another machine. So far, there are only three additions of note on top of what the ghci library offers: 1. The remote-iserv protocol has facilities for the host sending archives and object files the target doesn't have (dynlibs not yet implemented but there's no reason they can't be). This works by having the server send back a Bool after a loadObj or loadArchive indicating whether it needs the object sent, and then just reading it off the Pipe. 2. The remote-iserv lib abstracts over how the Pipe it communicates over is obtained. One could imagine e.g. an ssh-based implementation that just uses stdin and stdout* for the communication, the implementation I've actually tested on is a TCP server advertised over bonjour. 3. There is a protocol version included to address forwards compatibility concerns. As the library currently stands, it works for my use case. However, there would be a number of benefits if it were included with ghc (and used for local iserv as well): 1. Reduced code duplication (the server side copies iserv/src/Main.hs pretty heavily) 2. Reduced overhead keeping up to date with iserv protocol changes 3. No need for an extra client-side process, GHC can just open the Pipe itself 4. Proper library distribution in the cross-compiling case. The client needs to be linked with the ghci lib built by the stage0 compiler, as it runs on the build machine, while the server needs to be linked with the ghci lib built by the stage1 compiler. With a distribution created by 'make install', we only get the ghci lib for the target. Currently, I'm working around this by just using the ghci lib of the bootstrap compiler, which in my case is built from the same source checkout, but of course this isn't correct. If these libs were upstream, we'd only need one version of the client lib exposed and one version of the server lib exposed and could have them be for the build machine and the target, respectively 5. Better haskell hackers than I invested in the code ;) Thoughts on this? Would this be welcome upstream in some form? Thanks, Shea * Note that, in the general case, having the server process's stdio be the same as the compiler's (as we have in the local-iserv case) is not possible. Future work includes adding something to the protocol to allow forwarding stdio over the protocol pipe, to make GHCi usable without watching the *server*'s console. [1]: https://github.com/obsidiansystems/remote-iserv

3 4

Exhaustiveness checking for pattern synonyms
by Matthew Pickering 14 Jan '17

14 Jan '17

Hello devs, I have implemented exhaustiveness checking for pattern synonyms. The idea is very simple, you specify a set of pattern synonyms (or data constructors) which are regarded as a complete match. The pattern match checker then uses this information in order to check whether a function covers all possibilities. Specification: https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms/CompleteSigs https://phabricator.haskell.org/D2669 https://phabricator.haskell.org/D2725 Matt

3 4

Travis Builds are broken
by Matthew Pickering 13 Jan '17

13 Jan '17

A recent commit has caused the Travis builds to stop working. I think it was caused by https://phabricator.haskell.org/rGHCc2bd62ed62d2fae126819136d428989a7b4ddc79 Example failure Wrong exit code for plugins01()(expected 0 , actual 2 ) Stderr ( plugins01 ): ghc-stage2: /home/travis/build/ghc/ghc/libraries/ghci/dist-install/build/HSghci-8.1.o: unknown symbol `purgeObj' ghc-stage2: unable to load package `ghci-8.1' make[2]: *** [plugins01] Error 1 *** unexpected failure for plugins01(normal) Full log: https://s3.amazonaws.com/archive.travis-ci.org/jobs/190738798/log.txt Jon, could you perhaps take a look to see if the fix is obvious? Matt

1 0

Kind page of trac wiki
by Takenobu Tani 13 Jan '17

13 Jan '17

Dear devs, May I update Kind page of trac wiki [1] as following ? - "#" is the kind of unboxed values. Things like Int# have kind #. + "#" is the kind of unlifted values. Things like Int# have kind #. Is this correct? (These pages [2][3] are explained as "unlifted values".) [1]: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Kinds [2]: https://ghc.haskell.org/trac/ghc/wiki/UnliftedDataTypes [3]: https://ghc.haskell.org/trac/ghc/wiki/NoSubKinds Regards, Takenobu

2 2