September 2013 - ghc-devs

"has no symbols"/"same member name" warnings using libtool
by Luke Iannini 16 Sep '13

16 Sep '13

Hi all, I'm trying to track down the last warnings in GHC iOS. We get this waterfall of warnings like: warning same member name (Types.o) in output file used for input files: /usr/local/ghc-ios-sim/lib/i386-apple-darwin11-ghc-7.7.20130828/base-4.7.0.0/libHSbase-4.7.0.0.a(Types.o) and: /usr/local/ghc-ios-sim/lib/i386-apple-darwin11-ghc-7.7.20130828/base-4.7.0.0/libHSbase-4.7.0.0.a(Types.o) due to use of basename, truncation and blank padding and file: /usr/local/ghc-ios-sim/lib/i386-apple-darwin11-ghc-7.7.20130828/base-4.7.0.0/libHSbase-4.7.0.0.a(consUtils.o) has no symbols when we run libtool to create the static libraries, and I was wondering if anyone had any ideas what causes them so I could start debugging... I can't seem to find much information about the warning. Here's the output of i386-apple-darwin11-ghc -staticlib test.'s where test.hs is simply: main = print "hello world" https://gist.github.com/lukexi/25bfb42616933b0f1542 and here's the same with -v3 https://gist.github.com/lukexi/c1fbbe32cef9e3965a72 I suppose I can simply suppress the output of libtool when we call it from GHC, but I'd love to find the root cause if we can. Thanks for any hints! Cheers Luke

3 3

Coercible class (Was: newtype wrappers)
by Joachim Breitner 16 Sep '13

16 Sep '13

Hi, Am Montag, den 09.09.2013, 11:26 -0500 schrieb Austin Seipp: > It sounds like Simon thinks your work is good to go, so when your tree > is clean, feel free to push. done! Given that in the final form the feature, to the user, looks like a library and not a language extension, I decided to put the documentation not in the users guide, but only in the haddock for coerce and Coercible. So far they only live in GHC.Prim. Should we expose them in GHC.Prim for 7.8, or only in 7.10? Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nomeata(a)debian.org

4 12

RFC: are duplications / float outs acceptable for prefetches or not?
by Carter Schonwald 16 Sep '13

16 Sep '13

Hey all, I"ve been doing some work to finish up my prefetch patch that I hope to land in 7.8, and one design matter thats come up is what the optimization semantics should be! is it appropriate to duplicate prefetches? (probably yes) is it appropriate to float OUT prefetched? (probably not?) operations that are dupable which shouldn't float out are marked with the can_fail= true property, operations which cannot be safely floated out and can't be duped are marked as having side effects. on the GHC irc channel, Duncan was patient enough to walk my through understanding this, and this makes me lean towards the conclusion that duplication is ok, but floating out isnt. Thus all the prefetch ops (pure or not) should have the attribute "can fail", rather than no attribut or "has effects". this is exploiting that "can fail" really just means "don't float out". thoughts and counter points? thanks -Carter

1 2

Bit-rotting(?) HUGS-specific code in GHC boot libraries
by Herbert Valerio Riedel 15 Sep '13

15 Sep '13

Hello GHC devs, ...as the topic came up in #ghc, what's the current rationale for keeping HUGS-specific code sprinkled throughout GHC boot libraries? I quick tally in GHC's source tree via find -type f -iname '*.*hs' | xargs grep '#if.*HUGS' | cut -f1-3 -d/ | uniq -c results in 1 ./libraries/directory 5 ./libraries/haskell98 84 ./libraries/base 5 ./libraries/haskell2010 29 ./libraries/array 12 ./libraries/process 1 ./libraries/bytestring Does anyone actually still use/test those packages in HUGS? Is there any real benefit to keep the HUGS-specific code as dead (compile-time) code in those packages? (When) can that code be removed? Cheers, hvr

6 7

Validate fails for current master
by Simon Hengel 14 Sep '13

14 Sep '13

Hi, I'd love to push some Haddock changes, but for me validate on current master fails with: 1 caused framework failures 1 unexpected passes 86 unexpected failures Errors are of the form: - Multi-way if-expressions need MultiWayIf turned on + Multi-way if-expressions need -XMultiWayIf turned on Is one of you guys looking into this? Cheers, Simon

2 3

Data kind syntax
by Simon Peyton-Jones 13 Sep '13

13 Sep '13

