summaryrefslogtreecommitdiff
path: root/compiler/deSugar/DsUtils.hs
Commit message (Collapse)AuthorAgeFilesLines
* Module hierarchy: HsToCore (cf #13009)Sylvain Henry2020-02-141-1001/+0
|
* Use non-empty lists to remove partiality in matching codeJohn Ericson2020-01-071-20/+18
|
* Remove HasSrcSpan (#17494)Vladislav Zavialov2019-11-301-19/+19
| | | | | Metric Decrease: haddock.compiler
* Give seq a more precise type and remove magicBen Gamari2019-11-191-68/+74
| | | | | | | | | | | | | | | | | | | | | `GHC.Prim.seq` previously had the rather plain type: seq :: forall a b. a -> b -> b However, it also had a special typing rule to applications where `b` is not of kind `Type`. Issue #17440 noted that levity polymorphism allows us to rather give it the more precise type: seq :: forall (r :: RuntimeRep) a (b :: TYPE r). a -> b -> b This allows us to remove the special typing rule that we previously required to allow applications on unlifted arguments. T9404 contains a non-Type application of `seq` which should verify that this works as expected. Closes #17440.
* Separate `LPat` from `Pat` on the type-levelSebastian Graf2019-11-021-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since the Trees That Grow effort started, we had `type LPat = Pat`. This is so that `SrcLoc`s would only be annotated in GHC's AST, which is the reason why all GHC passes use the extension constructor `XPat` to attach source locations. See #15495 for the design discussion behind that. But now suddenly there are `XPat`s everywhere! There are several functions which dont't cope with `XPat`s by either crashing (`hsPatType`) or simply returning incorrect results (`collectEvVarsPat`). This issue was raised in #17330. I also came up with a rather clean and type-safe solution to the problem: We define ```haskell type family XRec p (f :: * -> *) = r | r -> p f type instance XRec (GhcPass p) f = Located (f (GhcPass p)) type instance XRec TH f = f p type LPat p = XRec p Pat ``` This is a rather modular embedding of the old "ping-pong" style, while we only pay for the `Located` wrapper within GHC. No ping-ponging in a potential Template Haskell AST, for example. Yet, we miss no case where we should've handled a `SrcLoc`: `hsPatType` and `collectEvVarsPat` are not callable at an `LPat`. Also, this gets rid of one indirection in `Located` variants: Previously, we'd have to go through `XPat` and `Located` to get from `LPat` to the wrapped `Pat`. Now it's just `Located` again. Thus we fix #17330.
* Much simpler language for PmCheckSebastian Graf2019-10-111-2/+2
| | | | | | | | | | | | | | | | Simon realised that the simple language composed of let bindings, bang patterns and flat constructor patterns is enough to capture the semantics of the source pattern language that are important for pattern-match checking. Well, given that the Oracle is smart enough to connect the dots in this less informationally dense form, which it is now. So we transform `translatePat` to return a list of `PmGrd`s relative to an incoming match variable. `pmCheck` then trivially translates each of the `PmGrd`s into constraints that the oracle understands. Since we pass in the match variable, we incidentally fix #15884 (coverage checks for view patterns) through an interaction with !1746.
* Note [Don't flatten tuples from HsSyn] in MkCoreRichard Eisenberg2019-10-031-4/+1
| | | | | | | | | | Previously, we would sometimes flatten 1-tuples and sometimes not. This didn't cause damage because there is no way to generate HsSyn with 1-tuples. But, with the upcoming fix to #16881, there will be. Without this patch, obscure lint errors would have resulted. No test case, as there is not yet a way to tickle this.
* Fix bogus type of case expressionwip/T17056Simon Peyton Jones2019-09-201-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Issue #17056 revealed that we were sometimes building a case expression whose type field (in the Case constructor) was bogus. Consider a phantom type synonym type S a = Int and we want to form the case expression case x of K (a::*) -> (e :: S a) We must not make the type field of the Case constructor be (S a) because 'a' isn't in scope. We must instead expand the synonym. Changes in this patch: * Expand synonyms in the new function CoreUtils.mkSingleAltCase. * Use mkSingleAltCase in MkCore.wrapFloat, which was the proximate source of the bug (when called by exprIsConApp_maybe) * Use mkSingleAltCase elsewhere * Documentation CoreSyn new invariant (6) in Note [Case expression invariants] CoreSyn Note [Why does Case have a 'Type' field?] CoreUtils Note [Care with the type of a case expression] * I improved Core Lint's error reporting, which was pretty confusing in this case, because it didn't mention that the offending type was the return type of a case expression. * A little bit of cosmetic refactoring in CoreUtils
* Module hierarchy: Hs (#13009)Sylvain Henry2019-09-201-2/+2
| | | | | | | Add GHC.Hs module hierarchy replacing hsSyn. Metric Increase: haddock.compiler
* Use an empty data type in TTG extension constructors (#15247)Ryan Scott2019-07-091-3/+3
| | | | | | | | | | | | | | | To avoid having to `panic` any time a TTG extension constructor is consumed, this MR introduces an uninhabited 'NoExtCon' type and uses that in every extension constructor's type family instance where it is appropriate. This also introduces a 'noExtCon' function which eliminates a 'NoExtCon', much like 'Data.Void.absurd' eliminates a 'Void'. I also renamed the existing `NoExt` type to `NoExtField` to better distinguish it from `NoExtCon`. Unsurprisingly, there is a lot of code churn resulting from this. Bumps the Haddock submodule. Fixes #15247.
* Update Trac ticket URLs to point to GitLabRyan Scott2019-03-151-4/+4
| | | | | This moves all URL references to Trac tickets to their corresponding GitLab counterparts.
* Add AnonArgFlag to FunTySimon Peyton Jones2019-02-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The big payload of this patch is: Add an AnonArgFlag to the FunTy constructor of Type, so that (FunTy VisArg t1 t2) means (t1 -> t2) (FunTy InvisArg t1 t2) means (t1 => t2) The big payoff is that we have a simple, local test to make when decomposing a type, leading to many fewer calls to isPredTy. To me the code seems a lot tidier, and probably more efficient (isPredTy has to take the kind of the type). See Note [Function types] in TyCoRep. There are lots of consequences * I made FunTy into a record, so that it'll be easier when we add a linearity field, something that is coming down the road. * Lots of code gets touched in a routine way, simply because it pattern matches on FunTy. * I wanted to make a pattern synonym for (FunTy2 arg res), which picks out just the argument and result type from the record. But alas the pattern-match overlap checker has a heart attack, and either reports false positives, or takes too long. In the end I gave up on pattern synonyms. There's some commented-out code in TyCoRep that shows what I wanted to do. * Much more clarity about predicate types, constraint types and (in particular) equality constraints in kinds. See TyCoRep Note [Types for coercions, predicates, and evidence] and Note [Constraints in kinds]. This made me realise that we need an AnonArgFlag on AnonTCB in a TyConBinder, something that was really plain wrong before. See TyCon Note [AnonTCB InivsArg] * When building function types we must know whether we need VisArg (mkVisFunTy) or InvisArg (mkInvisFunTy). This turned out to be pretty easy in practice. * Pretty-printing of types, esp in IfaceType, gets tidier, because we were already recording the (->) vs (=>) distinction in an ad-hoc way. Death to IfaceFunTy. * mkLamType needs to keep track of whether it is building (t1 -> t2) or (t1 => t2). See Type Note [mkLamType: dictionary arguments] Other minor stuff * Some tidy-up in validity checking involving constraints; Trac #16263
* [TTG: Handling Source Locations] Foundation and PatShayan-Najd2018-11-241-26/+29
| | | | | | | | | | | | | | | | | | This patch removes the ping-pong style from HsPat (only, for now), using the plan laid out at https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/HandlingSourceLocations (solution A). - the class `HasSrcSpan`, and its functions (e.g., `cL` and `dL`), are introduced - some instances of `HasSrcSpan` are introduced - some constructors `L` are replaced with `cL` - some patterns `L` are replaced with `dL->L` view pattern - some type annotation are necessarily updated (e.g., `Pat p` --> `Pat (GhcPass p)`) Phab diff: D5036 Trac Issues #15495 Updates haddock submodule
* Rename literal constructorsSylvain Henry2018-11-221-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | In a previous patch we replaced some built-in literal constructors (MachInt, MachWord, etc.) with a single LitNumber constructor. In this patch we replace the `Mach` prefix of the remaining constructors with `Lit` for consistency (e.g., LitChar, LitLabel, etc.). Sadly the name `LitString` was already taken for a kind of FastString and it would become misleading to have both `LitStr` (literal constructor renamed after `MachStr`) and `LitString` (FastString variant). Hence this patch renames the FastString variant `PtrString` (which is more accurate) and the literal string constructor now uses the least surprising `LitString` name. Both `Literal` and `LitString/PtrString` have recently seen breaking changes so doing this kind of renaming now shouldn't harm much. Reviewers: hvr, goldfire, bgamari, simonmar, jrtc27, tdammers Subscribers: tdammers, rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4881
* Replace most occurences of foldl with foldl'.klebinger.andreas@gmx.at2018-08-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds foldl' to GhcPrelude and changes must occurences of foldl to foldl'. This leads to better performance especially for quick builds where GHC does not perform strictness analysis. It does change strictness behaviour when we use foldl' to turn a argument list into function applications. But this is only a drawback if code looks ONLY at the last argument but not at the first. And as the benchmarks show leads to fewer allocations in practice at O2. Compiler performance for Nofib: O2 Allocations: -1 s.d. ----- -0.0% +1 s.d. ----- -0.0% Average ----- -0.0% O2 Compile Time: -1 s.d. ----- -2.8% +1 s.d. ----- +1.3% Average ----- -0.8% O0 Allocations: -1 s.d. ----- -0.2% +1 s.d. ----- -0.1% Average ----- -0.2% Test Plan: ci Reviewers: goldfire, bgamari, simonmar, tdammers, monoidal Reviewed By: bgamari, monoidal Subscribers: tdammers, rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4929
* Fix #15385 by using addDictsDs in matchGuardsRyan Scott2018-07-301-1/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When coverage checking pattern-matches, we rely on the call sites in the desugarer to populate the local dictionaries and term evidence in scope using `addDictsDs` and `addTmCsDs`. But it turns out that only the call site for desugaring `case` expressions was actually doing this properly. In another part of the desugarer, `matchGuards` (which handles pattern guards), it did not update the local dictionaries in scope at all, leading to #15385. Fixing this is relatively straightforward: just augment the `BindStmt` case of `matchGuards` to use `addDictsDs` and `addTmCsDs`. Accomplishing this took a little bit of import/export tweaking: * We now need to export `collectEvVarsPat` from `HsPat.hs`. * To avoid an import cycle with `Check.hs`, I moved `isTrueLHsExpr` from `DsGRHSs.hs` to `DsUtils.hs`, which resides lower on the import chain. Test Plan: make test TEST=T15385 Reviewers: simonpj, bgamari Reviewed By: simonpj Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15385 Differential Revision: https://phabricator.haskell.org/D4968
* Small refactor in desugar of pattern matchingSimon Peyton Jones2018-07-271-9/+37
| | | | | | | | | | | | | | | | In reviewing Phab:D4968 for Trac #15385 I saw a small but simple refactor to avoid unnecessary work in the desugarer. This patch just arranges to call matchSinglePatVar v ... rather than matchSinglePat (Var v) ... The more specialised function already existed, as match_single_pat_var I also added more comments about decideBangHood
* vectorise: Put it out of its miseryBen Gamari2018-06-021-76/+2
| | | | | | | | | | | | | | | | | | | | | Poor DPH and its vectoriser have long been languishing; sadly it seems there is little chance that the effort will be rekindled. Every few years we discuss what to do with this mass of code and at least once we have agreed that it should be archived on a branch and removed from `master`. Here we do just that, eliminating heaps of dead code in the process. Here we drop the ParallelArrays extension, the vectoriser, and the `vector` and `primitive` submodules. Test Plan: Validate Reviewers: simonpj, simonmar, hvr, goldfire, alanz Reviewed By: simonmar Subscribers: goldfire, rwbarton, thomie, mpickering, carter Differential Revision: https://phabricator.haskell.org/D4761
* Restore Trees That Grow reverted commitsAlan Zimmerman2018-04-091-30/+33
| | | | | | | | | | | | | | | | | | The following commits were reverted prior to the release of GHC 8.4.1, because the time to derive Data instances was too long [1]. 438dd1cbba13d35f3452b4dcef3f94ce9a216905 Phab:D4147 e3ec2e7ae94524ebd111963faf34b84d942265b4 Phab:D4177 47ad6578ea460999b53eb4293c3a3b3017a56d65 Phab:D4186 The work is continuing, as the minimum bootstrap compiler is now GHC 8.2.1, and this allows Plan B[2] for instances to be used. This will land in a following commit. Updates Haddock submodule [1] https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/Instances [2] https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/Instances#PLANB
* Kill off irrefutable pattern errorsDavid Feuer2018-01-151-1/+1
| | | | | | | | | | | | | | | | | Distinguishing between "refutable" and "irrefutable" patterns (as described by the Haskell Report) in incomplete pattern errors was more confusing than helpful. Remove references to irrefutable patterns. Reviewers: hvr, bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie, carter GHC Trac Issues: #14569 Differential Revision: https://phabricator.haskell.org/D4261
* Revert "trees that grow" workBen Gamari2017-11-211-33/+30
| | | | | | | | | | | | | | As documented in #14490, the Data instances currently blow up compilation time by too much to stomach. Alan will continue working on this in a branch and we will perhaps merge to 8.2 before 8.2.1 to avoid having to perform painful cherry-picks in 8.2 minor releases. Reverts haddock submodule. This reverts commit 47ad6578ea460999b53eb4293c3a3b3017a56d65. This reverts commit e3ec2e7ae94524ebd111963faf34b84d942265b4. This reverts commit 438dd1cbba13d35f3452b4dcef3f94ce9a216905. This reverts commit 0ff152c9e633accca48815e26e59d1af1fe44ceb.
* WIP on Doing a combined Step 1 and 3 for Trees That GrowAlan Zimmerman2017-11-081-30/+33
| | | | | | | | | | | | | | | | | | | | | | | | | See https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow Trees that grow extension points are added for - ValBinds - HsPat - HsLit - HsOverLit - HsType - HsTyVarBndr - HsAppType - FieldOcc - AmbiguousFieldOcc Updates haddock submodule Test Plan: ./validate Reviewers: shayan-najd, simonpj, austin, goldfire, bgamari Subscribers: goldfire, rwbarton, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D4147
* Revert "WIP on combining Step 1 and 3 of Trees That Grow"Ben Gamari2017-11-071-33/+30
| | | | | | | | This reverts commit 0ff152c9e633accca48815e26e59d1af1fe44ceb. Sadly this broke when bootstrapping with 8.0.2 due to #14396. Reverts haddock submodule.
* WIP on combining Step 1 and 3 of Trees That GrowAlan Zimmerman2017-11-071-30/+33
| | | | | | | | | | | | | | | | | | | | | | | | | See https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow Trees that grow extension points are added for - ValBinds - HsPat - HsLit - HsOverLit - HsType - HsTyVarBndr - HsAppType - FieldOcc - AmbiguousFieldOcc Updates haddock submodule Test Plan: ./validate Reviewers: shayan-najd, simonpj, austin, goldfire, bgamari Subscribers: goldfire, rwbarton, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D4147
* compiler: introduce custom "GhcPrelude" PreludeHerbert Valerio Riedel2017-09-191-0/+2
| | | | | | | | | | | | | | | | | | This switches the compiler/ component to get compiled with -XNoImplicitPrelude and a `import GhcPrelude` is inserted in all modules. This is motivated by the upcoming "Prelude" re-export of `Semigroup((<>))` which would cause lots of name clashes in every modulewhich imports also `Outputable` Reviewers: austin, goldfire, bgamari, alanz, simonmar Reviewed By: bgamari Subscribers: goldfire, rwbarton, thomie, mpickering, bgamari Differential Revision: https://phabricator.haskell.org/D3989
* Small refactor of getRuntimeRepSimon Peyton Jones2017-08-291-2/+2
| | | | | | | | | Instead of using a string argument, use HasDebugCallStack. (Oddly, some functions were using both!) Plus, use getRuntimeRep rather than getRuntimeRep_maybe when if the caller panics on Nothing. Less code, and a better debug stack.
* Treat banged bindings as FunBindsBen Gamari2017-06-271-1/+13
| | | | | | | | | | | | | | | This is another attempt at resolving #13594 by treating strict variable binds as FunBinds instead of PatBinds (as suggested in comment:1). Test Plan: Validate Reviewers: austin, alanz Subscribers: rwbarton, thomie, mpickering GHC Trac Issues: #13594 Differential Revision: https://phabricator.haskell.org/D3670
* Udate hsSyn AST to use Trees that GrowAlan Zimmerman2017-06-061-14/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: See https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow This commit prepares the ground for a full extensible AST, by replacing the type parameter for the hsSyn data types with a set of indices into type families, data GhcPs -- ^ Index for GHC parser output data GhcRn -- ^ Index for GHC renamer output data GhcTc -- ^ Index for GHC typechecker output These are now used instead of `RdrName`, `Name` and `Id`/`TcId`/`Var` Where the original name type is required in a polymorphic context, this is accessible via the IdP type family, defined as type family IdP p type instance IdP GhcPs = RdrName type instance IdP GhcRn = Name type instance IdP GhcTc = Id These types are declared in the new 'hsSyn/HsExtension.hs' module. To gain a better understanding of the extension mechanism, it has been applied to `HsLit` only, also replacing the `SourceText` fields in them with extension types. To preserve extension generality, a type class is introduced to capture the `SourceText` interface, which must be honoured by all of the extension points which originally had a `SourceText`. The class is defined as class HasSourceText a where -- Provide setters to mimic existing constructors noSourceText :: a sourceText :: String -> a setSourceText :: SourceText -> a getSourceText :: a -> SourceText And the constraint is captured in `SourceTextX`, which is a constraint type listing all the extension points that make use of the class. Updating Haddock submodule to match. Test Plan: ./validate Reviewers: simonpj, shayan-najd, goldfire, austin, bgamari Subscribers: rwbarton, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D3609
* Fix #12709 by not building bad applicationsRichard Eisenberg2017-03-171-0/+2
| | | | | | | | | | | In an effort to report multiple levity polymorphism errors all at once, the desugarer does not fail when encountering bad levity polymorphism. But we must be careful not to build the bad applications, lest they try to satisfy the let/app invariant and call isUnliftedType on a levity polymorphic type. This protects calls to mkCoreAppDs appropriately. test case: typecheck/should_fail/T12709
* Join pointsLuke Maurer2017-02-011-0/+14
| | | | | | | | | | | | | | | | | | | This major patch implements Join Points, as described in https://ghc.haskell.org/trac/ghc/wiki/SequentCore. You have to read that page, and especially the paper it links to, to understand what's going on; but it is very cool. It's Luke Maurer's work, but done in close collaboration with Simon PJ. This Phab is a squash-merge of wip/join-points branch of http://github.com/lukemaurer/ghc. There are many, many interdependent changes. Reviewers: goldfire, mpickering, bgamari, simonmar, dfeuer, austin Subscribers: simonpj, dfeuer, mpickering, Mikolaj, thomie Differential Revision: https://phabricator.haskell.org/D2853
* Update levity polymorphismRichard Eisenberg2017-01-191-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit implements the proposal in https://github.com/ghc-proposals/ghc-proposals/pull/29 and https://github.com/ghc-proposals/ghc-proposals/pull/35. Here are some of the pieces of that proposal: * Some of RuntimeRep's constructors have been shortened. * TupleRep and SumRep are now parameterized over a list of RuntimeReps. * This means that two types with the same kind surely have the same representation. Previously, all unboxed tuples had the same kind, and thus the fact above was false. * RepType.typePrimRep and friends now return a *list* of PrimReps. These functions can now work successfully on unboxed tuples. This change is necessary because we allow abstraction over unboxed tuple types and so cannot always handle unboxed tuples specially as we did before. * We sometimes have to create an Id from a PrimRep. I thus split PtrRep * into LiftedRep and UnliftedRep, so that the created Ids have the right strictness. * The RepType.RepType type was removed, as it didn't seem to help with * much. * The RepType.repType function is also removed, in favor of typePrimRep. * I have waffled a good deal on whether or not to keep VoidRep in TyCon.PrimRep. In the end, I decided to keep it there. PrimRep is *not* represented in RuntimeRep, and typePrimRep will never return a list including VoidRep. But it's handy to have in, e.g., ByteCodeGen and friends. I can imagine another design choice where we have a PrimRepV type that is PrimRep with an extra constructor. That seemed to be a heavier design, though, and I'm not sure what the benefit would be. * The last, unused vestiges of # (unliftedTypeKind) have been removed. * There were several pretty-printing bugs that this change exposed; * these are fixed. * We previously checked for levity polymorphism in the types of binders. * But we also must exclude levity polymorphism in function arguments. This is hard to check for, requiring a good deal of care in the desugarer. See Note [Levity polymorphism checking] in DsMonad. * In order to efficiently check for levity polymorphism in functions, it * was necessary to add a new bit of IdInfo. See Note [Levity info] in IdInfo. * It is now safe for unlifted types to be unsaturated in Core. Core Lint * is updated accordingly. * We can only know strictness after zonking, so several checks around * strictness in the type-checker (checkStrictBinds, the check for unlifted variables under a ~ pattern) have been moved to the desugarer. * Along the way, I improved the treatment of unlifted vs. banged * bindings. See Note [Strict binds checks] in DsBinds and #13075. * Now that we print type-checked source, we must be careful to print * ConLikes correctly. This is facilitated by a new HsConLikeOut constructor to HsExpr. Particularly troublesome are unlifted pattern synonyms that get an extra void# argument. * Includes a submodule update for haddock, getting rid of #. * New testcases: typecheck/should_fail/StrictBinds typecheck/should_fail/T12973 typecheck/should_run/StrictPats typecheck/should_run/T12809 typecheck/should_fail/T13105 patsyn/should_fail/UnliftedPSBind typecheck/should_fail/LevPolyBounded typecheck/should_compile/T12987 typecheck/should_compile/T11736 * Fixed tickets: #12809 #12973 #11736 #13075 #12987 * This also adds a test case for #13105. This test case is * "compile_fail" and succeeds, because I want the testsuite to monitor the error message. When #13105 is fixed, the test case will compile cleanly.
* Ensure nested binders have Internal NamesSimon Peyton Jones2017-01-051-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | This is a long-standing bug. A nested (non-top-level) binder in Core should not have an External Name, like M.x. But - Lint was not checking this invariant - The desugarer could generate programs that failed the invariant. An example is in tests/deSugar/should_compile/T13043, which had let !_ = M.scState in ... This desugared to let ds = case M.scSate of M.scState { DEFAULT -> () } in case ds of () -> ... We were wrongly re-using that scrutinee as a case binder. And Trac #13043 showed that could ultimately lead to two top-level bindings with the same closure name. Alas! - The desugarer had one other place (in DsUtils.mkCoreAppDs) that could generate bogus code This patch fixes all three bugs, and adds a regression test.
* Fix desugaring of pattern bindings (again)Simon Peyton Jones2016-09-301-55/+81
| | | | | | | | | | | | | | | | | | | This patch fixes Trac #12595. The problem was with a pattern binding like !x = e For a start it's silly to match that pattern and build a unit tuple (the General Case of mkSelectorBinds); but that's what was happening because the bang fell through to the general case. But for a variable pattern building any auxiliary bindings is stupid. So the patch introduces a new case in mkSelectorBinds for variable patterns. Then it turned out that if 'e' was a plain variable, and moreover was imported GlobalId, then matchSinglePat made it a /bound/ variable, which should never happen. That ultimately caused a linker error, but the original bug was much earlier.
* Fix and refactor strict pattern bindingsSimon Peyton Jones2016-02-261-122/+186
| | | | | | | | | | | | | | | | | | | | | | This patch was triggered by Trac #11601, where I discovered that -XStrict was really not doing the right thing. In particular, f y = let !(Just x) = blah[y] in body[y,x] This was evaluating 'blah' but not pattern matching it against Just until x was demanded. This is wrong. The patch implements a new semantics which ensures that strict patterns (i.e. ones with an explicit bang, or with -XStrict) are evaluated fully when bound. * There are extensive notes in DsUtils: Note [mkSelectorBinds] * To do this I found I need one-tuples; see Note [One-tuples] in TysWiredIn I updated the user manual to give the new semantics
* Address #11471 by putting RuntimeRep in kinds.wip/runtime-repRichard Eisenberg2016-02-241-2/+2
| | | | | | | | | | | | | | | | | | | | | See Note [TYPE] in TysPrim. There are still some outstanding pieces in #11471 though, so this doesn't actually nail the bug. This commit also contains a few performance improvements: * Short-cut equality checking of nullary type syns * Compare types before kinds in eqType * INLINE coreViewOneStarKind * Store tycon binders separately from kinds. This resulted in a ~10% performance improvement in compiling the Cabal package. No change in functionality other than performance. (This affects the interface file format, though.) This commit updates the haddock submodule.
* Fix desugaring of bang-pattern let-bindingsSimon Peyton Jones2016-02-181-26/+23
| | | | | | | | | | | | | When implementing Strict Haskell, the patch 46a03fbe didn't faithfully implement the semantics given in the manual. In particular there was an ad-hoc case in mkSelectorBinds for "strict and no binders" that didn't work. This patch fixes it, curing Trac #11572. Howver it forced me to think about banged let-bindings, and I rather think we do not have quite the right semantics yet, so I've opened Trac #11601.
* Another batch of typo fixes in non-codeGabor Greif2016-02-111-1/+1
|
* Refactor the typechecker to use ExpTypes.Richard Eisenberg2016-01-271-5/+5
| | | | | | | | | | | | | | | | | | | | | The idea here is described in [wiki:Typechecker]. Briefly, this refactor keeps solid track of "synthesis" mode vs "checking" in GHC's bidirectional type-checking algorithm. When in synthesis mode, the expected type is just an IORef to write to. In addition, this patch does a significant reworking of RebindableSyntax, allowing much more freedom in the types of the rebindable operators. For example, we can now have `negate :: Int -> Bool` and `(>>=) :: m a -> (forall x. a x -> m b) -> m b`. The magic is in tcSyntaxOp. This addresses tickets #11397, #11452, and #11458. Tests: typecheck/should_compile/{RebindHR,RebindNegate,T11397,T11458} th/T11452
* Expose enabled language extensions to THBen Gamari2015-12-151-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This exposes `template-haskell` functions for querying the language extensions which are enabled when compiling a module, - an `isExtEnabled` function to check whether an extension is enabled - an `extsEnabled` function to obtain a full list of enabled extensions To avoid code duplication this adds a `GHC.LanguageExtensions` module to `ghc-boot` and moves `DynFlags.ExtensionFlag` into it. A happy consequence of this is that the ungainly `DynFlags` lost around 500 lines. Moreover, flags corresponding to language extensions are now clearly distinguished from other flags due to the `LangExt.*` prefix. Updates haddock submodule. This fixes #10820. Test Plan: validate Reviewers: austin, spinda, hvr, goldfire, alanz Reviewed By: goldfire Subscribers: mpickering, RyanGlScott, hvr, simonpj, thomie Differential Revision: https://phabricator.haskell.org/D1200 GHC Trac Issues: #10820
* Comment layout onlySimon Peyton Jones2015-12-151-5/+5
|
* Add kind equalities to GHC.Richard Eisenberg2015-12-111-10/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This implements the ideas originally put forward in "System FC with Explicit Kind Equality" (ICFP'13). There are several noteworthy changes with this patch: * We now have casts in types. These change the kind of a type. See new constructor `CastTy`. * All types and all constructors can be promoted. This includes GADT constructors. GADT pattern matches take place in type family equations. In Core, types can now be applied to coercions via the `CoercionTy` constructor. * Coercions can now be heterogeneous, relating types of different kinds. A coercion proving `t1 :: k1 ~ t2 :: k2` proves both that `t1` and `t2` are the same and also that `k1` and `k2` are the same. * The `Coercion` type has been significantly enhanced. The documentation in `docs/core-spec/core-spec.pdf` reflects the new reality. * The type of `*` is now `*`. No more `BOX`. * Users can write explicit kind variables in their code, anywhere they can write type variables. For backward compatibility, automatic inference of kind-variable binding is still permitted. * The new extension `TypeInType` turns on the new user-facing features. * Type families and synonyms are now promoted to kinds. This causes trouble with parsing `*`, leading to the somewhat awkward new `HsAppsTy` constructor for `HsType`. This is dispatched with in the renamer, where the kind `*` can be told apart from a type-level multiplication operator. Without `-XTypeInType` the old behavior persists. With `-XTypeInType`, you need to import `Data.Kind` to get `*`, also known as `Type`. * The kind-checking algorithms in TcHsType have been significantly rewritten to allow for enhanced kinds. * The new features are still quite experimental and may be in flux. * TODO: Several open tickets: #11195, #11196, #11197, #11198, #11203. * TODO: Update user manual. Tickets addressed: #9017, #9173, #7961, #10524, #8566, #11142. Updates Haddock submodule.
* ApiAnnotations: Make all RdrName occurences LocatedAlan Zimmerman2015-11-231-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At the moment the API Annotations can only be used on the ParsedSource, as there are changes made to the RenamedSource that prevent it from being used to round trip source code. It is possible to build a map from every Located Name in the RenamedSource from its location to the Name, which can then be used when resolved names are required when changing the ParsedSource. However, there are instances where the identifier is not located, specifically (GHC.VarPat name) (GHC.HsVar name) (GHC.UserTyVar name) (GHC.HsTyVar name) Replace each of the name types above with (Located name) Updates the haddock submodule. Test Plan: ./validate Reviewers: austin, goldfire, bgamari Reviewed By: bgamari Subscribers: goldfire, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D1512 GHC Trac Issues: #11019
* Fix inconsistent pretty-printing of type familiesMichał Sośnicki2015-11-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | After the changes, the three functions used to print type families were identical, so they are refactored into one. Original RHSs of data instance declarations are recreated and printed in user error messages. RHSs containing representation TyCons are printed in the Coercion Axioms section in a typechecker dump. Add vbar to the list of SDocs exported by Outputable. Replace all text "|" docs with it. Fixes #10839 Reviewers: goldfire, jstolarek, austin, bgamari Reviewed By: jstolarek Subscribers: jstolarek, thomie Differential Revision: https://phabricator.haskell.org/D1441 GHC Trac Issues: #10839
* Implement the Strict language extensionAdam Sandberg Eriksson2015-11-141-21/+65
| | | | | | | | | | | | | | | | | | | | | Add a new language extension `-XStrict` which turns all bindings strict as if the programmer had written a `!` before it. This also upgrades ordinary Haskell to allow recursive and polymorphic strict bindings. See the wiki[1] and the Note [Desugar Strict binds] in DsBinds for specification and implementation details. [1] https://ghc.haskell.org/trac/ghc/wiki/StrictPragma Reviewers: austin, tibbe, simonpj, bgamari Reviewed By: tibbe, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1142 GHC Trac Issues: #8347
* Generate Typeable info at definition sitesBen Gamari2015-10-301-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the second attempt at merging D757. This patch implements the idea floated in Trac #9858, namely that we should generate type-representation information at the data type declaration site, rather than when solving a Typeable constraint. However, this turned out quite a bit harder than I expected. I still think it's the right thing to do, and it's done now, but it was quite a struggle. See particularly * Note [Grand plan for Typeable] in TcTypeable (which is a new module) * Note [The overall promotion story] in DataCon (clarifies existing stuff) The most painful bit was that to generate Typeable instances (ie TyConRepName bindings) for every TyCon is tricky for types in ghc-prim etc: * We need to have enough data types around to *define* a TyCon * Many of these types are wired-in Also, to minimise the code generated for each data type, I wanted to generate pure data, not CAFs with unpackCString# stuff floating about. Performance ~~~~~~~~~~~ Three perf/compiler tests start to allocate quite a bit more. This isn't surprising, because they all allocate zillions of data types, with practically no other code, esp. T1969 * T1969: GHC allocates 19% more * T4801: GHC allocates 13% more * T5321FD: GHC allocates 13% more * T9675: GHC allocates 11% more * T783: GHC allocates 11% more * T5642: GHC allocates 10% more I'm treating this as acceptable. The payoff comes in Typeable-heavy code. Remaining to do ~~~~~~~~~~~~~~~ * I think that "TyCon" and "Module" are over-generic names to use for the runtime type representations used in GHC.Typeable. Better might be "TrTyCon" and "TrModule". But I have not yet done this * Add more info the the "TyCon" e.g. source location where it was defined * Use the new "Module" type to help with Trac Trac #10068 * It would be possible to generate TyConRepName (ie Typeable instances) selectively rather than all the time. We'd need to persist the information in interface files. Lacking a motivating reason I have not done this, but it would not be difficult. Refactoring ~~~~~~~~~~~ As is so often the case, I ended up refactoring more than I intended. In particular * In TyCon, a type *family* (whether type or data) is repesented by a FamilyTyCon * a algebraic data type (including data/newtype instances) is represented by AlgTyCon This wasn't true before; a data family was represented as an AlgTyCon. There are some corresponding changes in IfaceSyn. * Also get rid of the (unhelpfully named) tyConParent. * In TyCon define 'Promoted', isomorphic to Maybe, used when things are optionally promoted; and use it elsewhere in GHC. * Cleanup handling of knownKeyNames * Each TyCon, including promoted TyCons, contains its TyConRepName, if it has one. This is, in effect, the name of its Typeable instance. Updates haddock submodule Test Plan: Let Harbormaster validate Reviewers: austin, hvr, goldfire Subscribers: goldfire, thomie Differential Revision: https://phabricator.haskell.org/D1404 GHC Trac Issues: #9858
* Revert "Generate Typeable info at definition sites"Ben Gamari2015-10-291-7/+7
| | | | | | | | This reverts commit bef2f03e4d56d88a7e9752a7afd6a0a35616da6c. This merge was botched Also reverts haddock submodule.
* Generate Typeable info at definition sitesBen Gamari2015-10-291-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements the idea floated in Trac #9858, namely that we should generate type-representation information at the data type declaration site, rather than when solving a Typeable constraint. However, this turned out quite a bit harder than I expected. I still think it's the right thing to do, and it's done now, but it was quite a struggle. See particularly * Note [Grand plan for Typeable] in TcTypeable (which is a new module) * Note [The overall promotion story] in DataCon (clarifies existing stuff) The most painful bit was that to generate Typeable instances (ie TyConRepName bindings) for every TyCon is tricky for types in ghc-prim etc: * We need to have enough data types around to *define* a TyCon * Many of these types are wired-in Also, to minimise the code generated for each data type, I wanted to generate pure data, not CAFs with unpackCString# stuff floating about. Performance ~~~~~~~~~~~ Three perf/compiler tests start to allocate quite a bit more. This isn't surprising, because they all allocate zillions of data types, with practically no other code, esp. T1969 * T3294: GHC allocates 110% more (filed #11030 to track this) * T1969: GHC allocates 30% more * T4801: GHC allocates 14% more * T5321FD: GHC allocates 13% more * T783: GHC allocates 12% more * T9675: GHC allocates 12% more * T5642: GHC allocates 10% more * T9961: GHC allocates 6% more * T9203: Program allocates 54% less I'm treating this as acceptable. The payoff comes in Typeable-heavy code. Remaining to do ~~~~~~~~~~~~~~~ * I think that "TyCon" and "Module" are over-generic names to use for the runtime type representations used in GHC.Typeable. Better might be "TrTyCon" and "TrModule". But I have not yet done this * Add more info the the "TyCon" e.g. source location where it was defined * Use the new "Module" type to help with Trac Trac #10068 * It would be possible to generate TyConRepName (ie Typeable instances) selectively rather than all the time. We'd need to persist the information in interface files. Lacking a motivating reason I have not done this, but it would not be difficult. Refactoring ~~~~~~~~~~~ As is so often the case, I ended up refactoring more than I intended. In particular * In TyCon, a type *family* (whether type or data) is repesented by a FamilyTyCon * a algebraic data type (including data/newtype instances) is represented by AlgTyCon This wasn't true before; a data family was represented as an AlgTyCon. There are some corresponding changes in IfaceSyn. * Also get rid of the (unhelpfully named) tyConParent. * In TyCon define 'Promoted', isomorphic to Maybe, used when things are optionally promoted; and use it elsewhere in GHC. * Cleanup handling of knownKeyNames * Each TyCon, including promoted TyCons, contains its TyConRepName, if it has one. This is, in effect, the name of its Typeable instance. Requires update of the haddock submodule. Differential Revision: https://phabricator.haskell.org/D757
* ApplicativeDo transformationSimon Marlow2015-09-171-9/+9
| | | | | | | | | | | | | | | | Summary: This is an implementation of the ApplicativeDo proposal. See the Note [ApplicativeDo] in RnExpr for details on the current implementation, and the wiki page https://ghc.haskell.org/trac/ghc/wiki/ApplicativeDo for design notes. Test Plan: validate Reviewers: simonpj, goldfire, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D729
* Define DsUtils.mkCastDs and use itSimon Peyton Jones2015-07-301-4/+23
| | | | | | | This change avoids a spurious WARNing from mkCast. In the output of the desugarer (only, I think) we can have a cast where the type of the expression and cast don't syntactically match, because of an enclosing type-let binding.
* Generalized Coverage pass to allow adding multiple types of TickishsPeter Wortmann2014-12-161-5/+4
| | | | | | | | This allows having, say, HPC ticks, automatic cost centres and source notes active at the same time. We especially take care to un-tangle the infrastructure involved in generating them. (From Phabricator D169)
View Lorry Controller Status