- ghc-devs - Haskell.org

Help with cast error
by Conal Elliott 24 Apr '14

24 Apr '14

I'd appreciate help with a cast-related Core Lint error I'm getting with a GHC plugin I'm working on: Argument value doesn't match argument type: Fun type: Enc (Vec ('S 'Z) Bool) ~ (Bool, ()) => EP (Enc (Vec ('S 'Z) Bool)) -> EP (Bool, ()) Arg type: ~R# (Enc (Vec ('S 'Z) Bool)) (Bool, ()) Arg: CO Sub (TFCo:R:EncVec[0] <'Z>_N <Bool>_N) ; (Sub TFCo:R:EncBool[0], Sub (TFCo:R:EncVec0[0] <Bool>_N))_R (I omitted the module prefixes for brevity.) Do I have a role wrong here, or maybe something more fundamental? I can easily supply more info if it'd help. Thanks, -- Conal

2 2

RE: Cloning ghc-7.8
by Simon Peyton Jones 24 Apr '14

24 Apr '14

OK. So are you saying that you can't reliably change to a different branch in an existing tree, but rather must freshly clone from the source each time you want to check out a different branch? That seems a bit extreme. I thought switching branches is precisely what git is good at. Still I'll blow away my tree and try what you say. Simon | -----Original Message----- | From: Herbert Valerio Riedel [mailto:hvriedel@gmail.com] | Sent: 24 April 2014 11:30 | To: Simon Peyton Jones | Cc: Austin Seipp | Subject: Re: Cloning ghc-7.8 | | On 2014-04-24 at 12:14:16 +0200, Simon Peyton Jones wrote: | > I tried the sequence below and got this: | | maybe try this sequence that was suggested by Austin on #ghc a couple | of | days ago: | | <thoughtpolice> (sync-all has a little difficulty with the submodules | here, and you'll end up needing to always clean anyway due to interface | changes, etc) | <thoughtpolice> 'git clone -b ghc-7.8 git://git.haskell.org && cd ghc | && ./sync-all get -b ghc-7.8' should do it |

3 2

Cloning ghc-7.8
by Simon Peyton Jones 24 Apr '14

24 Apr '14

How would I get a GHC 7.8 branch repo? Something like git clone http://git.haskell.org/ghc.git ghc-7.8-branch cd ghc-7.8-branch ./sync-all get git checkout ghc-7.8 git submodule update Is that enough? What about the non-submodule libraries? Do I need to do any more pull/get stuff? This would be another great entry on the workflow page. Thanks Simon

1 1

Porting GHC
by Simon Peyton Jones 24 Apr '14

24 Apr '14

Colin I saw your porting-ghc blog post<http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/2014-04-15-porting…> (via the Haskell Weekly News) today. What a great post! Porting GHC to new architectures is way beyond the slender resources of GHC HQ, so depends utterly on volunteers. And you see to be a particularly skilled and knowledgeable one. Thank you! Simon PS: where you have offered patches to the main sources (e.g the function-prototype thing), did you elaborately comment the "technically wrong" prototype? I have this fear that in three year's time someone is going to say "oh, we could do better with that prototype" and re-introduce the bug! Aha. I've just checked #8965, and there's no comment at all. I'll add the commit message as a comment. Other ghc-devs, nb! Adding the ticket number to the comment is also fantastically helpful, because it often points to examples and discussion that are too long to include in the code.

1 0

checking clean reporting a lot of non-deleted files.
by Karel Gardas 23 Apr '14

23 Apr '14

Hello Herbert, I hope you are the right person to ask, but it looks like after folding base/template-haskell/ghc-prim/integer-gmp/ etc. libraries to ghc tree the build's checking clean step reports a lot of non-deleted files. This makes our builder logs quite huge: http://haskell.inf.elte.hu/builders/solaris-x86-head/36/14.html the situation just few days ago was quite different: http://haskell.inf.elte.hu/builders/solaris-x86-head/33/14.html Do you think this is caused by your change? If not, do you have an idea what's going wrong here? Thanks! Karel

2 1

Re: [commit: ghc] master: Be less untruthful about the prototypes of external functions (5a31f23)
by Simon Marlow 23 Apr '14

23 Apr '14