Trevor Thanks for working on the data-kind stuff. I've had a terribly crammed week, so I have only just looked at it properly. The first thing I look for is a wiki page articulating the design you have chosen. I think it's this: http://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindsWithoutData Is that it? By which I mean, are there really *zero* wrinkles, dark corners? Second, I'm not so happy about introducing a whole new constructor, KindDecl, in TyClDecl; plus associated clobber like a new data type TyConDecl. That brings lots of new code to treat those new declarations. All that new code makes sense for things that differ radically -- for example a class declaration is very different to a data type declaration. BUT this 'data kind' stuff is really very very similar to an ordinary data type declaration! You just treat a very restricted form. Moreover, it won't be long before Stephanie and Richard are seeking GADTs at the kind level, and then you'll have to expand it, duplicating yet more code. One way to recover the commonality would be to really treat it as a data type declaration, but to restrict what is actually brought into scope (just as 'data type' will do). But then what about the use of '*' in data kind? data kind T = A * | B T T Well, that's really just a parsing issue! The parser can parse it as a kind, so that it understands the star correctly. But having parsed it, we can treat it largely like an ordinary data type declaration, can't we? What do you think? Want to Skype? Sadly I'm out Mon/Tues. Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of | git(a)git.haskell.org | Sent: 09 September 2013 04:54 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] data-kind-syntax: Fix how we're using roles with | `data kind` declarations (13d4096) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : data-kind-syntax | Link : | http://ghc.haskell.org/trac/ghc/changeset/13d4096e0668e9f80a8601122affc6 | 4f8be295de/ghc | | >--------------------------------------------------------------- | | commit 13d4096e0668e9f80a8601122affc64f8be295de | Author: Trevor Elliott <trevor(a)galois.com> | Date: Sun Sep 8 17:46:48 2013 -0700 | | Fix how we're using roles with `data kind` declarations | | | >--------------------------------------------------------------- | | 13d4096e0668e9f80a8601122affc64f8be295de | compiler/iface/IfaceSyn.lhs | 11 +++++++---- | compiler/iface/MkIface.lhs | 3 ++- | compiler/iface/TcIface.lhs | 5 +++-- | compiler/typecheck/TcTyClsDecls.lhs | 15 ++++++++------- | compiler/types/TyCon.lhs | 8 ++++---- | 5 files changed, 24 insertions(+), 18 deletions(-) | | diff --git a/compiler/iface/IfaceSyn.lhs b/compiler/iface/IfaceSyn.lhs | index b12906b..ca772ac 100644 | --- a/compiler/iface/IfaceSyn.lhs | +++ b/compiler/iface/IfaceSyn.lhs | @@ -436,19 +436,22 @@ instance Binary IfaceBang where | | data IfaceTyConDecl | = IfTyCon { | - ifTyConOcc :: OccName, -- constructor name | - ifTyConArgKs :: [IfaceKind] -- constructor argument kinds | + ifTyConOcc :: OccName, -- constructor name | + ifTyConArgKs :: [IfaceKind], -- constructor argument kinds | + ifTyConRoles :: [Role] -- constructor argument roles | } | | instance Binary IfaceTyConDecl where | - put_ bh (IfTyCon a1 a2) = do | + put_ bh (IfTyCon a1 a2 a3) = do | put_ bh (occNameFS a1) | put_ bh a2 | + put_ bh a3 | get bh = do | a1 <- get bh | a2 <- get bh | + a3 <- get bh | occ <- return $! mkOccNameFS tcName a1 | - return (IfTyCon occ a2) | + return (IfTyCon occ a2 a3) | | data IfaceClsInst | = IfaceClsInst { ifInstCls :: IfExtName, -- See | comments with | diff --git a/compiler/iface/MkIface.lhs b/compiler/iface/MkIface.lhs | index 6764c91..3fff2b8 100644 | --- a/compiler/iface/MkIface.lhs | +++ b/compiler/iface/MkIface.lhs | @@ -1566,7 +1566,8 @@ tyConToIfaceDecl env tycon | | ifaceTyConDecl ty_con | = IfTyCon { ifTyConOcc = getOccName (tyConName ty_con), | - ifTyConArgKs = map (tidyToIfaceType emptyTidyEnv) | args } | + ifTyConArgKs = map (tidyToIfaceType emptyTidyEnv) | args, | + ifTyConRoles = tyConRoles ty_con } | where | (args,_) = splitFunTys (tyConKind ty_con) | | diff --git a/compiler/iface/TcIface.lhs b/compiler/iface/TcIface.lhs | index d6b6a55..2d18a74 100644 | --- a/compiler/iface/TcIface.lhs | +++ b/compiler/iface/TcIface.lhs | @@ -668,11 +668,12 @@ tcIfaceDataCons tycon_name tycon _ if_cons | ; return (HsUnpack (Just co)) } | | tcIfaceTyConDecl :: Kind -> KCon -> IfaceTyConDecl -> IfL TyCon | -tcIfaceTyConDecl kind kcon IfTyCon { ifTyConOcc = occ_name, | ifTyConArgKs = args } | +tcIfaceTyConDecl kind kcon IfTyCon { ifTyConOcc = occ_name, | ifTyConArgKs = args, | + ifTyConRoles = roles } | = do name <- lookupIfaceTop occ_name | -- See the comment in tc_con_decl of tcIfaceDataCons for why | forkM | kinds <- forkM pp_name (mapM tcIfaceKind args) | - return (mkDataKindTyCon kcon name (mkFunTys kinds kind)) | + return (mkDataKindTyCon kcon name (mkFunTys kinds kind) roles) | where | pp_name = ptext (sLit "Type constructor") <+> ppr occ_name | | diff --git a/compiler/typecheck/TcTyClsDecls.lhs | b/compiler/typecheck/TcTyClsDecls.lhs | index 99a3584..d348e8b 100644 | --- a/compiler/typecheck/TcTyClsDecls.lhs | +++ b/compiler/typecheck/TcTyClsDecls.lhs | @@ -118,7 +118,7 @@ tcTyAndClassDecls boot_details tyclds_s | -- remaining groups are typecheck in the extended global | env | | tcTyClGroup :: ModDetails -> TyClGroup Name -> TcM TcGblEnv | -tcTyClGroup boot_details decls | +tcTyClGroup _boot_details decls | | all (isKindDecl . unLoc) decls | = do (kcons, _) <- fixM $ \ ~(_, conss) -> do | let rec_info = panic "tcTyClGroup" "rec_info" | @@ -820,13 +820,12 @@ mkKindCon _rec_info tycons KindDecl { tcdLName = | L _ kind_name | kind_name | sKind | kvars | - [] -- XXX roles here? | + (replicate (length kvars) Nominal) -- no interesting kind | equality | Nothing | [] | (DataKindTyCon tycons) | NoParentTyCon | - -- TODO, make the rec_info work | - NonRecursive --(rti_is_rec rec_info kind_name) | + NonRecursive -- XXX is this OK? | False | NotPromotable | where | @@ -838,8 +837,8 @@ mkKindCon _ _ _ = | panic "mkKindCon" "non 'data kind' declaration" | | tcKindDecl :: RecTyInfo -> TyClDecl Name -> TcM [TyCon] | -tcKindDecl rec_info KindDecl { tcdLName = L _ kind_name, tcdKVars = | lknames | - , tcdTypeCons = cons } | +tcKindDecl _rec_info KindDecl { tcdLName = L _ kind_name, tcdKVars = | lknames | + , tcdTypeCons = cons } | = do traceTc "tcKindDecl" (ppr kind_name) | | ~(ATyCon kcon) <- tcLookupGlobal kind_name | @@ -1394,7 +1393,9 @@ tcTyConDecl kvars kind TyConDecl { tycon_name = | name, tycon_details = details } | RecCon {} -> panic "tcTyConDecl" "unexpected record | constructor" | let (kcon,_) = splitTyConApp kind | con_kind = mkPiKinds kvars (mkFunTys ks kind) | - return (mkDataKindTyCon kcon (unLoc name) con_kind) | + roles = replicate (length kvars) Nominal | + ++ replicate (length ks) Representational | + return (mkDataKindTyCon kcon (unLoc name) con_kind roles) | | | \end{code} | diff --git a/compiler/types/TyCon.lhs b/compiler/types/TyCon.lhs | index 8ccbcc9..9308713 100644 | --- a/compiler/types/TyCon.lhs | +++ b/compiler/types/TyCon.lhs | @@ -1087,13 +1087,13 @@ mkPromotedDataCon con name unique kind roles | | -- | Construct a type constructor for a type introduced by a 'data | kind' | -- declaration. | -mkDataKindTyCon :: TyCon -> Name -> Kind -> TyCon | -mkDataKindTyCon kc name kind | +mkDataKindTyCon :: TyCon -> Name -> Kind -> [Role] -> TyCon | +mkDataKindTyCon kc name kind roles | = PromotedDataCon { | tyConName = name, | tyConUnique = nameUnique name, | - tyConArity = 0, | - tc_roles = [], -- XXX is this correct? | + tyConArity = length roles, | + tc_roles = roles, | tc_kind = kind, | parentTyCon = kc | } | | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

