- ghc-devs - Haskell.org

GHC's Fall 2018 HCAR submission
by Ben Gamari 12 Nov '18

12 Nov '18

Hello everyone, The Haskell Community Activities Report is coming up and I have prepared the skeleton for GHC's contribution [1]. If you have a project cooking or have recently had a patch land do have a look to make sure it's recognized in the submission. Cheers, - Ben https://ghc.haskell.org/trac/ghc/wiki/Status/Oct18

6 10

Help on tuple section in TH
by Yotam Ohad 12 Nov '18

12 Nov '18

Hello, I'm a wannabe ghc contributor on my first patch. I'm trying to do #15843 and I would like some help. I understand that I need to change repE in DsMeta.hs An explanation of the type signatures and the types would be very helpful. Also, What does repLEs do? Thanks for your help Yotam

3 2

Re: Suppressing False Incomplete Pattern Matching Warnings for Polymorphic Pattern Synonyms
by Ryan Scott 10 Nov '18

10 Nov '18

You *can* put `LL` into a COMPLETE set, but under the stipulation that you specify which type constructor it's monomorphized to. To quote the wiki page on COMPLETE sets: In the case where all the patterns are polymorphic, a user must provide a type signature but we accept the definition regardless of the type signature they provide. The type constructor for the whole set of patterns is the type constructor as specified by the user. If the user does not provide a type signature then the definition is rejected as ambiguous. This design is a consequence of the design of the pattern match checker. Complete sets of patterns must be identified relative to a type. This is a sanity check as users would never be able to match on all constructors if the set of patterns is inconsistent in this manner. In other words, this would work provided that you'd be willing to list every single instance of `HasSrcSpan` in its own COMPLETE set. It's tedious, but possible. Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms/CompleteSigs#Typing

5 9

trac ticket about missing in tree gmp on newest mac ghc builds
by Carter Schonwald 09 Nov '18

09 Nov '18

hey Ben, HVR https://ghc.haskell.org/trac/ghc/ticket/15769 seems to indicate there was quite a serious faux pas in the mac builds, do you folk need help? -Carter

1 0

StgRhsClosure freevar and argument name duplicates
by Csaba Hruska 07 Nov '18

07 Nov '18

Hi, Can StgRhsClosure's freevar list ([occ]) or argument list ([bndr]) contain duplicates? Cheers, Csaba data GenStgRhs bndr occ = StgRhsClosure CostCentreStack -- CCS to be attached (default is CurrentCCS) StgBinderInfo -- Info about how this binder is used (see below) *[occ]* -- non-global free vars; a list, rather than -- a set, because order is important !UpdateFlag -- ReEntrant | Updatable | SingleEntry *[bndr]* -- arguments; if empty, then not a function; -- as above, order is important. (GenStgExpr bndr occ) -- body

2 15

GHC 8.8 freeze in three weeks
by Ben Gamari 05 Nov '18

05 Nov '18

Hello everyone, Incredibly enough we are quickly coming up on three months since the nominal GHC 8.6.1 release date. This means that the GHC 8.8 branch is quickly approaching. We will plan on cutting the branch on November 18th. Note that this is in three weeks. If you have a patch that you would like to see in GHC 8.8 and it isn't yet up on Phabricator, do let me know. Moreover, if you have something that will be in GHC 8.8 and you haven't yet added it to the release status page [1], please add it. Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.8.1

2 2

[ANNOUNCE] GHC 8.6.2 is now available
by Ben Gamari 05 Nov '18

05 Nov '18

Hello everyone, The GHC team is very happy to announce the availability of GHC 8.6.2, a bugfix release to GHC 8.6.1. The source distribution, binary distributions, and documentation for this release are available at https://downloads.haskell.org/~ghc/8.6.2 The 8.6 release fixes several regressions present in 8.6.1 including: * A long-standing (but previously hard to manifest) bug resulting in undefined behavior for some applications of dataToTag# has been fixed (#15696) * An incorrect linker path to libgmp in the Mac OS binary distributions (#15404) * A regression rendering Windows installations to read-only directories unusable (#15667) * A regression resulting in panics while compiling some record updates of GADTs constructors (#15499) * A regression resulting in incorrect type errors when splicing types into constraint contexts has been fixed (#15815) * Around a dozen other issues. See Trac [1] for a full list of issues resolved in this release. Note that this release ships with one significant but long-standing bug (#14251): Calls to functions taking both Float# and Double# may result in incorrect code generation when compiled using the LLVM code generator. This is not a new issue, it has existed as long as the LLVM code generator has existed; however, changes in code generation in 8.6 made it more likely that user code using only lifted types will trigger it. Happy compiling! Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/query?status=closed&milestone=8.6.2&col=id…

1 0

multiple top level Main.main binders in STG
by Csaba Hruska 02 Nov '18

02 Nov '18

Hello, I added an STG exporter to my modified GHC to do experiments with the STG representation of the program. I noticed that there are multiple top-level binders for *Main.main* function. Is this a convention or a bug? Regards, Csaba Hruska Here is an example code snippet of the exported STG of the Main module: Main.main2 = closure (F:) (B:) { case Main.$wupto 1# 10000000# of sat.s16537 { DEFAULT -> case Main.$wxsum 0# sat.s16537 of ww.s16538 { DEFAULT -> case GHC.Show.$wshowSignedInt 0# ww.s16538 GHC.Types.[] of ww4.s16539 { GHC.Prim.(#,#) ww5.s16540 ww6.s16541 -> GHC.Types.: ww5.s16540 ww6.s16541 } } }} Main.main1 = closure (F:) (B: void.040) { GHC.IO.Handle.Text.hPutStr2 GHC.IO.Handle.FD.stdout Main.main2 GHC.Types.True GHC.Prim.void#} *Main.main* = closure (F:) (B: void.040) { Main.main1 GHC.Prim.void#} Main.main3 = closure (F:) (B: void.040) { GHC.TopHandler.runMainIO1 Main.main1 GHC.Prim.void#} *Main.main* = closure (F:) (B: void.040) { Main.main3 GHC.Prim.void#}

2 3

Visible dependent quantification / CUSKs
by Richard Eisenberg 02 Nov '18

02 Nov '18

Hi all, I see visible dependent quantification and top-level kind signatures on the release plan for GHC 8.8. Is there a diff for these I've missed? Or is something in the works? Sorry if I've just missed it go by! Thanks, Richard

2 2

RE: Hadrian build failed
by Andrey Mokhov 01 Nov '18

01 Nov '18

Hello Yotam, Could you please report this as a bug on GHC Trac? https://ghc.haskell.org/trac/ghc/wiki/ReportABug I couldn’t quickly reproduce your issue, however, I run into another seemingly unrelated problem. P.S.: Note that build instructions in my blog post got slightly out of date after the Hadrian move – I’ve fixed this. Cheers, Andrey -------- Forwarded Message -------- Subject: Hadrian build failed Date: Thu, 1 Nov 2018 20:33:14 +0200 From: Yotam Ohad <yotam2206(a)gmail.com><mailto:yotam2206@gmail.com> To: ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> Hi, I'm trying to build with hadrian (https://blogs.ncl.ac.uk/andreymokhov/building-ghc-on-windows/) I get an error when running: stack exec hadrian -- --directory ".." -j --flavour=quickest --configure md5sum: 'standard input': no properly formatted MD5 checksum lines found ERROR: mingw-w64-x86_64-crt-git-5.0.0.4795.e3d96cb1-1-any.pkg.tar.xz appears to be corrupted, please delete it and try again. ) Deleting and trying again results in the same error. Any idea on how to solve this? Yotam

1 0