November 2016 - ghc-devs

IRC: Logging #ghc with ircbrowse.net?
by Ben Gamari 25 Nov '16

25 Nov '16

Hello GHC developers, In the past we have relied upon Phabricator's Chatlog application to log the #ghc freenode channel. While Chatlog did its job admirably, it seems that Phacility has deprecated it with no proposed replacement. Thankfully, there appears to be no shortage of alternatives. In particular, Chris Done's ircbrowse.net seems to offer a great deal of functionality and already mirrors a number of other Haskell-related channels. Would anyone be opposed to adding #ghc to the list of channels monitored by ircbrowse.net? Cheers, - Ben

3 3

Constraint solver again
by Simon Peyton Jones 24 Nov '16

24 Nov '16

Richard, I’ve taken another run at the constraint solver. It’s on wip/spj-tc-branch3 (you’ll need a forced update). I think I can safely commit it to HEAD in the light of your earlier comments, so I’ll do that soon, but I thought I’d just give you (and other ghc-devs) a heads-up. The two main commits are below. The former is small; the latter is the main event. Simon commit 570c3181342386b5cee1862f85a8ebed7d98d712 Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Wed Nov 23 16:00:00 2016 +0000 Allow TyVars in TcTypes Up to now we've had a rule that a TyVar can't apppear in a type seen by the type checker; they should all be TcTyVars. But: a) With -XTypeInType it becomes much harder to exclude them; see Note [TcTyVars in the typechecker] in TcType. b) It's unnecessary to exculde them; instead we can just treat a TyVar just like vanillaSkolemTv. This is what was causing an ASSERT error in indexed-types/should_fail/T12041, reported in Trac #12826. That patch allows a TyVar in a TcType. The most significant change is to make Var.tcTyVarDetails return vanillaSkolemTv. In fact it already did, but (a) it was not documented, and (b) we never exploited it. Now we rely on it. commit 6e6d93b8b713339dc5f74e8f93e35d0d94014d63 Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Tue Oct 25 17:41:45 2016 +0100 Another major constraint-solver refactoring This patch takes further my refactoring of the constraint solver, which I've been doing over the last couple of months in consultation with Richard. It fixes a number of tricky bugs that made the constraint solver actually go into a loop, including Trac #12526 Trac #12444 Trac #12538 The main changes are these * Flatten unification variables (fmvs/fuvs) appear on the LHS of a tvar/tyvar equality; thus fmv ~ alpha and not alpha ~ fmv See Note [Put flatten unification variables on the left] in TcUnify. This is implemented by TcUnify.swapOverTyVars. * Don't reduce a "loopy" CFunEqCan where the fsk appears on the LHS: F t1 .. tn ~ fsk where 'fsk' is free in t1..tn. See Note [FunEq occurs-check principle] in TcInteract This neatly stops some infinite loops that people reported; and it allows us to delete some crufty code in reduce_top_fun_eq. And it appears to be no loss whatsoever. As well as fixing loops, ContextStack2 and T5837 both terminate when they didn't before. * Previously we generated "derived shadow" constraints from Wanteds, but we could (and sometimes did; Trac #xxxx) repeatedly generate a derived shadow from the same Wanted. A big change in this patch is to have two kinds of Wanteds: [WD] behaves like a pair of a Wanted and a Derived [W] behaves like a Wanted only See CtFlavour and ShadowInfo in TcRnTypes, and the ctev_nosh field of a Wanted. This turned out to be a lot simpler. A [WD] gets split into a [W] and a [D] in TcSMonad.maybeEmitShaodow. See TcSMonad Note [The improvement story and derived shadows] * Rather than have a separate inert_model in the InertCans, I've put the derived equalities back into inert_eqs. We weren't gaining anything from a separate field. * Previously we had a mode for the constraint solver in which it would more aggressively solve Derived constraints; it was used for simplifying the context of a 'deriving' clause, or a 'default' delcaration, for example. But the complexity wasn't worth it; now I just make proper Wanted constraints. See TcMType.cloneWC * Don't generate injectivity improvement for Givens; see Note [No FunEq improvement for Givens] in TcInteract * solveSimpleWanteds leaves the insolubles in-place rather than returning them. Simpler. I also did lots of work on comments.

1 0

DWARF patches for 8.2
by Ben Gamari 24 Nov '16

24 Nov '16

Hello fellow DWARF enthusiasts, Tonight I finally made something of a breakthrough on the DWARF front; after finding a small logic error in one of my patches I was able to get a full stack trace into and out of Haskell using the runtime system's native stack unwinder. This is quite exciting! Recall that up until now there have been a few issues which can lead to problems with unwinding, * #11353: Unsafe foreign calls can require the NCG to make stack pointer adjustments to accomodate native calling conventions. These adjustments need to be taken into account when we generate unwinding information. * #11337: Stack fixups produced by CmmStackLayout aren't reflected in unwinding information. Essentially this was a result of the fact that our current unwinding implementation assumes that stack layout is fixed over the course of a block. * #11338: The region surrounding safe foreign calls doesn't get proper unwinding information. I've solved all three of these in my branch, which I've rebased, split up, and posted to Phabricator. The result is quite a stack of differentials, * D2740: OrdList: Add Foldable, Traversable instances Some throat-clearing. * D2735: Use newBlockId instead of newLabelC Just some refactoring. * D2737: NCGMonad: Add MonadUnique NatM instance This will come in handy later. * D2736: AsmCodeGen: Refactor worker in cmmNativeGens More refactoring I did while trying to understand the dataflow in the NCG. * D2739: CmmCommonBlockElim: Ignore CmmUnwind nodes This is a fix to what I believe is a bug which I noticed while reading through the implementation. * D2741: Generalize CmmUnwind and pass unwind information through NCG This is the bulk of the change. Here we refactor the treatment of unwinding information to provide the flexibility we will need to address the issues described above and fix #11353. Review is badly needed here. * D2742: CmmLayoutStack: Add unwind information on stack fixups Here we use the infrastructure provided in D2741 to fix #11337. * D2743: StgCmmForeign: Emit debug information for safe foreign calls Here we fix #11338 by adding unwind information to the safe foreign call prologue/epilogue code. * D2738: Cmm: Add support for undefined unwinding statements Fix unwinding information for stg_stack_underflow_frames, which we have no means of unwinding out of. For this we need to add support for unwinding declarations which tell the underwinder to "forget" about the value of a register. Reviews would be greatly appreciated. Cheers, - Ben

2 1

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

22 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 18 Nov '16

18 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