Could we have a comment with the ticket number next to the prototype please? Otherwise some well-meaning developer will "fix" it again in the future :-) Cheers, Simon On 22/04/2014 05:40, git(a)git.haskell.org wrote: > Repository : ssh://git@git.haskell.org/ghc > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/5a31f231eebfb8140f9b519b166094d9d… > >> --------------------------------------------------------------- > > commit 5a31f231eebfb8140f9b519b166094d9d4fc2d79 > Author: Colin Watson <cjwatson(a)debian.org> > Date: Sat Apr 12 01:55:07 2014 +0100 > > Be less untruthful about the prototypes of external functions > > GHC's generated C code uses dummy prototypes for foreign imports. At the > moment these all claim to be (void), i.e. functions of zero arguments. On > most platforms this doesn't matter very much: calls to these functions put > the parameters in the usual places anyway, and (with the exception of > varargs) things just work. > > However, the ELFv2 ABI on ppc64 optimises stack allocation > (http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01149.html) a call to a > function that has a prototype, is not varargs, and receives all parameters > in registers rather than on the stack does not require the caller to > allocate an argument save area. The incorrect prototypes cause GCC to > believe that all functions declared this way can be called without an > argument save area, but if the callee has sufficiently many arguments then > it will expect that area to be present, and will thus corrupt the caller's > stack. This happens in particular with calls to runInteractiveProcess in > libraries/process/cbits/runProcess.c. > > The simplest fix appears to be to declare these external functions with an > unspecified argument list rather than a void argument list. This is no > worse for platforms that don't care either way, and allows a successful > bootstrap of GHC 7.8 on little-endian Linux ppc64 (which uses the ELFv2 > ABI). > > Fixes #8965 > > Signed-off-by: Colin Watson <cjwatson(a)debian.org> > Signed-off-by: Austin Seipp <austin(a)well-typed.com> > > >> --------------------------------------------------------------- > > 5a31f231eebfb8140f9b519b166094d9d4fc2d79 > includes/Stg.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/includes/Stg.h b/includes/Stg.h > index be966aa..1707c9b 100644 > --- a/includes/Stg.h > +++ b/includes/Stg.h > @@ -213,7 +213,7 @@ typedef StgFunPtr F_; > #define II_(X) static StgWordArray (X) GNU_ATTRIBUTE(aligned (8)) > #define IF_(f) static StgFunPtr GNUC3_ATTRIBUTE(used) f(void) > #define FN_(f) StgFunPtr f(void) > -#define EF_(f) extern StgFunPtr f(void) > +#define EF_(f) extern StgFunPtr f() > > /* ----------------------------------------------------------------------------- > Tail calls > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

1 0

Coverity CID 43168
by Howard B. Golden 22 Apr '14

22 Apr '14

Hi, This is code I wrote for Trac ticket #2615. I will study it to see if it needs to be fixed. If so, I will submit a patch. I tried to put this into the triage section in Coverity, but I guess I don't have write access to update that. This is a minor memory leak (if at all). The semantics of the POSIX dlopen error isn't fully specified, so I'm unsure of whether I need to fix this or not. Howard B. Golden Northridge, CA, USA

1 0

Coverity Scan
by Austin Seipp 22 Apr '14

22 Apr '14

Hello all, As of this morning, GHC has been accepted into the Coverity Scan project! The results are in and a few of us are combing over them now. Some of you I'm sure would like to play around and see what it says. Please feel free to ask me for access. In general, Coverity is restrictive of access because of the security implications, but I think this is much less of a problem for us in general. That said, I won't give literally everyone in the world access, but there's no harm in having some eyes. The project is available here, and you can request access by giving your email address: https://scan.coverity.com/projects/1919 Currently me and Herbert are the owners, and so we can submit builds. I plan on inviting at least Simon M and Edward Yang as well. You two can also just apply via the UI and I will add you as well. Note that I think a few of these issues are quite real, but I do think we'll have to mitigate some by writing a Coverity model and tuning things to reduce the false impact rate. Luckily this shouldn't be too hard. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

2 3

Re: [commit: ghc] wip/orf: ghc: implement OverloadedRecordFields (fe77cbf)
by Chris Dornan 22 Apr '14

22 Apr '14