2 1

build failures on Linux
by Kazu Yamamoto 13 Sep '13

13 Sep '13

Hi, I cannot build GHC head today on Linux. It seems to me that this bug is relating to the followings: https://github.com/sol/doctest-haskell/issues/59 https://github.com/sol/doctest-haskell/pull/60 Why did the initial value of v_opt_C_ready in GHCI change? --Kazu Haddock coverage: 100% ( 1 / 1) in 'GHC.IntWord64' 78% ( 7 / 9) in 'GHC.Types' 3% ( 2 / 63) in 'GHC.Tuple' 0% ( 0 / 3) in 'GHC.Debug' 0% ( 0 /351) in 'GHC.PrimopWrappers' 2% ( 1 / 43) in 'GHC.PrimWrappers' 17% ( 1 / 6) in 'GHC.CString' 31% (170 /540) in 'GHC.Prim' 100% ( 3 / 3) in 'GHC.Magic' 38% ( 6 / 16) in 'GHC.Classes' haddock: internal error: haddock: panic! (the 'impossible' happened) (GHC version 7.7.20130912 for x86_64-unknown-linux): Static flags have not been initialised! Please call GHC.newSession or GHC.parseStaticFlags early enough. Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [libraries/ghc-prim/dist-install/doc/html/ghc-prim/ghc-prim.haddock] Error 1

