- ghc-devs - Haskell.org

Paren removal in renamer
by Alan & Kim Zimmerman 21 Nov '16

21 Nov '16

Hi all I have been wrestling with something silly most of today. T12530 has the following splice in it, which has parens around the "(Maybe Int)". $([d| -- Test the Template Haskell pretty-printing for TypeApplications f = id @(Maybe Int) |]) the parsed source has these parens, but they are removed for the renamed source. I am modifying the pretty printer to be faithful to the original source, so when the renamed source is printed it has no parens, causing T12530 to fail. I have looked all over the source, and cannot see where the HsParTy is removed. Can anyone give me a pointer? See details here [1] My current work branch is here [2], but I am pretty sure there are no changes affecting this there. [1] http://lpaste.net/1624164315596587008 [2] https://github.com/alanz/ghc/tree/wip/T3384 Regards Alan

1 0

Heads up: Git HEAD now requres LLVM 3.9
by Erik de Castro Lopo 18 Nov '16

18 Nov '16

Hi all, With the landing of https://phabricator.haskell.org/D2719 GHC git HEAD now requires LLVM 3.9. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

1 0

GHC 8.0.2 status
by Ben Gamari 18 Nov '16

18 Nov '16

Hello GHCers, Thanks to the work of darchon the last blocker for the 8.0.2 release (#12479) has nearly been resolved. After the fix has been merged I'll be doing some further testing of the ghc-8.0 branch and cut a source tarball for 8.0.2-rc1 later this week. If you intend on offering a binary release for 8.0.2 it would be great if you could plan on testing the tarball promptly so we can cut 8.0.2 and move on to planning for 8.2.1. Thanks for your help and patience! Cheers, - Ben

4 8

GHC archeology and git commit hashes
by Ismael Figueroa 18 Nov '16

18 Nov '16

Dear ghc devs, I'm doing some archeology of the GHC codebase, and I need to map every release to a given git tag/commit/hash. So far, based on the official webpage and Github mirror, I have done it for releases from 7.2.1 until 8.0.1. However, it is not clear to me: - whether there is a corresponding point in history for releases before 7.2.1 - what are the corresponding commits, if any >From what I can get at a glance, at this point in time the source code was managed in a DARCS repository, right? Would you please be so kind to point me in the right direction, in order to correctly perform this mapping? Thanks in advance! -- Ismael

2 1

RE: windows build
by Simon Peyton Jones 17 Nov '16

17 Nov '16

Whizzo! Window builds are up again. Thank you! Here are the errors I get, which seem more manageable. Simon Unexpected passes: rts/T7037.run T7037 [unexpected] (normal) Unexpected failures: ghci/prog003/prog003.run prog003 [bad exit code] (ghci) plugins/plugins07.run plugins07 [bad exit code] (normal) Unexpected stat failures: perf/haddock/haddock.compiler.run haddock.compiler [stat not good enough] (normal) perf/should_run/T876.run T876 [stat too good] (normal) Framework failures: plugins/plugins07.run plugins07 [normal] (pre_cmd failed: 2) | -----Original Message----- | From: Ben Gamari [mailto:ben@well-typed.com] | Sent: 17 November 2016 15:24 | To: Simon Peyton Jones <simonpj(a)microsoft.com> | Subject: RE: windows build | | Simon Peyton Jones <simonpj(a)microsoft.com> writes: | | > OK thank you. | > | > Meanwhile, what about the RTS error? | | A fix has been merged for the RTS issue | (b76958671cda1df9f6f0e1d54d681144d09cb06e). Tamar is still looking at the | testsuite driver issue (#12554) and has a suspicion that the issue is | file handle inheritance. He's going to try to put together a fix tonight. | | Cheers, | | - Ben

1 0

Linux -> Windows cross-compiling failed
by Bernard de la Paz 16 Nov '16

16 Nov '16

3 3

OverloadedRecordFields request for review
by Adam Gundry 16 Nov '16

16 Nov '16

Hi devs, I just wanted to draw your attention to the OverloadedRecordFields proposal [1], which I've just updated and now has a corresponding implementation ready for review on Phab [2]. I'd very much appreciate any feedback on either the design or implementation. Thanks, Adam [1] https://github.com/ghc-proposals/ghc-proposals/pull/6 [2] https://phabricator.haskell.org/D2708 -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

OSX build failing
by Matthew Pickering 14 Nov '16

14 Nov '16

Hi all, The OSX build is broken due to 55d535da10dd63bbaf03fb176ced7179087cd0d4 Should I revert the patch or is there a fix coming? Matt ===== commit 55d535da10dd63bbaf03fb176ced7179087cd0d4 Author: Simon Marlow <marlowsd(a)gmail.com> Date: Wed Nov 9 09:20:02 2016 +0000 Remove CONSTR_STATIC Summary: We currently have two info tables for a constructor * XXX_con_info: the info table for a heap-resident instance of the constructor, It has type CONSTR, or one of the specialised types like CONSTR_1_0 * XXX_static_info: the info table for a static instance of this constructor, which has type CONSTR_STATIC or CONSTR_STATIC_NOCAF. I'm getting rid of the latter, and using the `con_info` info table for both static and dynamic constructors. For rationale and more details see Note [static constructors] in SMRep.hs. I also removed these macros: `isSTATIC()`, `ip_STATIC()`, `closure_STATIC()`, since they relied on the CONSTR/CONSTR_STATIC distinction, and anyway HEAP_ALLOCED() does the same job. Test Plan: validate Reviewers: bgamari, simonpj, austin, gcampax, hvr, niteria, erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2690 https://phabricator.haskell.org/rGHC

1 1

Non-working "-no-pie" test?
by Gabor Greif 14 Nov '16

14 Nov '16

Hi all, The test for checking "-no-pie" support of GCC doesn't seem to work. See below: $ gcc --version gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4) Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ echo 'int main() { return 0; }' > conftest.c $ if gcc -o conftest -no-pie conftest.c > /dev/null 2>&1 ; then echo YEP ; else echo NOPE ; fi YEP $ if gcc -o conftest -no-pie conftest.c ; then echo YEP ; else echo NOPE ; fi gcc: unrecognized option '-no-pie' YEP $ if gcc -o conftest -no-pie conftest.c > /dev/null ; then echo YEP ; else echo NOPE ; fi gcc: unrecognized option '-no-pie' YEP Is the test supposed to check that there is nothing output into stdout? If so, it seems to fail. It leads to lots of failures when "make test", because gcc gets chatty. Cheers, Gabor PS: I have bash 4.1.

2 1

T12041 failing?
by Simon Marlow 14 Nov '16

14 Nov '16

I just saw the error below in a validate with -DDEBUG. Anyone know about this? --- /tmp/ghctest-uhJ8rt/test spaces/./indexed-types/should_fail/T12041.run/T12041.stderr.normalised 2016-11-09 12:13:38.206501840 +0000 +++ /tmp/ghctest-uhJ8rt/test spaces/./indexed-types/should_fail/T12041.run/T12041.comp.stderr.normalised 2016-11-09 12:13:38.206501840 +0000 @@ -1,7 +1,17 @@ +ghc: panic! (the 'impossible' happened) + (GHC version 8.1.20161109 for x86_64-unknown-linux): + ASSERT failed! + i_axb + Call stack: + CallStack (from HasCallStack): + prettyCurrentCallStack, called at compiler/utils/Outputable.hs:<line>:<column> in <package-id>:Outputable + callStackDoc, called at compiler/utils/Outputable.hs:<line>:<column> in <package-id>:Outputable + assertPprPanic, called at compiler/typecheck/TcType.hs:<line>:<column> in <package-id>:TcType + Call stack: + CallStack (from HasCallStack): + prettyCurrentCallStack, called at compiler/utils/Outputable.hs:<line>:<column> in <package-id>:Outputable + callStackDoc, called at compiler/utils/Outputable.hs:<line>:<column> in <package-id>:Outputable + pprPanic, called at compiler/utils/Outputable.hs:<line>:<column> in <package-id>:Outputable + assertPprPanic, called at compiler/typecheck/TcType.hs:<line>:<column> in <package-id>:TcType -T12041.hs:12:15: - Expected kind â€˜i -> Constraintâ€™, - but â€˜(~) Intâ€™ has kind â€˜* -> Constraintâ€™ - In the type â€˜(~) Intâ€™ - In the type instance declaration for â€˜Obâ€™ - In the instance declaration for â€˜Category Iâ€™ +Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for T12041(normal)

2 2