Marvellous On 22/04/2014 12:17, "git(a)git.haskell.org" <git(a)git.haskell.org> wrote: >Repository : ssh://git@git.haskell.org/ghc > >On branch : wip/orf >Link : >http://ghc.haskell.org/trac/ghc/changeset/fe77cbf15dd44bb72943357d65bd8adf >9f4deee5/ghc > >>--------------------------------------------------------------- > >commit fe77cbf15dd44bb72943357d65bd8adf9f4deee5 >Author: Adam Gundry <adam(a)well-typed.com> >Date: Tue Apr 22 02:12:03 2014 -0500 > > ghc: implement OverloadedRecordFields > > This fully implements the new ORF extension, developed during the >Google > Summer of Code 2013, and as described on the wiki: > > https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields > > This also updates the Haddock submodule. > > Reviewed-by: Simon Peyton Jones <simonpj(a)microsoft.com> > Signed-off-by: Austin Seipp <austin(a)well-typed.com> > > >>--------------------------------------------------------------- > >fe77cbf15dd44bb72943357d65bd8adf9f4deee5 > compiler/basicTypes/Avail.hs | 149 ++++++- > compiler/basicTypes/DataCon.lhs | 21 +- > compiler/basicTypes/DataCon.lhs-boot | 2 + > compiler/basicTypes/FieldLabel.lhs | 128 ++++++ > compiler/basicTypes/Id.lhs | 12 +- > compiler/basicTypes/MkId.lhs | 2 +- > compiler/basicTypes/OccName.lhs | 8 + > compiler/basicTypes/RdrName.lhs | 123 +++-- > compiler/deSugar/Check.lhs | 4 +- > compiler/deSugar/Coverage.lhs | 4 +- > compiler/deSugar/Desugar.lhs | 2 + > compiler/deSugar/DsExpr.lhs | 18 +- > compiler/deSugar/DsMeta.hs | 4 +- > compiler/deSugar/DsMonad.lhs | 1 + > compiler/deSugar/MatchCon.lhs | 6 +- > compiler/ghc.cabal.in | 3 + > compiler/ghc.mk | 7 + > compiler/hsSyn/Convert.lhs | 23 +- > compiler/hsSyn/HsDecls.lhs | 6 + > compiler/hsSyn/HsExpr.lhs | 5 +- > compiler/hsSyn/HsImpExp.lhs | 33 +- > compiler/hsSyn/HsPat.lhs | 39 +- > compiler/hsSyn/HsTypes.lhs | 51 ++- > compiler/hsSyn/HsUtils.lhs | 80 ++-- > compiler/iface/BuildTyCl.lhs | 2 +- > compiler/iface/IfaceSyn.lhs | 52 +-- > compiler/iface/LoadIface.lhs | 19 +- > compiler/iface/MkIface.lhs | 27 +- > compiler/iface/TcIface.lhs | 36 +- > compiler/main/DynFlags.hs | 9 + > compiler/main/GHC.hs | 19 +- > compiler/main/HscMain.hs | 16 +- > compiler/main/HscTypes.lhs | 27 +- > compiler/main/InteractiveEval.hs | 2 +- > compiler/main/PprTyThing.hs | 12 +- > compiler/main/TidyPgm.lhs | 12 +- > compiler/parser/Parser.y.pp | 6 +- > compiler/parser/RdrHsSyn.lhs | 6 +- > compiler/prelude/PrelInfo.lhs | 2 +- > compiler/prelude/PrelNames.lhs | 43 +- > compiler/prelude/TysWiredIn.lhs | 2 +- > compiler/rename/RnEnv.lhs | 321 ++++++++++--- > compiler/rename/RnExpr.lhs | 20 +- > compiler/rename/RnNames.lhs | 470 >+++++++++++++++----- > compiler/rename/RnPat.lhs | 75 ++-- > compiler/rename/RnSource.lhs | 90 ++-- > compiler/rename/RnTypes.lhs | 53 ++- > compiler/typecheck/FamInst.lhs | 53 ++- > compiler/typecheck/Inst.lhs | 3 +- > compiler/typecheck/TcEnv.lhs | 57 +-- > compiler/typecheck/TcErrors.lhs | 54 ++- > compiler/typecheck/TcEvidence.lhs | 1 + > compiler/typecheck/TcExpr.lhs | 320 ++++++++++--- > compiler/typecheck/TcFldInsts.lhs | 468 >+++++++++++++++++++ > compiler/typecheck/TcGenDeriv.lhs | 11 +- > compiler/typecheck/TcGenGenerics.lhs | 16 +- > compiler/typecheck/TcHsSyn.lhs | 4 +- > compiler/typecheck/TcHsType.lhs | 16 +- > compiler/typecheck/TcInstDcls.lhs | 4 +- > compiler/typecheck/TcInteract.lhs | 65 ++- > compiler/typecheck/TcPat.lhs | 24 +- > compiler/typecheck/TcRnDriver.lhs | 25 +- > compiler/typecheck/TcRnMonad.lhs | 5 +- > compiler/typecheck/TcRnTypes.lhs | 31 +- > compiler/typecheck/TcSMonad.lhs | 18 +- > compiler/typecheck/TcSplice.lhs | 2 +- > compiler/typecheck/TcTyClsDecls.lhs | 79 ++-- > compiler/typecheck/TcType.lhs | 9 + > compiler/typecheck/TcValidity.lhs | 19 +- > compiler/types/TyCon.lhs | 54 ++- > compiler/types/Type.lhs | 29 +- > compiler/types/Type.lhs-boot | 2 + > compiler/types/TypeRep.lhs | 43 +- > compiler/utils/Binary.hs | 1 - > compiler/utils/FastStringEnv.lhs | 77 ++++ > docs/users_guide/glasgow_exts.xml | 307 +++++++++++++ > libraries/base/GHC/Base.lhs | 3 + > libraries/base/GHC/Records.hs | 249 +++++++++++ > libraries/base/GHC/TypeLits.hs | 8 +- > libraries/base/base.cabal | 1 + > testsuite/tests/driver/T4437.hs | 1 + > testsuite/tests/ghci/scripts/ghci042.stdout | 2 +- > testsuite/tests/module/mod176.stderr | 2 +- > .../{annotations => overloadedrecflds}/Makefile | 0 > .../ghci}/Makefile | 0 > testsuite/tests/overloadedrecflds/ghci/all.T | 3 + > .../ghci/overloadedrecfldsghci01.script | 13 + > .../ghci/overloadedrecfldsghci01.stdout | 11 + > .../should_fail}/Makefile | 0 > .../should_fail/OverloadedRecFldsFail04_A.hs | 9 + > .../should_fail/OverloadedRecFldsFail06_A.hs | 16 + > .../should_fail/OverloadedRecFldsFail08_A.hs | 14 + > .../tests/overloadedrecflds/should_fail/all.T | 16 + > .../should_fail/overloadedrecfldsfail01.hs | 17 + > .../should_fail/overloadedrecfldsfail01.stderr | 16 + > .../should_fail/overloadedrecfldsfail02.hs | 19 + > .../should_fail/overloadedrecfldsfail02.stderr | 50 +++ > .../should_fail/overloadedrecfldsfail03.hs | 7 + > .../should_fail/overloadedrecfldsfail03.stderr | 5 + > .../should_fail/overloadedrecfldsfail04.hs | 9 + > .../should_fail/overloadedrecfldsfail04.stderr | 5 + > .../should_fail/overloadedrecfldsfail05.hs | 10 + > .../should_fail/overloadedrecfldsfail05.stderr | 10 + > .../should_fail/overloadedrecfldsfail06.hs | 10 + > .../should_fail/overloadedrecfldsfail06.stderr | 15 + > .../should_fail/overloadedrecfldsfail07.hs | 11 + > .../should_fail/overloadedrecfldsfail07.stderr | 6 + > .../should_fail/overloadedrecfldsfail08.hs | 13 + > .../should_fail/overloadedrecfldsfail08.stderr | 47 ++ > .../should_fail/overloadedrecfldsfail09.hs | 9 + > .../should_fail/overloadedrecfldsfail09.stderr | 20 + > .../should_fail/overloadedrecfldsfail10.hs | 11 + > .../should_fail/overloadedrecfldsfail10.stderr | 9 + > .../should_run}/Makefile | 0 > .../should_run/OverloadedRecFldsRun01_A.hs | 9 + > .../should_run/OverloadedRecFldsRun02_A.hs | 9 + > .../should_run/OverloadedRecFldsRun07_A.hs | 11 + > .../should_run/OverloadedRecFldsRun07_B.hs | 7 + > .../should_run/OverloadedRecFldsRun08_A.hs | 11 + > .../should_run/OverloadedRecFldsRun08_B.hs | 7 + > .../should_run/OverloadedRecFldsRun08_C.hs | 7 + > .../should_run/OverloadedRecFldsRun11_A.hs | 9 + > .../should_run/OverloadedRecFldsRun11_A.hs-boot | 5 + > .../should_run/OverloadedRecFldsRun11_B.hs | 7 + > .../should_run/OverloadedRecFldsRun12_A.hs | 11 + > .../should_run/OverloadedRecFldsRun12_B.hs | 7 + > testsuite/tests/overloadedrecflds/should_run/all.T | 26 ++ > .../should_run/overloadedrecfldsrun01.hs | 70 +++ > .../should_run/overloadedrecfldsrun01.stdout | 13 + > .../should_run/overloadedrecfldsrun02.hs | 6 + > .../should_run/overloadedrecfldsrun02.stdout | 0 > .../should_run/overloadedrecfldsrun03.hs | 18 + > .../should_run/overloadedrecfldsrun03.stdout | 4 + > .../should_run/overloadedrecfldsrun04.hs | 18 + > .../should_run/overloadedrecfldsrun04.stdout | 3 + > .../should_run/overloadedrecfldsrun05.hs | 34 ++ > .../should_run/overloadedrecfldsrun05.stdout | 2 + > .../should_run/overloadedrecfldsrun06.hs | 28 ++ > .../should_run/overloadedrecfldsrun06.stdout | 1 + > .../should_run/overloadedrecfldsrun07.hs | 7 + > .../should_run/overloadedrecfldsrun07.stdout} | 0 > .../should_run/overloadedrecfldsrun08.hs | 7 + > .../should_run/overloadedrecfldsrun08.stdout | 2 + > .../should_run/overloadedrecfldsrun09.hs | 8 + > .../should_run/overloadedrecfldsrun09.stdout | 2 + > .../should_run/overloadedrecfldsrun10.hs | 12 + > .../should_run/overloadedrecfldsrun10.stderr | 2 + > .../should_run/overloadedrecfldsrun11.hs | 5 + > .../should_run/overloadedrecfldsrun11.stdout} | 0 > .../should_run/overloadedrecfldsrun12.hs | 6 + > .../should_run/overloadedrecfldsrun12.stdout | 2 + > .../should_run/overloadedrecfldsrun13.hs | 9 + > .../should_run/overloadedrecfldsrun13.stdout} | 0 > testsuite/tests/rename/should_fail/T5892a.stderr | 2 +- > .../tests/typecheck/should_fail/tcfail102.stderr | 3 +- > utils/ghctags/Main.hs | 2 +- > utils/haddock | 2 +- > 157 files changed, 4131 insertions(+), 759 deletions(-) > >Diff suppressed because of size. To see it, use: > > git diff-tree --root --patch-with-stat --no-color >--find-copies-harder --ignore-space-at-eol --cc >fe77cbf15dd44bb72943357d65bd8adf9f4deee5 >_______________________________________________ >ghc-commits mailing list >ghc-commits(a)haskell.org >http://www.haskell.org/mailman/listinfo/ghc-commits