4 4

possible solution! Re: llvm calling convention matters
by Carter Schonwald 13 Sep '13

13 Sep '13

to repeat: I think no one would have object to having a clearly marked, experimental -fllvmExpermentalAVX flag that requires building LLVM with a specified patch, as a way to showcase your multivector work! that would evade all of my objections (provided avx is still exposed with normal -fllvm, but spilled to stack rather than registers), and i'd actually argue in favor of such. Especially since it would not impose any release cycle constraints on a subsequent, systematic exploration for using XMM / YMM / ZMM in the calling convention going forward. @Geoff, Simons, Johan, and others: does anyone object to that approach? applying such a calling convention patch to llvm is really quite straightforward, and the build process is pretty zippy after that too. cheers -Carter On Thu, Sep 12, 2013 at 2:34 AM, Carter Schonwald < carter.schonwald(a)gmail.com> wrote: > that said it does occur to me that there is an alternative solution that > may be acceptable for everyone! > > what about providing a pseudo compatible way called -fllvm-experimentalAVX > (or something), and simply require that for it to be used, the user has an > llvm Patched with the YMM simd in register fun call support? internally > that could just be an llvm way that trips the logic that puts the first few > AVX values in those YMM1-6 slots if they are the first args, so only the > stack spilling logic needs be changed? > > (ie it wouldn't be tied to an llvm version, but rather this pseduo way > flag) > > does that make sense? > > either way, i'd really like having avx even if its always spilled to stack > at funcalls with standard LLVMs! > > cheers > -carter > > > > > On Thu, Sep 12, 2013 at 2:28 AM, Carter Schonwald < > carter.schonwald(a)gmail.com> wrote: > >> Geoff, >> >> a prosaic reason why there *might* be a fundamentally breaking change >> would be the following idea nathan howell suggested to me this afternoon: >> change the Sp and SPLim register so that the X86/x86_64 target can use the >> CPU's Push and (maybe) Pop instructions for the stack manipulations, >> rather than MOV and fam. see http://ghc.haskell.org/trac/ghc/ticket/8272(which is just what i've said). Thats one change thats pretty simple but >> deep, but likely worth exploring. >> >> >> i'm saying any ABI change for GHC 7.10, would likely entail patching LLVM >> 3.4, because thats the only LLVM version likely to come out between now and >> whenever we get 7.10 out (assuming 7.10 lands within the next 8-12 months, >> which is reasonable since we've got noticeably more (amazing) people >> helping out lately). Thus, any change there entails either asking the llvm >> folks to support >1 GHC convention per architecture, or replace the current >> one! I'd rather do the latter than the former, when it comes to asking >> other people to maintain it :) >> (and llvm engineers do in fact help out maintaining that code) >> >> >> have you run a Nofib, or even benchmarks restricted to your multivector >> code, for the current calling convention (including the spilling AVX >> vectors to the stack thats the current plan i gather) VS passing in >> registers with an LLVM built using the patches i worked out ~ 2 months ago? >> it'd be really easy to build that custom llvm, then run the benchmarks! >> (i'm happy to help, and ultimately, benchmarks will reveal if its worth >> while or not! And if the main goal is for your talk, its still valid even >> if its not in the merge window over the next 4 days). >> >> I really think its not obvious what the "best" abi change would be! It >> really will require coming up with a list of variants, implementing them, >> and running nofib with each variant, which i lack the compute/human time >> resources to do this week. Modern hardware is complex enough that for >> something like an ABI change, the only healthy attitude can be "lets >> benchmark it!". >> >> i'd really like any change in calling convention to also improve perf on >> codes that aren't explicitly simd! (and a conservative simd only change, >> blocks/conflicts with that augmentation going forward, and not just for the >> stack pointer example i mention early) >> >> Not just scalar floats in simd registers , but perhaps also words/ints ! >> >> (though that latter bit might be pretty ambitious and subtle, i'll need >> to investigate that a bit to see how feasible it may be). >> SIMD has great support for ints/words, and any partial abi change on the >> llvm backend now would make it hard to support that later well (or at >> least, thats what it looks like to me). actually effectively using simd >> for scalar ints and words should be doable, but might force us to be a bit >> more thoughtful on how GHC internally distinguishes ints used for address >> arithmetic, vs ints used as data. (interestingly, i'm not sure if any >> current extent x86 calling convention does that!) >> >> >> That single change would make 7.10 require a completely different >> llvm and native code gen convention from our current one, plus touch all of >> the code gen on x86 architectures. >> >> >> basically: we're lucky that everyone builds haskell code from source, so >> ABI compat across GHC versions is a non issue. BUT, any ABI changes should >> be backed by benchmarks (at least when the change is performance >> motivated). Likewise, because we use LLVM as an external dep for the -fllvm >> backend, we really need to keep how their release cycle interacts with our >> release cycle, because people use haskell and ghc! which as many like to >> say, is both a boon and a pain ;). >> >> Having people hit ghc acting broken with an llvm that was "supported >> before" is risky support problem to deal with. having an LLVM head variant >> support a modified ABI, and then later needing to break it for 7.10 (for >> one of the possible exploratory reasons above) would lead to a support >> headache I don't wish on anyone. >> >> pardon the verbose answer, but thats my offhand take >> >> cheers >> -Carter >> >> >> On Wed, Sep 11, 2013 at 10:10 PM, Geoffrey Mainland <mainland(a)apeiron.net >> > wrote: >> >>> We support compiling some code with -fllvm and some not in the same >>> executable. Otherwise how could users of the Haskell Platform link their >>> -fllvm-compiled code with native-codegen-compiled libraries like base, >>> etc.? >>> >>> In other words, the LLVM and native back ends use the same calling >>> convention. With my SIMD work, they still use the same calling >>> conventions, but the native codegen can never generate code that uses >>> SIMD instructions. >>> >>> Geoff >>> >>> On 09/11/2013 10:03 PM, Johan Tibell wrote: >>> > OK. But that doesn't create a problem for the code we output with the >>> > LLVM backend, no? Or do we support compiling some code with -fllvm and >>> > some not in the same executable? >>> > >>> > >>> > On Wed, Sep 11, 2013 at 6:56 PM, Geoffrey Mainland >>> > <mainland(a)apeiron.net <mailto:mainland@apeiron.net>> wrote: >>> > >>> > We definitely have interop between the native codegen and the LLVM >>> > back >>> > end now. Otherwise anyone who wanted to use the LLVM back end >>> > would have >>> > to build GHC themselves. Interop means that users can install the >>> > Haskell Platform and still use -fllvm when it makes a performance >>> > difference. >>> > >>> > Geoff >>> > >>> > On 09/11/2013 07:59 PM, Johan Tibell wrote: >>> > > Do nothing different than you're doing for 7.8, we can sort it >>> out >>> > > later. Just put a comment on the primops saying they're >>> > LLVM-only. See >>> > > e.g. >>> > > >>> > > >>> > > >>> > >>> https://github.com/ghc/ghc/blob/master/compiler/prelude/primops.txt.pp#L181 >>> > > >>> > > for an example how to add docs to primops. >>> > > >>> > > I don't think we need interop between the native and the LLVM >>> > > backends. We don't have that now do we (i.e. they use different >>> > > calling conventions). >>> > > >>> > > >>> > > >>> > > On Wed, Sep 11, 2013 at 4:51 PM, Geoffrey Mainland >>> > > <mainland(a)apeiron.net <mailto:mainland@apeiron.net> >>> > <mailto:mainland@apeiron.net <mailto:mainland@apeiron.net>>> >>> wrote: >>> > > >>> > > On 09/11/2013 07:44 PM, Johan Tibell wrote: >>> > > > On Wed, Sep 11, 2013 at 4:40 PM, Geoffrey Mainland >>> > > <mainland(a)apeiron.net <mailto:mainland@apeiron.net> >>> > <mailto:mainland@apeiron.net <mailto:mainland@apeiron.net>>> >>> wrote: >>> > > > > Do you mean we need a reasonable emulation of the SIMD >>> > primops for >>> > > > > the native codegen? >>> > > > >>> > > > Yes. Reasonable in the sense that it computes the right >>> > result. >>> > > I can >>> > > > see that some code might still want to #ifdef (if the >>> > fallback isn't >>> > > > fast enough). >>> > > >>> > > Two implications of this requirement: >>> > > >>> > > 1) There will not be SIMD in 7.8. I just don't have the >>> > time. In fact, >>> > > what SIMD support is there already will have to be removed >>> if we >>> > > cannot >>> > > live with LLVM-only SIMD primops. >>> > > >>> > > 2) If we also require interop between the LLVM back-end and >>> > the native >>> > > codegen, then we cannot pass any SIMD vectors in >>> > registers---they all >>> > > must be passed on the stack. >>> > > >>> > > My plan, as discussed with Simon PJ, is to not support SIMD >>> > primops at >>> > > all with the native codegen. If there is a strong feeling >>> that >>> > > this *is >>> > > not* the way to go, the I need to know ASAP. >>> > > >>> > > Geoff >>> > > >>> > > >>> > > >>> > >>> > >>> >>> >> >

