- ghc-devs - Haskell.org

Simplifying subsumption
by Simon Peyton Jones 02 Feb '20

02 Feb '20

Jurriaan, Ben I have a MR up for #17775, which implements the now-accepted GHC proposal to simplify subsumption. https://gitlab.haskell.org/ghc/ghc/merge_requests/2600 However, it requires some eta expansions in haskeline, and maybe other packages. I don't know how to do that. Could you, or another member of the GHC support team, help do this? We want a MR we can validate on its own before committing, of course. Jurriaan has all the necessary library patches. We should not commit to HEAD until there has been some code review, though. Moreover as we know, when committed, it'll break a number of packages, so we need to broadcast a warning, along with the patches Jurriaan has to fix them. I'm not sure when and how to do that. Thanks! Simon

1 0

How to run the testsuite with an out of tree compiler?
by Matthew Pickering 01 Feb '20

01 Feb '20

I am trying to run `ghcide` on GHC's tests. The documentation says that I should pass `--test-compiler=..` to hadrian in order to do this. When I do this however it starts trying to configure a bunch of packages and starting to build stuff. I don't want hadrian to build anything, I just want it to use my patched version of GHC when running certain tests! How can I achieve this? Cheers, Matt

1 1

[ANNOUNCE] Glasgow Haskell Compiler 8.10.1-rc1 released
by Ben Gamari 31 Jan '20

31 Jan '20

Hello all, The GHC team is happy to announce the availability of the first release candidate of GHC 8.10.1. Source and binary distributions are available at the usual place: https://downloads.haskell.org/ghc/8.10.1-rc1/ 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 is the first and likely final release candidate. For a variety of reasons, it comes a few weeks later than the original schedule of release late December. However, besides a few core libraries book-keeping issues this candidate is believed to be in good condition for the final release. As such, the final 8.10.1 release will likely come in two weeks. Note that at the moment we still require that macOS Catalina users exempt the binary distribution from the notarization requirement by running `xattr -cr .` on the unpacked tree before running `make install`. In addition, we are still looking for any Alpine Linux to help diagnose the correctness issues in the Alpine binary distribution [1]. If you use Alpine any you can offer here would be greatly appreciated. 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

5 4

more submodule questions
by Richard Eisenberg 30 Jan '20

30 Jan '20

Hi devs, I recently found this text at the end of https://gitlab.haskell.org/ghc/ghc/wikis/working-conventions/git/submodules <https://gitlab.haskell.org/ghc/ghc/wikis/working-conventions/git/submodules> : --- The CI pipeline of ghc/ghc> <applewebdata://9E3625B8-2065-48C6-A8FA-16817EA6E642/ghc/ghc> includes a linting step to ensure that all submodules refer only to "persistent" commits of the upstream repositories (e.g. not wip/ branches, which may disappear in the future). Specifically, the linter checks that any submodules refer to commits that are reachable by at least one branch that doesn't begin with the prefix wip/. Consequently, you must ensure that any submodule changes introduced in a ghc/ghc> <applewebdata://9E3625B8-2065-48C6-A8FA-16817EA6E642/ghc/ghc> merge request are merged upstream before the merge request is added to the merge queue. --- I don't understand what this means. - By citing "ghc/ghc>", does this mean that the linter only checks for this on branches of the ghc/ghc repo? If I have a fork (e.g. rae/ghc), are these checks disabled? - Does this linter stop CI from progressing to, say, running the testsuite? If so, then how can we run the testsuite via CI if we have any submodule changes? We want to run the testsuite while the work is still in progress. - By "you must ensure ... before the merge request is added to the merge queue": this makes me wonder whether the linter is just a warning or an error. That is, if I must ensure it, then it suggests that CI is not ensuring it. Sorry to be dense here! Thanks, Richard

2 3

stage2 build fails
by Simon Peyton Jones 28 Jan '20

28 Jan '20

I'm getting this with "sh validate -legacy" compiler/main/DynFlags.hs:1344:15: error: [-Woverlapping-patterns, -Werror=overlapping-patterns] Pattern match is redundant In an equation for 'settings': settings s | otherwise = ... | 1344 | | otherwise = panic $ "Invalid cfg parameters." ++ exampleString | ^^^^^^^^^ This is when compiling the stage-2 compiler. There's an ifdef in DynFlags thus #if __GLASGOW_HASKELL__ <= 810 | otherwise = panic $ "Invalid cfg parameters." ++ exampleString #endif but somehow it's not triggering for the stage2 compiler. Any ideas? It's blocking a full build. This #ifdef was added in 8038cbd96f4, when GHC became better at reporting redundant code. Simon

4 12