1 0

OverloadedRecordFields merge
by Austin Seipp 22 Apr '14

22 Apr '14

Hello all, As some of you might have seen last week, my colleague Adam took the time to get his OverloadedRecordFields back up to date with regards to HEAD. I'm now wondering: when should we pull the trigger? I am inclined to say 'soon'. In particular, the ORF changes are rather large, and Adam has hinted to me it touches a lot of components of e.g. name resolution. A large change with some fairly big impacts, in other words. I think it is perhaps best to merge soon - so that it does not get out of date and cause undue burden to Adam, but also so that we have maximal amounts of time to sort out issues in the long haul that it might expose. Simon - I believe you reviewed Adam's work in the past, yes? I am wondering what you think we should do here. I am more than willing to defer to you and let you do the merge after another review. On the other hand, if you already did review it and feel confident after a look or two, I'm more than willing to take over sometime this week. Adam - since you emailed us last week, Herbert went ahead and merged 'base' into GHC's repository. This does not invalidate the changes you gave us, it just means the two commits can be collapsed into one. Also, the performance failures seem like minor anomalies, but I have not yet directly built the ORF branch to confirm this. You're free to rebase yourself, or I can likely handle it without much issue soon. If anyone else has opinions here - please speak up, I'm all ears. For those reading, Adam's implementation is available in current form here: - https://github.com/adamgundry/ghc - https://github.com/adamgundry/packages-base - https://github.com/adamgundry/haddock -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

2 3