summaryrefslogtreecommitdiff
path: root/compiler/deSugar
Commit message (Collapse)AuthorAgeFilesLines
* fix warningSimon Marlow2009-07-281-2/+0
|
* Remove old 'foreign import dotnet' codeSimon Marlow2009-07-272-47/+10
| | | | It still lives in darcs, if anyone wants to revive it sometime.
* Remove GHC's haskell98 dependencyIan Lynagh2009-07-242-2/+2
|
* Add tuple sections as a new featuresimonpj@microsoft.com2009-07-237-64/+72
| | | | | | | | | | | | | | | | This patch adds tuple sections, so that (x,,z) means \y -> (x,y,z) Thanks for Max Bolinbroke for doing the hard work. In the end, instead of using two constructors in HsSyn, I used just one (still called ExplicitTuple) whose arguments can be Present (LHsExpr id) or Missing PostTcType While I was at it, I did a bit of refactoring too.
* Take account of GADTs when reporting patterm-match overlapsimonpj@microsoft.com2009-07-221-6/+9
| | | | | | | | | | | | | | | | | | | | | When matching against a GADT, some of the constructors may be impossible. For example data T a where T1 :: T Int T2 :: T Bool T3 :: T a f :: T Int -> Int f T1 = 3 f T3 = 4 Here, does not have any missing cases, despite omittting T2, because T2 :: T Bool. This patch teaches the overlap checker about GADTs, which happily turned out to be rather easy even though the overlap checker needs a serious rewrite.
* Fix Trac #3382: desugaring of NPatssimonpj@microsoft.com2009-07-201-27/+32
| | | | | | | Max spotted that the short-cut rules for desugaring NPats (where we compare against a literal) were wrong now that we have overloaded strings.
* Remove unused importsIan Lynagh2009-07-078-10/+0
|
* Trim unused imports detected by new unused-import codesimonpj@microsoft.com2009-07-061-8/+0
|
* Make changes to -fwarn-unused-do-bind and -fwarn-wrong-do-bind suggested by SPJMax Bolingbroke2009-07-021-25/+28
|
* Support for -fwarn-unused-do-bind and -fwarn-wrong-do-bind, as per #3263Max Bolingbroke2009-07-011-23/+65
|
* New syntax for GADT-style record declarations, and associated refactoringsimonpj@microsoft.com2009-07-021-4/+4
| | | | | | | | | | | | | | | | | | | | | | | The main purpose of this patch is to fix Trac #3306, by fleshing out the syntax for GADT-style record declraations so that you have a context in the type. The new form is data T a where MkT :: forall a. Eq a => { x,y :: !a } -> T a See discussion on the Trac ticket. The old form is still allowed, but give a deprecation warning. When we remove the old form we'll also get rid of the one reduce/reduce error in the grammar. Hurrah! While I was at it, I failed as usual to resist the temptation to do lots of refactoring. The parsing of data/type declarations is now much simpler and more uniform. Less code, less chance of errors, and more functionality. Took longer than I planned, though. ConDecl has record syntax, but it was not being used consistently, so I pushed that through the compiler.
* Fix #3319, and do various tidyups at the same timeSimon Marlow2009-06-262-3/+2
| | | | | | - converting a THSyn FFI declaration to HsDecl was broken; fixed - pretty-printing of FFI declarations was variously bogus; fixed - there was an unused "library" field in CImport; removed
* Add missing StgPrimCallOp case in repCCallConvDuncan Coutts2009-06-111-1/+1
| | | | We don't handle "foreign import prim" in TH stuff.
* Desugaring for "foreign import prim"Duncan Coutts2009-06-091-1/+36
| | | | | | | | | | | | | Unlike normal foreign imports which desugar into a separate worker and wrapper, we use just a single wrapper decleration. The representation in Core of the call is currently as a foreign call. This means the args are all treated as fully strict. This is ok at the moment because we restrict the types for foreign import prim to be of unboxed types, however in future we may want to make prim imports be the normal cmm calling convention for Haskell functions, in which case we would not be able to assume all args are strict. At that point it may make more sense to represent cmm/prim calls distinct from foreign calls, and more like the we the existing PrimOp calls are handled.
* Allow RULES for seq, and exploit themsimonpj@microsoft.com2009-06-033-7/+98
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Roman found situations where he had case (f n) of _ -> e where he knew that f (which was strict in n) would terminate if n did. Notice that the result of (f n) is discarded. So it makes sense to transform to case n of _ -> e Rather than attempt some general analysis to support this, I've added enough support that you can do this using a rewrite rule: RULE "f/seq" forall n. seq (f n) e = seq n e You write that rule. When GHC sees a case expression that discards its result, it mentally transforms it to a call to 'seq' and looks for a RULE. (This is done in Simplify.rebuildCase.) As usual, the correctness of the rule is up to you. This patch implements the extra stuff. I have not documented it explicitly in the user manual yet... let's see how useful it is first. The patch looks bigger than it is, because a) Comments; see esp MkId Note [seqId magic] b) Some refactoring. Notably, I moved the special desugaring for seq from MkCore back into DsUtils where it properly belongs. (It's really a desugaring thing, not a CoreSyn invariant.) c) Annoyingly, in a RULE left-hand side we need to be careful that the magical desugaring done in MkId Note [seqId magic] item (c) is *not* done on the LHS of a rule. Or rather, we arrange to un-do it, in DsBinds.decomposeRuleLhs.
* Template Haskell: improve lifting for stringssimonpj@microsoft.com2009-05-271-6/+11
| | | | | | | | | | | | | | | | | | When you have a (\s::String -> ....[| s |]....), the string 's' is lifted. We used to get a chain of single-character Cons nodes, correct but lots and lots of code. This patch arranges to optimise that to a string literal. It does so in two places: a) In TcExpr, if we know that s::String, we generate liftString directly b) In DsMeta, if we find a list of character literals, we convert to a string. This catches a few cases that (a) does not There an accompanying patch in the template-haskell package, adding Language.Haskell.TH.Syntax.liftString
* Fix a lint failure when we have a ! (# ... #) pattern in a where clauseIan Lynagh2009-04-241-0/+15
| | | | | This showed up when converting ds057 to follow the new bang pattern rules, in #2806.
* mkErrorAppDs now takes an SDoc rather than a StringIan Lynagh2009-03-315-15/+14
| | | | | This avoids some showSDoc's where the String then gets converted back into an SDoc.
* Fix Trac #246: order of matching in record patternssimonpj@microsoft.com2009-03-301-40/+112
| | | | | | | | | | | | | While I was looking at the desugaring of pattern matching (fixing Trac #3126) I finally got around to fixing another long-standing bug: when matching in a record pattern, GHC should match left-to-right in the programmer-specfied order, *not* left-to-right positionally in the original record declaration. Needless to say, that requires a little more code. See Note [Record patterns] in MatchCon.lhs
* Fix Trac #3126: matching overloaded literalssimonpj@microsoft.com2009-03-302-33/+44
| | | | | | | | | | | | | | | Claus Reinke uncovered a long-standing bug in GHC, whereby we were combining the pattern-match on overloaded literals, missing the fact that an intervening pattern (for a different literal) might also match. (If someone had a very odd implementation of fromInteger!) See Note [Grouping overloaded literal patterns] in Match.lhs If this merges smoothly to 6.10, go for it, but it's very much a corner case. Thank you Claus!
* White space cosmetics onlysimonpj@microsoft.com2009-03-301-5/+5
|
* Template Haskell: added bang patternsManuel M T Chakravarty2009-03-261-3/+9
|
* Template Haskell: support for kind annotationsManuel M T Chakravarty2009-03-261-51/+141
|
* Template Haskell: support for INLINE and SPECIALISE pragmasManuel M T Chakravarty2009-03-241-16/+115
|
* Template Haskell support for equality constraintsManuel M T Chakravarty2009-03-191-20/+57
|
* Template Haskell: support for type family declarationsManuel M T Chakravarty2009-03-191-79/+207
|
* Add the notion of "constructor-like" Ids for rule-matchingsimonpj@microsoft.com2009-03-182-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds an optional CONLIKE modifier to INLINE/NOINLINE pragmas, {-# NOINLINE CONLIKE [1] f #-} The effect is to allow applications of 'f' to be expanded in a potential rule match. Example {-# RULE "r/f" forall v. r (f v) = f (v+1) #-} Consider the term let x = f v in ..x...x...(r x)... Normally the (r x) would not match the rule, because GHC would be scared about duplicating the redex (f v). However the CONLIKE modifier says to treat 'f' like a constructor in this situation, and "look through" the unfolding for x. So (r x) fires, yielding (f (v+1)). The main changes are: - Syntax - The inlinePragInfo field of an IdInfo has a RuleMatchInfo component, which records whether or not the Id is CONLIKE. Of course, this needs to be serialised in interface files too. - The occurrence analyser (OccAnal) and simplifier (Simplify) treat CONLIKE thing like constructors, by ANF-ing them - New function coreUtils.exprIsExpandable is like exprIsCheap, but additionally spots applications of CONLIKE functions - A CoreUnfolding has a field that caches exprIsExpandable - The rule matcher consults this field. See Note [Expanding variables] in Rules.lhs. On the way I fixed a lurking variable bug in the way variables are expanded. See Note [Do not expand locally-bound variables] in Rule.lhs. I also did a bit of reformatting and refactoring in Rules.lhs, so the module has more lines changed than are really different.
* Special-case desugaring of simple parallel array comprehensionsRoman Leshchinskiy2009-03-071-1/+23
|
* When generating C, don't pretend functions are dataIan Lynagh2009-02-061-2/+7
| | | | | | | | | | | | | | | We used to generated things like: extern StgWordArray (newCAF) __attribute__((aligned (8))); ((void (*)(void *))(W_)&newCAF)((void *)R1.w); (which is to say, pretend that newCAF is some data, then cast it to a function and call it). This goes wrong on at least IA64, where: A function pointer on the ia64 does not point to the first byte of code. Intsead, it points to a structure that describes the function. The first quadword in the structure is the address of the first byte of code so we end up dereferencing function pointers one time too many, and segfaulting.
* Rollback INLINE patchesSimon Marlow2008-12-163-140/+125
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | rolling back: Fri Dec 5 16:54:00 GMT 2008 simonpj@microsoft.com * Completely new treatment of INLINE pragmas (big patch) This is a major patch, which changes the way INLINE pragmas work. Although lots of files are touched, the net is only +21 lines of code -- and I bet that most of those are comments! HEADS UP: interface file format has changed, so you'll need to recompile everything. There is not much effect on overall performance for nofib, probably because those programs don't make heavy use of INLINE pragmas. Program Size Allocs Runtime Elapsed Min -11.3% -6.9% -9.2% -8.2% Max -0.1% +4.6% +7.5% +8.9% Geometric Mean -2.2% -0.2% -1.0% -0.8% (The +4.6% for on allocs is cichelli; see other patch relating to -fpass-case-bndr-to-join-points.) The old INLINE system ~~~~~~~~~~~~~~~~~~~~~ The old system worked like this. A function with an INLINE pragam got a right-hand side which looked like f = __inline_me__ (\xy. e) The __inline_me__ part was an InlineNote, and was treated specially in various ways. Notably, the simplifier didn't inline inside an __inline_me__ note. As a result, the code for f itself was pretty crappy. That matters if you say (map f xs), because then you execute the code for f, rather than inlining a copy at the call site. The new story: InlineRules ~~~~~~~~~~~~~~~~~~~~~~~~~~ The new system removes the InlineMe Note altogether. Instead there is a new constructor InlineRule in CoreSyn.Unfolding. This is a bit like a RULE, in that it remembers the template to be inlined inside the InlineRule. No simplification or inlining is done on an InlineRule, just like RULEs. An Id can have an InlineRule *or* a CoreUnfolding (since these are two constructors from Unfolding). The simplifier treats them differently: - An InlineRule is has the substitution applied (like RULES) but is otherwise left undisturbed. - A CoreUnfolding is updated with the new RHS of the definition, on each iteration of the simplifier. An InlineRule fires regardless of size, but *only* when the function is applied to enough arguments. The "arity" of the rule is specified (by the programmer) as the number of args on the LHS of the "=". So it makes a difference whether you say {-# INLINE f #-} f x = \y -> e or f x y = e This is one of the big new features that InlineRule gives us, and it is one that Roman really wanted. In contrast, a CoreUnfolding can fire when it is applied to fewer args than than the function has lambdas, provided the result is small enough. Consequential stuff ~~~~~~~~~~~~~~~~~~~ * A 'wrapper' no longer has a WrapperInfo in the IdInfo. Instead, the InlineRule has a field identifying wrappers. * Of course, IfaceSyn and interface serialisation changes appropriately. * Making implication constraints inline nicely was a bit fiddly. In the end I added a var_inline field to HsBInd.VarBind, which is why this patch affects the type checker slightly * I made some changes to the way in which eta expansion happens in CorePrep, mainly to ensure that *arguments* that become let-bound are also eta-expanded. I'm still not too happy with the clarity and robustness fo the result. * We now complain if the programmer gives an INLINE pragma for a recursive function (prevsiously we just ignored it). Reason for change: we don't want an InlineRule on a LoopBreaker, because then we'd have to check for loop-breaker-hood at occurrence sites (which isn't currenlty done). Some tests need changing as a result. This patch has been in my tree for quite a while, so there are probably some other minor changes. M ./compiler/basicTypes/Id.lhs -11 M ./compiler/basicTypes/IdInfo.lhs -82 M ./compiler/basicTypes/MkId.lhs -2 +2 M ./compiler/coreSyn/CoreFVs.lhs -2 +25 M ./compiler/coreSyn/CoreLint.lhs -5 +1 M ./compiler/coreSyn/CorePrep.lhs -59 +53 M ./compiler/coreSyn/CoreSubst.lhs -22 +31 M ./compiler/coreSyn/CoreSyn.lhs -66 +92 M ./compiler/coreSyn/CoreUnfold.lhs -112 +112 M ./compiler/coreSyn/CoreUtils.lhs -185 +184 M ./compiler/coreSyn/MkExternalCore.lhs -1 M ./compiler/coreSyn/PprCore.lhs -4 +40 M ./compiler/deSugar/DsBinds.lhs -70 +118 M ./compiler/deSugar/DsForeign.lhs -2 +4 M ./compiler/deSugar/DsMeta.hs -4 +3 M ./compiler/hsSyn/HsBinds.lhs -3 +3 M ./compiler/hsSyn/HsUtils.lhs -2 +7 M ./compiler/iface/BinIface.hs -11 +25 M ./compiler/iface/IfaceSyn.lhs -13 +21 M ./compiler/iface/MkIface.lhs -24 +19 M ./compiler/iface/TcIface.lhs -29 +23 M ./compiler/main/TidyPgm.lhs -55 +49 M ./compiler/parser/ParserCore.y -5 +6 M ./compiler/simplCore/CSE.lhs -2 +1 M ./compiler/simplCore/FloatIn.lhs -6 +1 M ./compiler/simplCore/FloatOut.lhs -23 M ./compiler/simplCore/OccurAnal.lhs -36 +5 M ./compiler/simplCore/SetLevels.lhs -59 +54 M ./compiler/simplCore/SimplCore.lhs -48 +52 M ./compiler/simplCore/SimplEnv.lhs -26 +22 M ./compiler/simplCore/SimplUtils.lhs -28 +4 M ./compiler/simplCore/Simplify.lhs -91 +109 M ./compiler/specialise/Specialise.lhs -15 +18 M ./compiler/stranal/WorkWrap.lhs -14 +11 M ./compiler/stranal/WwLib.lhs -2 +2 M ./compiler/typecheck/Inst.lhs -1 +3 M ./compiler/typecheck/TcBinds.lhs -17 +27 M ./compiler/typecheck/TcClassDcl.lhs -1 +2 M ./compiler/typecheck/TcExpr.lhs -4 +6 M ./compiler/typecheck/TcForeign.lhs -1 +1 M ./compiler/typecheck/TcGenDeriv.lhs -14 +13 M ./compiler/typecheck/TcHsSyn.lhs -3 +2 M ./compiler/typecheck/TcInstDcls.lhs -5 +4 M ./compiler/typecheck/TcRnDriver.lhs -2 +11 M ./compiler/typecheck/TcSimplify.lhs -10 +17 M ./compiler/vectorise/VectType.hs +7 Mon Dec 8 12:43:10 GMT 2008 simonpj@microsoft.com * White space only M ./compiler/simplCore/Simplify.lhs -2 Mon Dec 8 12:48:40 GMT 2008 simonpj@microsoft.com * Move simpleOptExpr from CoreUnfold to CoreSubst M ./compiler/coreSyn/CoreSubst.lhs -1 +87 M ./compiler/coreSyn/CoreUnfold.lhs -72 +1 Mon Dec 8 17:30:18 GMT 2008 simonpj@microsoft.com * Use CoreSubst.simpleOptExpr in place of the ad-hoc simpleSubst (reduces code too) M ./compiler/deSugar/DsBinds.lhs -50 +16 Tue Dec 9 17:03:02 GMT 2008 simonpj@microsoft.com * Fix Trac #2861: bogus eta expansion Urghlhl! I "tided up" the treatment of the "state hack" in CoreUtils, but missed an unexpected interaction with the way that a bottoming function simply swallows excess arguments. There's a long Note [State hack and bottoming functions] to explain (which accounts for most of the new lines of code). M ./compiler/coreSyn/CoreUtils.lhs -16 +53 Mon Dec 15 10:02:21 GMT 2008 Simon Marlow <marlowsd@gmail.com> * Revert CorePrep part of "Completely new treatment of INLINE pragmas..." The original patch said: * I made some changes to the way in which eta expansion happens in CorePrep, mainly to ensure that *arguments* that become let-bound are also eta-expanded. I'm still not too happy with the clarity and robustness fo the result. Unfortunately this change apparently broke some invariants that were relied on elsewhere, and in particular lead to panics when compiling with profiling on. Will re-investigate in the new year. M ./compiler/coreSyn/CorePrep.lhs -53 +58 M ./configure.ac -1 +1 Mon Dec 15 12:28:51 GMT 2008 Simon Marlow <marlowsd@gmail.com> * revert accidental change to configure.ac M ./configure.ac -1 +1
* Make some profiling flags dynamicIan Lynagh2008-12-091-5/+7
| | | | | | | In particular: -fauto-sccs-on-all-toplevs -auto-all -no-auto-all -fauto-sccs-on-exported-toplevs -auto -no-auto -fauto-sccs-on-individual-cafs -caf-all -no-caf-all
* Use CoreSubst.simpleOptExpr in place of the ad-hoc simpleSubst (reduces code ↵simonpj@microsoft.com2008-12-081-50/+16
| | | | too)
* Completely new treatment of INLINE pragmas (big patch)simonpj@microsoft.com2008-12-053-76/+125
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a major patch, which changes the way INLINE pragmas work. Although lots of files are touched, the net is only +21 lines of code -- and I bet that most of those are comments! HEADS UP: interface file format has changed, so you'll need to recompile everything. There is not much effect on overall performance for nofib, probably because those programs don't make heavy use of INLINE pragmas. Program Size Allocs Runtime Elapsed Min -11.3% -6.9% -9.2% -8.2% Max -0.1% +4.6% +7.5% +8.9% Geometric Mean -2.2% -0.2% -1.0% -0.8% (The +4.6% for on allocs is cichelli; see other patch relating to -fpass-case-bndr-to-join-points.) The old INLINE system ~~~~~~~~~~~~~~~~~~~~~ The old system worked like this. A function with an INLINE pragam got a right-hand side which looked like f = __inline_me__ (\xy. e) The __inline_me__ part was an InlineNote, and was treated specially in various ways. Notably, the simplifier didn't inline inside an __inline_me__ note. As a result, the code for f itself was pretty crappy. That matters if you say (map f xs), because then you execute the code for f, rather than inlining a copy at the call site. The new story: InlineRules ~~~~~~~~~~~~~~~~~~~~~~~~~~ The new system removes the InlineMe Note altogether. Instead there is a new constructor InlineRule in CoreSyn.Unfolding. This is a bit like a RULE, in that it remembers the template to be inlined inside the InlineRule. No simplification or inlining is done on an InlineRule, just like RULEs. An Id can have an InlineRule *or* a CoreUnfolding (since these are two constructors from Unfolding). The simplifier treats them differently: - An InlineRule is has the substitution applied (like RULES) but is otherwise left undisturbed. - A CoreUnfolding is updated with the new RHS of the definition, on each iteration of the simplifier. An InlineRule fires regardless of size, but *only* when the function is applied to enough arguments. The "arity" of the rule is specified (by the programmer) as the number of args on the LHS of the "=". So it makes a difference whether you say {-# INLINE f #-} f x = \y -> e or f x y = e This is one of the big new features that InlineRule gives us, and it is one that Roman really wanted. In contrast, a CoreUnfolding can fire when it is applied to fewer args than than the function has lambdas, provided the result is small enough. Consequential stuff ~~~~~~~~~~~~~~~~~~~ * A 'wrapper' no longer has a WrapperInfo in the IdInfo. Instead, the InlineRule has a field identifying wrappers. * Of course, IfaceSyn and interface serialisation changes appropriately. * Making implication constraints inline nicely was a bit fiddly. In the end I added a var_inline field to HsBInd.VarBind, which is why this patch affects the type checker slightly * I made some changes to the way in which eta expansion happens in CorePrep, mainly to ensure that *arguments* that become let-bound are also eta-expanded. I'm still not too happy with the clarity and robustness fo the result. * We now complain if the programmer gives an INLINE pragma for a recursive function (prevsiously we just ignored it). Reason for change: we don't want an InlineRule on a LoopBreaker, because then we'd have to check for loop-breaker-hood at occurrence sites (which isn't currenlty done). Some tests need changing as a result. This patch has been in my tree for quite a while, so there are probably some other minor changes.
* Add static flag -fsimple-list-literalssimonpj@microsoft.com2008-12-051-1/+19
| | | | | | | | | | The new static flag -fsimple-list-literals makes ExplicitList literals be desugared in the straightforward way, rather than using 'build' as now. See SLPJ comments with Note [Desugaring explicit lists]. I don't expect this flag to be used by users (hence no docs). It's just there to let me try the performance effects of switching on and off.
* Merging in the new codegen branchdias@eecs.harvard.edu2008-08-141-25/+21
| | | | | | | | | | | | | | | | | | This merge does not turn on the new codegen (which only compiles a select few programs at this point), but it does introduce some changes to the old code generator. The high bits: 1. The Rep Swamp patch is finally here. The highlight is that the representation of types at the machine level has changed. Consequently, this patch contains updates across several back ends. 2. The new Stg -> Cmm path is here, although it appears to have a fair number of bugs lurking. 3. Many improvements along the CmmCPSZ path, including: o stack layout o some code for infotables, half of which is right and half wrong o proc-point splitting
* Fix #2740: we were missing the free variables on some expressionsSimon Marlow2008-11-251-14/+13
| | | | | Particularly boolean expresions: the conditional of an 'if', and guards, were missing their free variables.
* Fix desugaring of record update (fixes Trac #2735)simonpj@microsoft.com2008-11-031-10/+15
|
* Comments onlysimonpj@microsoft.com2008-10-311-2/+4
|
* Add (a) CoreM monad, (b) new Annotations featuresimonpj@microsoft.com2008-10-301-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch, written by Max Bolingbroke, does two things 1. It adds a new CoreM monad (defined in simplCore/CoreMonad), which is used as the top-level monad for all the Core-to-Core transformations (starting at SimplCore). It supports * I/O (for debug printing) * Unique supply * Statistics gathering * Access to the HscEnv, RuleBase, Annotations, Module The patch therefore refactors the top "skin" of every Core-to-Core pass, but does not change their functionality. 2. It adds a completely new facility to GHC: Core "annotations". The idea is that you can say {#- ANN foo (Just "Hello") #-} which adds the annotation (Just "Hello") to the top level function foo. These annotations can be looked up in any Core-to-Core pass, and are persisted into interface files. (Hence a Core-to-Core pass can also query the annotations of imported things.) Furthermore, a Core-to-Core pass can add new annotations (eg strictness info) of its own, which can be queried by importing modules. The design of the annotation system is somewhat in flux. It's designed to work with the (upcoming) dynamic plug-ins mechanism, but is meanwhile independently useful. Do not merge to 6.10!
* Mostly-fix Trac #2595: updates for existentialssimonpj@microsoft.com2008-10-282-37/+94
| | | | | | | | | | | | | | | | Ganesh wanted to update records that involve existentials. That seems reasonable to me, and this patch covers existentials, GADTs, and data type families. The restriction is that The types of the updated fields may mention only the universally-quantified type variables of the data constructor This doesn't allow everything in #2595 (it allows 'g' but not 'f' in the ticket), but it gets a lot closer. Lots of the new lines are comments!
* Spelling error in commentsimonpj@microsoft.com2008-10-191-1/+1
|
* Add ASSERTs to all calls of nameModulesimonpj@microsoft.com2008-10-031-1/+3
| | | | | | nameModule fails on an InternalName. These ASSERTS tell you which call failed.
* Tidy up the treatment of dead binderssimonpj@microsoft.com2008-09-203-19/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch does a lot of tidying up of the way that dead variables are handled in Core. Just the sort of thing to do on an aeroplane. * The tricky "binder-swap" optimisation is moved from the Simplifier to the Occurrence Analyser. See Note [Binder swap] in OccurAnal. This is really a nice change. It should reduce the number of simplifier iteratoins (slightly perhaps). And it means that we can be much less pessimistic about zapping occurrence info on binders in a case expression. * For example: case x of y { (a,b) -> e } Previously, each time around, even if y,a,b were all dead, the Simplifier would pessimistically zap their OccInfo, so that we can't see they are dead any more. As a result virtually no case expression ended up with dead binders. This wasn't Bad in itself, but it always felt wrong. * I added a check to CoreLint to check that a dead binder really isn't used. That showed up a couple of bugs in CSE. (Only in this sense -- they didn't really matter.) * I've changed the PprCore printer to print "_" for a dead variable. (Use -dppr-debug to see it again.) This reduces clutter quite a bit, and of course it's much more useful with the above change. * Another benefit of the binder-swap change is that I could get rid of the Simplifier hack (working, but hacky) in which the InScopeSet was used to map a variable to a *different* variable. That allowed me to remove VarEnv.modifyInScopeSet, and to simplify lookupInScopeSet so that it doesn't look for a fixpoint. This fixes no bugs, but is a useful cleanup. * Roman pointed out that Id.mkWildId is jolly dangerous, because of its fixed unique. So I've - localied it to MkCore, where it is private (not exported) - renamed it to 'mkWildBinder' to stress that you should only use it at binding sites, unless you really know what you are doing - provided a function MkCore.mkWildCase that emodies the most common use of mkWildId, and use that elsewhere So things are much better * A knock-on change is that I found a common pattern of localising a potentially global Id, and made a function for it: Id.localiseId
* Fix Trac #2052 Allowing hpc to understand hsc files.andygill@ku.edu2008-09-161-4/+13
|
* Change desugaring of PArr literalsRoman Leshchinskiy2008-09-121-12/+12
|
* Minor refactoring to get rid of Type.splitNewTyConAppsimonpj@microsoft.com2008-09-151-1/+3
|
* Refactor the desugaring of RULE lhss a bitsimonpj@microsoft.com2008-09-152-33/+34
| | | | | | | | This is just a tidy-up. Previously we were calling occurAnalyse twice on each LHS which was silly and a bit unclean too. This patch should have no overall effect, though.
* Return instead of print warnings and errors in desugarer.Thomas Schilling2008-09-142-34/+37
|
* Major change in compilation of instance declarations (fix Trac #955, #2328)simonpj@microsoft.com2008-09-031-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch makes an important change to the way that dictionary functions are handled. Before, they were unconditionally marked INLIINE, but all the code written by the user in the instance was inside that unconditionally-inlined function. Result: massive code bloat in programs that use complicated instances. This patch make instances behave rather as if all the methods were written in separate definitions. That dramatically reduces bloat. The new plan is described in TcInstDcls Note [How instance declarations are translated] Everything validates. The major code-bloat bug is squashed: in particular DoCon is fine now (Trac #2328) and I believe that #955 is also better. Nofib results: Binary sizes -1 s.d. +2.5% +1 s.d. +3.1% Average +2.8% Allocations -1 s.d. -6.4% +1 s.d. +2.5% Average -2.0% Note that 2% improvement. Some programs improve by 20% (rewrite)! Two get slightly worse: pic (2.1%), and gameteb (3.2%), but all others improve or stay the same. I am not absolutely 100% certain that all the corners are correct; for example, when default methods are marked INLINE, are they inlined? But overall it's better. It's nice that the patch also removes a lot of code. I deleted some out of date comments, but there's something like 100 fewer lines of code in the new version! (In the line counts below, there are a lot of new comments.)
* Fix Trac #2520: duplicate symbolssimonpj@microsoft.com2008-08-271-2/+14
| | | | | | | | | The problem here was that were were quantifying over an *External* Name, which causes no end of confusion. See Note [Const rule dicts] in DsBinds. The fix is very easy, I'm happy to say.