Intree gmp builds using Hadrian use system gmp headers
by Carter Schonwald 28 Jan '20

28 Jan '20

Hey all, For those using Hadrian for platforms where intree gmp config is important, some sleuthing I’ve done over the past half seems to indicate that currently it’s not correct via Hadrian, but only via make. https://gitlab.haskell.org/ghc/ghc/issues/17756 I’m able to reproduce this on multiple OS X machines (though it took me a while to read apart that is Hadrian specific.) Punchline : at the moment, Hadrian intree gmp builds succeed because gmp headers in default include search paths of gcc/clang get picked up. In a properly isolated environment / one without the offending header leakage, I’m able at least on OS X to get Hadrian with intree gmp to consistently fail.

1 1

gaining access to the `ghc` group
by Richard Eisenberg 27 Jan '20

27 Jan '20

Hi devs, I'm onboarding a new contributor (Gert-Jan Bottu), whose patch (!2465) makes commensurate changes in Haddock. In order to use CI, then, he needs to be able to push a wip/ branch to our fork of Haddock. In order to do that, he needs to be in the `ghc` group. (I'm assuming -- but have not checked -- that just forking Haddock on the gitlab.haskell.org <http://gitlab.haskell.org/> instance is not enough. The wiki page on submodules (https://gitlab.haskell.org/ghc/ghc/wikis/working-conventions/git/submodules <https://gitlab.haskell.org/ghc/ghc/wikis/working-conventions/git/submodules>) suggests it is not.) That same wiki page says the one needs merely ask to join the `ghc` group. Good. So I follow the "ask" link to get to https://gitlab.haskell.org/ghc/ghc/wikis/mailing-lists-and-irc#mailing-list… <https://gitlab.haskell.org/ghc/ghc/wikis/mailing-lists-and-irc#mailing-list…> . That page helpfully describes where we can be reached, but it's not all that helpful for someone who wants to join the `ghc` group. According to that page, newcomers have to post publicly in either ghc-devs (I have never seen such a request there) or in #ghc. If I'm new in town, I wouldn't feel all that happy doing so, likely wanting to wait until I actually had a patch accepted before requesting rights.... but of course I need access to CI in order to get a patch accepted. Instead, would it be possible to have some sort of ghc-admin list, perhaps? While (I think) I know the individuals to contact for a request like this, an official mailing list would make this more transparent and, in my opinion, easier to onboard new contributors. I understand if folks don't want yet another mailing list, but then is here some other approach here that doesn't require posting in public? Thanks! Richard

2 2

Anyone able to build current master on OS X with GCC?
by Carter Schonwald 25 Jan '20

25 Jan '20

I’m finding myself only able to successfully run a full validate build if I set the build configuration to use clang rather than gcc. Otherwise I get a cpp error that makes it look like some #defines are missing in the Gmp binding codes. Anyone able to do a gcc flavored Mac build that survives validate recently ?

1 0

[ghc-steering-committee] The GHC Committee welcomes its new members
by Joachim Breitner 24 Jan '20

24 Jan '20

Dear Haskell community, the GHC Steering committee welcomes three new members, Alejandro Serrano Mena, Cale Gibbard and Tom Harding. We are happy to see that there is continued interest in our work, and are looking forward to having fresh insights and energy on the committee. They take the seat of Sandy Maguire, who we thank for this productive work during his tenure. As you might notice, we picked more candidates than we filled slots. This is not because Sandy’s productivity need three people to fill. The idea is that there is no reason to turn away a motivated contributor just to stick to the arbitrary 10 members. Instead, we will aim at “roughly 10”, and probably not call for new members until we have dropped below that number again. On behalf of the committee, Joachim Breitner PS: Alejandro, Cale and Tom, please send me your github handles and subscribe to the mailing list at https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de https://www.joachim-breitner.de/

1 0

Bug in SRT generation for procs in .cmm files?
by Ömer Sinan Ağacan 24 Jan '20

24 Jan '20

Hi Simon, Currently CmmParse only generates CmmLabels for procs, and those are considered non-CAFFY by hasCAF (and thus CmmBuildInfoTables). As a result if I have two procs in a .cmm file: - p1, refers to a CAF in base - p2, refers to p1 I *think* (haven't checked) we don't consider p1 as CAFFY, and even if we do, we don't consider p2 as CAFFY becuase the reference from p2 to p1 won't be considered CAFFY by hasCAF. So we currently can't define a CAFFY Cmm proc in .cmm files as the SRT algorithm will never build SRTs for procs in .cmm files. Is this intentional? I'd expect this to be possible, because there's nothing preventing me from referring to a CAFFY definition in a library (e.g. base) in a .cmm file, but doing this would be a bug in runtime. Thanks, Ömer

3 3