2 7

AMP patch and performance tests failures
by Jan Stolarek 12 Sep '13

12 Sep '13

I am getting validation failures from T3064 performance test: =====> T3064(normal) 1741 of 3782 [0, 0, 0] cd ./perf/compiler && '/5playpen/t-jastol/ghc-validate/inplace/bin/ghc-stage2' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T3064.hs +RTS -V0 -tT3064.comp.stats --machine-readable -RTS >T3064.comp.stderr 2>&1 peak_megabytes_allocated value is too high: Expected peak_megabytes_allocated: 30 +/-20% Lower bound peak_megabytes_allocated: 24 Upper bound peak_megabytes_allocated: 36 Actual peak_megabytes_allocated: 39 This tests has some instances of Monads and Applicatives so my random guess is that AMP patch caused that. Can anyone working on that patch confirm or deny that it increases allocation and causes this failure? I also got a validation failure from T5837 a couple of times, but it doesn't happen always. Janek

3 2

running out of bits in lexer
by Richard Eisenberg 12 Sep '13

12 Sep '13

Hi devs, I'm in the process of reimplementing role annotations (#8185). I need to add a new pseudo-keyword 'role' to the lexer, and I'm initially tempted to guard the lexing of this keyword with an extension bit (like, say, tyFamBit in Lexer.x). But, there are already bits 0 to 31 taken, and the type of the bitmap is Int, so I'm out of luck. However, I think there's a way out: the parser should do the right thing when it sees these pseudo-keywords, and hopefully the downstream code could check the enabled options. So, it would seem that having some of these bit controls in the lexer is unnecessary -- more a belt-and-suspenders thing than anything else. So, I propose to let the lexer treat 'role' specially in all cases, relying on the parser to treat it like an ordinary varid except when 'role' comes right after 'type'. Is there something I'm missing here? In particular, I can't think of a good reason not to treat the pseudo-keyword 'family' in the same way and allow it to lex regardless of the extensions. This might also improve error messages. Thanks, Richard

2 1