December 2015 - ghc-devs

FW: [Diffusion] [Build Failed] rGHC52b02e66025f: Comments only (isIrrefutablePat)
by Simon Peyton Jones 03 Dec '15

03 Dec '15

Haddock is a constant mystery. I added five lines of comments to GHC's source code, and one of the Haddock performance tests fails (see below). That's all the patch contains. I am reluctant to fix it by deleting the comments! Simon -----Original Message----- From: noreply(a)phabricator.haskell.org [mailto:noreply@phabricator.haskell.org] Sent: 02 December 2015 16:05 To: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: [Diffusion] [Build Failed] rGHC52b02e66025f: Comments only (isIrrefutablePat) Harbormaster failed to build B7060: rGHC52b02e66025f: Comments only (isIrrefutablePat)! BRANCHES master USERS simonpj (Author) GHC - HsSyn/Parser (Auditor) GHC - Renamer (Auditor) COMMIT https://phabricator.haskell.org/rGHC52b02e66025f EMAIL PREFERENCES https://phabricator.haskell.org/settings/panel/emailpreferences/ To: simonpj, GHC - HsSyn/Parser, GHC - Renamer

3 2

ok to do reformatting commits?
by Evan Laforge 03 Dec '15

03 Dec '15

When I was doing a recent patch, I was annoyed by lint errors about >80 lines when I was just conforming to the existing style. To avoid cluttering my commit with unrelated changes, I decided to fix the lints in a formatting-only commit afterwards. Looking in the archives, I see there was some recent discussion about this, but I didn't see anyone volunteering to just go wrap a bunch of files, or saying that they didn't want anyone to do this (usual reason being cluttering the history, which as a rationale to not do formatting only changes never sat too well with me). Would anyone mind if I went and wrapped a bunch of files, say typecheck/*.hs? This seems simpler than either constant hassling from arc or coming up with more elaborate rules for arc. I would have to make some formatting decisions, so likely to some eyes I would be messing some stuff up, but since there's no real standard that is probably unavoidable.

5 6

HEADS UP: Moving Phabricator to a new server soon
by Austin Seipp 02 Dec '15

02 Dec '15

Hello all, As I said about a week or two ago[1], I still have plans to move the Phabricator server. I'd like to do this tonight. I plan on starting this around 10pm CST or so. This is late at night in the US and quite early in the EU, so I'm hoping to avoid causing problems for anyone. I'll follow up with more emails in response to this one later tonight, as things move forward. Thanks! [1] https://mail.haskell.org/pipermail/ghc-devs/2015-November/010519.html -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

linker error in haddock, D1558
by Alan & Kim Zimmerman 01 Dec '15

01 Dec '15

Does anyone know why a build would be failing with utils/haddock/dist/build/Haddock/GhcUtils.dyn_o: In function `skOK_info': (.text+0x75c8): undefined reference to `stg_ap_0_upd_info' utils/haddock/dist/build/Haddock/GhcUtils.dyn_o: In function `skP5_info': (.text+0x7728): undefined reference to `stg_ap_0_upd_info' collect2: error: ld returned 1 exit status `gcc' failed in phase `Linker'. (Exit code: 1) utils/haddock/ghc.mk:21: recipe for target 'utils/haddock/dist/build/tmp/haddock' failed make[1]: *** [utils/haddock/dist/build/tmp/haddock] Error 1 This is happening on https://phabricator.haskell.org/harbormaster/build/8393/, a build of https://phabricator.haskell.org/D1558 Alan

1 0

Wildcard refactoring
by Simon Peyton Jones 01 Dec '15

01 Dec '15

OK, I think it’s time to commit my branch wip/spj-wildcard-refactor Ben: could you commit it as a single large patch (ignore the branch history). A commit message appears below. There is a corresponding patch for haddock, with same branch name in the haddock repo. Could you also open a ticket for the performance regression on perf/compiler/T3064? I don’t want to forget it, but it’s past time to commit such a big, invasive patch. There are two other tests failing for me, which appear to do with the version number for the containers sub-module. I think I have failed to get the other submodules (other than haddock) right. I was NOT intending to change them, so just use origin/master for them. Everyone: take a look at the commit message below. I’ve been working on this for far too long, in spare moments. Richard, I’m sorry that it’ll be disruptive to your changes, but in a good way I hope. Simon This patch began as a modest refactoring of HsType and friends, to clarify and tidy up exactly where quantification takes place in types. Although initially driven by making the implementation of wildcards more tidy (and fixing a number of bugs), I gradually got drawn into a pretty big process, which I've been doing on and off for quite a long time. There is one compiler performance regression as a result of all this, in perf/compiler/T3064. I still need to look into that. * The principal driving change is described in Note [HsType binders] in HsType. Well worth reading! * Those data type changes drive almost everything else. In particular we now statically know where (a) implicit quantification only (LHsSigType), e.g. in instance declaratios and SPECIALISE signatures (b) implicit quantification and wildcards (LHsSigWcType) can appear, e.g. in function type signatures * As part of this change, HsForAllTy is (a) simplified (no wildcards) and (b) split into HsForAllTy and HsQualTy. The two contructors appear when and only when the correponding user-level construct appears. Again see Note [HsType binders]. HsExplicitFlag disappears altogether. * Other simplifications - ExprWithTySig no longer needs an ExprWithTySigOut variant - TypeSig no longer needs a PostRn name [name] field for wildcards - PatSynSig records a LHsSigType rather than the decomposed pieces - The mysterious 'GenericSig' is now 'ClassOpSig' * Renamed LHsTyVarBndrs to LHsQTyVars * There are some uninteresting knock-on changes in Haddock, because of the HsSyn changes I also did a bunch of loosely-related changes: * We already had type synonyms CoercionN/CoercionR for nominal and representational coercions. I've added similar treatment for TcCoercionN/TcCoercionR mkWpCastN/mkWpCastN All just type synonyms but jolly useful. * I record-ised ForeignImport and ForeignExport * I improved the (poor) fix to Trac #10896, by making TcTyClsDecls.checkValidTyCl recover from errors, but adding a harmless, abstract TyCon to the envt if so. * I did some significant refactoring in RnEnv.lookupSubBndrOcc, for reasons that I have (embarrassingly) now totally forgotten. It had to do with something to do with import and export

2 1

Wildcards in type functions vs. named wild cards
by Jan Stolarek 01 Dec '15

01 Dec '15

Simon, One of my students (Michał, CCd) is hacking on #10982 and he noticed a rather unexpected behaviour. If I say: {-# LANGUAGE TypeFamilies #-} module T10982 where type family F a where F _t = Int Then everything is fine. But if I enable NamedWildCards extension then suddenly this code is rejected: T10982.hs:7:7: error: Unexpected wild card: ‘_t’ In the declaration for type synonym ‘F’ I am 99% sure this is a bug and the program should be accepted even with NamedWildCards. Am I correct? Does this interact in any way with your upcomming refactoring of wildcards? Janek --- Politechnika Łódzka Lodz University of Technology Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system.

2 2