summaryrefslogtreecommitdiff
path: root/compiler/deSugar/DsExpr.hs
Commit message (Collapse)AuthorAgeFilesLines
* Module hierarchy: HsToCore (cf #13009)Sylvain Henry2020-02-141-1201/+0
|
* Always display inferred variables using bracesKrzysztof Gogolewski2020-02-121-97/+100
| | | | | | | | | | | | | We now always show "forall {a}. T" for inferred variables, previously this was controlled by -fprint-explicit-foralls. This implements part 1 of https://github.com/ghc-proposals/ghc-proposals/pull/179. Part of GHC ticket #16320. Furthermore, when printing a levity restriction error, we now display the HsWrap of the expression. This lets users see the full elaboration with -fprint-typechecker-elaboration (see also #17670)
* Fix long distance info for record updatesSebastian Graf2020-02-101-1/+19
| | | | | | | | | | | | | | | | | | For record updates where the `record_expr` is a variable, as in #17783: ```hs data PartialRec = No | Yes { a :: Int, b :: Bool } update No = No update r@(Yes {}) = r { b = False } ``` We should make use of long distance info in `-Wincomplete-record-updates` checking. But the call to `matchWrapper` in the `RecUpd` case didn't specify a scrutinee expression, which would correspond to the `record_expr` `r` here. That is fixed now. Fixes #17783.
* Introduce IsPass; refactor wrappers.Richard Eisenberg2020-02-081-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are two main payloads of this patch: 1. This introduces IsPass, which allows e.g. printing code to ask what pass it is running in (Renamed vs Typechecked) and thus print extension fields. See Note [IsPass] in Hs.Extension 2. This moves the HsWrap constructor into an extension field, where it rightly belongs. This is done for HsExpr and HsCmd, but not for HsPat, which is left as an exercise for the reader. There is also some refactoring around SyntaxExprs, but this is really just incidental. This patch subsumes !1721 (sorry @chreekat). Along the way, there is a bit of refactoring in GHC.Hs.Extension, including the removal of NameOrRdrName in favor of NoGhcTc. This meant that we had no real need for GHC.Hs.PlaceHolder, so I got rid of it. Updates haddock submodule. ------------------------- Metric Decrease: haddock.compiler -------------------------
* Disable two warnings for files that trigger themTom Ellis2020-01-271-0/+3
| | | | | | incomplete-uni-patterns and incomplete-record-updates will be in -Wall at a future date, so prepare for that by disabling those warnings on files that trigger them.
* Fix more typos, via an improved Levenshtein-style correctorBrian Wignall2020-01-121-1/+1
|
* Overloaded Quotation Brackets (#246)Matthew Pickering2020-01-121-1/+1
| | | | | | | | | | | | | | | | | | This patch implements overloaded quotation brackets which generalise the desugaring of all quotation forms in terms of a new minimal interface. The main change is that a quotation, for example, [e| 5 |], will now have type `Quote m => m Exp` rather than `Q Exp`. The `Quote` typeclass contains a single method for generating new names which is used when desugaring binding structures. The return type of functions from the `Lift` type class, `lift` and `liftTyped` have been restricted to `forall m . Quote m => m Exp` rather than returning a result in a Q monad. More details about the feature can be read in the GHC proposal. https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0246-overloaded-bracket.rst
* Deduplicate copied monad failure handler codeJohn Ericson2019-12-201-5/+6
|
* Remove HasSrcSpan (#17494)Vladislav Zavialov2019-11-301-27/+27
| | | | | Metric Decrease: haddock.compiler
* Factor out HsSCC/HsCoreAnn/HsTickPragma into HsPragEwip/hs-pragVladislav Zavialov2019-11-281-20/+22
| | | | | | | | | | | | | | | | | | | | | | | This is a refactoring with no user-visible changes (except for GHC API users). Consider the HsExpr constructors that correspond to user-written pragmas: HsSCC representing {-# SCC ... #-} HsCoreAnn representing {-# CORE ... #-} HsTickPragma representing {-# GENERATED ... #-} We can factor them out into a separate datatype, HsPragE. It makes the code a bit tidier, especially in the parser. Before this patch: hpc_annot :: { Located ( (([AddAnn],SourceText),(StringLiteral,(Int,Int),(Int,Int))), ((SourceText,SourceText),(SourceText,SourceText)) ) } After this patch: prag_hpc :: { Located ([AddAnn], HsPragE GhcPs) }
* Ensure that coreView/tcView are able to inlineBen Gamari2019-11-131-0/+1
| | | | | | | | | | | | | | | | | | | | Previously an import cycle between Type and TyCoRep meant that several functions in TyCoRep ended up SOURCE import coreView. This is quite unfortunate as coreView is intended to be fused into a larger pattern match and not incur an extra call. Fix this with a bit of restructuring: * Move the functions in `TyCoRep` which depend upon things in `Type` into `Type` * Fold contents of `Kind` into `Type` and turn `Kind` into a simple wrapper re-exporting kind-ish things from `Type` * Clean up the redundant imports that popped up as a result Closes #17441. Metric Decrease: T4334
* Fix #15344: use fail when desugaring applicative-doJosef Svenningsson2019-10-281-13/+13
| | | | | | | | | | | | | | | | Applicative-do has a bug where it fails to use the monadic fail method when desugaring patternmatches which can fail. See #15344. This patch fixes that problem. It required more rewiring than I had expected. Applicative-do happens mostly in the renamer; that's where decisions about scheduling are made. This schedule is then carried through the typechecker and into the desugarer which performs the actual translation. Fixing this bug required sending information about the fail method from the renamer, through the type checker and into the desugarer. Previously, the desugarer didn't have enough information to actually desugar pattern matches correctly. As a side effect, we also fix #16628, where GHC wouldn't catch missing MonadFail instances with -XApplicativeDo.
* Much simpler language for PmCheckSebastian Graf2019-10-111-1/+1
| | | | | | | | | | | | | | | | 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-0/+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.
* Move pattern match checker modules to GHC.HsToCore.PmCheckSebastian Graf2019-09-301-1/+1
|
* Module hierarchy: Hs (#13009)Sylvain Henry2019-09-201-1/+1
| | | | | | | Add GHC.Hs module hierarchy replacing hsSyn. Metric Increase: haddock.compiler
* Remove Bag fold specialisations (#16969)Richard Lupton2019-08-191-1/+1
|
* Use an empty data type in TTG extension constructors (#15247)Ryan Scott2019-07-091-9/+9
| | | | | | | | | | | | | | | 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.
* Implement the -XUnliftedNewtypes extension.Andrew Martin2019-06-141-5/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | GHC Proposal: 0013-unlifted-newtypes.rst Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/98 Issues: #15219, #1311, #13595, #15883 Implementation Details: Note [Implementation of UnliftedNewtypes] Note [Unifying data family kinds] Note [Compulsory newtype unfolding] This patch introduces the -XUnliftedNewtypes extension. When this extension is enabled, GHC drops the restriction that the field in a newtype must be of kind (TYPE 'LiftedRep). This allows types like Int# and ByteArray# to be used in a newtype. Additionally, coerce is made levity-polymorphic so that it can be used with newtypes over unlifted types. The bulk of the changes are in TcTyClsDecls.hs. With -XUnliftedNewtypes, getInitialKind is more liberal, introducing a unification variable to return the kind (TYPE r0) rather than just returning (TYPE 'LiftedRep). When kind-checking a data constructor with kcConDecl, we attempt to unify the kind of a newtype with the kind of its field's type. When typechecking a data declaration with tcTyClDecl, we again perform a unification. See the implementation note for more on this. Co-authored-by: Richard Eisenberg <rae@richarde.dev>
* Pattern/expression ambiguity resolutionVladislav Zavialov2019-05-031-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch removes 'EWildPat', 'EAsPat', 'EViewPat', and 'ELazyPat' from 'HsExpr' by using the ambiguity resolution system introduced earlier for the command/expression ambiguity. Problem: there are places in the grammar where we do not know whether we are parsing an expression or a pattern, for example: do { Con a b <- x } -- 'Con a b' is a pattern do { Con a b } -- 'Con a b' is an expression Until we encounter binding syntax (<-) we don't know whether to parse 'Con a b' as an expression or a pattern. The old solution was to parse as HsExpr always, and rejig later: checkPattern :: LHsExpr GhcPs -> P (LPat GhcPs) This meant polluting 'HsExpr' with pattern-related constructors. In other words, limitations of the parser were affecting the AST, and all other code (the renamer, the typechecker) had to deal with these extra constructors. We fix this abstraction leak by parsing into an overloaded representation: class DisambECP b where ... newtype ECP = ECP { runECP_PV :: forall b. DisambECP b => PV (Located b) } See Note [Ambiguous syntactic categories] for details. Now the intricacies of parsing have no effect on the hsSyn AST when it comes to the expression/pattern ambiguity.
* Update Trac ticket URLs to point to GitLabRyan Scott2019-03-151-2/+2
| | | | | This moves all URL references to Trac tickets to their corresponding GitLab counterparts.
* Expression/command ambiguity resolutionVladislav Zavialov2019-02-231-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch removes 'HsArrApp' and 'HsArrForm' from 'HsExpr' by introducing a new ambiguity resolution system in the parser. Problem: there are places in the grammar where we do not know whether we are parsing an expression or a command: proc x -> do { (stuff) -< x } -- 'stuff' is an expression proc x -> do { (stuff) } -- 'stuff' is a command Until we encounter arrow syntax (-<) we don't know whether to parse 'stuff' as an expression or a command. The old solution was to parse as HsExpr always, and rejig later: checkCommand :: LHsExpr GhcPs -> P (LHsCmd GhcPs) This meant polluting 'HsExpr' with command-related constructors. In other words, limitations of the parser were affecting the AST, and all other code (the renamer, the typechecker) had to deal with these extra constructors by panicking. We fix this abstraction leak by parsing into an intermediate representation, 'ExpCmd': data ExpCmdG b where ExpG :: ExpCmdG HsExpr CmdG :: ExpCmdG HsCmd type ExpCmd = forall b. ExpCmdG b -> PV (Located (b GhcPs)) checkExp :: ExpCmd -> PV (LHsExpr GhcPs) checkCmd :: ExpCmd -> PV (LHsCmd GhcPs) checkExp f = f ExpG -- interpret as an expression checkCmd f = f CmdG -- interpret as a command See Note [Ambiguous syntactic categories] for details. Now the intricacies of parsing have no effect on the hsSyn AST when it comes to the expression/command ambiguity. Future work: apply the same principles to the expression/pattern ambiguity.
* Fix typo in DsExprwip/ds-expr-typoMatthew Pickering2019-01-181-1/+1
|
* Warn on all out-of-range literals in pats/exprsAlec Theriault2018-12-031-6/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: These changes were motivated by #13256. While poking around, I realized we weren't very consistent in our "-Woverflowed-literals" warnings. This patch fixes that by: * warning earlier on in the pipeline (ie. before we've desugared 'Int' patterns into 'I# Int#') * handling 'HsLit' as well as 'HsOverLit' (this covers unboxed literals) * covering more pattern / expression forms 4/6 of the warnings in the 'Overflow' test are due to this patch. The other two are mostly for completeness. Also fixed a missing empty-enumeration warning for 'Natural'. This warnings were tripped up by the 'Bounded Word' instance (see #9505), but the fix was obvious and simple: use unboxed word literals. Test Plan: make TEST=Overflow && make TEST=T10930 Reviewers: hvr, bgamari, RyanGlScott Reviewed By: RyanGlScott Subscribers: RyanGlScott, rwbarton, carter GHC Trac Issues: #13256, #10930 Differential Revision: https://phabricator.haskell.org/D5181
* [TTG: Handling Source Locations] Foundation and PatShayan-Najd2018-11-241-33/+36
| | | | | | | | | | | | | | | | | | 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
* More explicit foralls (GHC Proposal 0007)Matthew Yacavone2018-10-271-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | Allow the user to explicitly bind type/kind variables in type and data family instances (including associated instances), closed type family equations, and RULES pragmas. Follows the specification of GHC Proposal 0007, also fixes #2600. Advised by Richard Eisenberg. This modifies the Template Haskell AST -- old code may break! Other Changes: - convert HsRule to a record - make rnHsSigWcType more general - add repMaybe to DsMeta Includes submodule update for Haddock. Test Plan: validate Reviewers: goldfire, bgamari, alanz Subscribers: simonpj, RyanGlScott, goldfire, rwbarton, thomie, mpickering, carter GHC Trac Issues: #2600, #14268 Differential Revision: https://phabricator.haskell.org/D4894
* 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
* Be mindful of GADT tyvar order when desugaring record updatesRyan Scott2018-08-171-8/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: After commit ef26182e2014b0a2a029ae466a4b121bf235e4e4, the type variable binders in GADT constructor type signatures are now quantified in toposorted order, instead of always having all the universals before all the existentials. Unfortunately, that commit forgot to update some code (which was assuming the latter scenario) in `DsExpr` which desugars record updates. This wound up being the cause of #15499. This patch makes up for lost time by desugaring record updates in a way such that the desugared expression applies type arguments to the right-hand side constructor in the correct order—that is, the order in which they were quantified by the user. Test Plan: make test TEST=T15499 Reviewers: simonpj, bgamari Reviewed By: simonpj Subscribers: rwbarton, carter GHC Trac Issues: #15499 Differential Revision: https://phabricator.haskell.org/D5060
* Small refactor in desugar of pattern matchingSimon Peyton Jones2018-07-271-1/+1
| | | | | | | | | | | | | | | | 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
* TTG for IPBind had wrong extension nameAlan Zimmerman2018-06-221-1/+1
| | | | | | | | | | | | | | | | | | | | The standard[1] for extension naming is to use the XC prefix for the internal extension points, rather than for a new constructor. This is violated for IPBind, having data IPBind id = IPBind (XIPBind id) (Either (Located HsIPName) (IdP id)) (LHsExpr id) | XCIPBind (XXIPBind id) Swap the usage of XIPBind and XCIPBind [1] https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow#Namingconventions Closes #15302
* vectorise: Put it out of its miseryBen Gamari2018-06-021-27/+0
| | | | | | | | | | | | | | | | | | | | | 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
* TTG : complete for balance of hsSyn ASTAlan Zimmerman2018-04-271-20/+23
| | | | | | | | | | | | | | | | | | Summary: - remove PostRn/PostTc fields - remove the HsVect In/Out distinction for Type, Class and Instance - remove PlaceHolder in favour of NoExt - Simplify OutputableX constraint Updates haddock submodule Test Plan: ./validate Reviewers: goldfire, bgamari Subscribers: goldfire, thomie, mpickering, carter Differential Revision: https://phabricator.haskell.org/D4625
* TTG for HsBinds and Data instances Plan BAlan Zimmerman2018-04-131-7/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: - Add the balance of the TTG extensions for hsSyn/HsBinds - Move all the (now orphan) data instances into hsSyn/HsInstances and use TTG Data instances Plan B https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/Instances#PLANB Updates haddock submodule. Illustrative numbers Compiling HsInstances before using Plan B. Max residency ~ 5G <<ghc: 629,864,691,176 bytes, 5300 GCs, 321075437/1087762592 avg/max bytes residency (23 samples), 2953M in use, 0.000 INIT (0.000 elapsed), 383.511 MUT (384.986 elapsed), 37.426 GC (37.444 elapsed) :ghc>> Using Plan B Max residency 1.1G <<ghc: 78,832,782,968 bytes, 2884 GCs, 222140352/386470152 avg/max bytes residency (34 samples), 1062M in use, 0.001 INIT (0.001 elapsed), 56.612 MUT (62.917 elapsed), 32.974 GC (32.923 elapsed) :ghc>> Test Plan: ./validate Reviewers: shayan-najd, goldfire, bgamari Subscribers: goldfire, thomie, mpickering, carter Differential Revision: https://phabricator.haskell.org/D4581
* Restore Trees That Grow reverted commitsAlan Zimmerman2018-04-091-60/+64
| | | | | | | | | | | | | | | | | | 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
* Track type variable scope more carefully.Richard Eisenberg2018-03-311-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The main job of this commit is to track more accurately the scope of tyvars introduced by user-written foralls. For example, it would be to have something like this: forall a. Int -> (forall k (b :: k). Proxy '[a, b]) -> Bool In that type, a's kind must be k, but k isn't in scope. We had a terrible way of doing this before (not worth repeating or describing here, but see the old tcImplicitTKBndrs and friends), but now we have a principled approach: make an Implication when kind-checking a forall. Doing so then hooks into the existing machinery for preventing skolem-escape, performing floating, etc. This also means that we bump the TcLevel whenever going into a forall. The new behavior is done in TcHsType.scopeTyVars, but see also TcHsType.tc{Im,Ex}plicitTKBndrs, which have undergone significant rewriting. There are several Notes near there to guide you. Of particular interest there is that Implication constraints can now have skolems that are out of order; this situation is reported in TcErrors. A major consequence of this is a slightly tweaked process for type- checking type declarations. The new Note [Use SigTvs in kind-checking pass] in TcTyClsDecls lays it out. The error message for dependent/should_fail/TypeSkolEscape has become noticeably worse. However, this is because the code in TcErrors goes to some length to preserve pre-8.0 error messages for kind errors. It's time to rip off that plaster and get rid of much of the kind-error-specific error messages. I tried this, and doing so led to a lovely error message for TypeSkolEscape. So: I'm accepting the error message quality regression for now, but will open up a new ticket to fix it, along with a larger error-message improvement I've been pondering. This applies also to dependent/should_fail/{BadTelescope2,T14066,T14066e}, polykinds/T11142. Other minor changes: - isUnliftedTypeKind didn't look for tuples and sums. It does now. - check_type used check_arg_type on both sides of an AppTy. But the left side of an AppTy isn't an arg, and this was causing a bad error message. I've changed it to use check_type on the left-hand side. - Some refactoring around when we print (TYPE blah) in error messages. The changes decrease the times when we do so, to good effect. Of course, this is still all controlled by -fprint-explicit-runtime-reps Fixes #14066 #14749 Test cases: dependent/should_compile/{T14066a,T14749}, dependent/should_fail/T14066{,c,d,e,f,g,h}
* Improve exhaustive checking for guards in pattern bindings and MultiIf.HE, Tao2018-03-021-0/+3
| | | | | | | | | | | | | | | | | | | | | | | Previously we didn't do exhaustive checking on MultiIf expressions and guards in pattern bindings. We can construct the `LMatch` directly from GRHSs or [LHsExpr] (MultiIf's alts) then feed it to checkMatches, without construct the MatchGroup and using function `matchWrapper`. Signed-off-by: HE, Tao <sighingnow@gmail.com> Test Plan: make test TEST="T14773a T14773b" Reviewers: bgamari, RyanGlScott, simonpj Reviewed By: bgamari, simonpj Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14773 Differential Revision: https://phabricator.haskell.org/D4400
* Make cost centre symbol names deterministic.Shea Levy2018-03-021-2/+3
| | | | | | | | | | | | | | | | | | | | | Previously, non-CAF cost centre symbol names contained a unique, leading to non-deterministic object files which, among other issues, can lead to an inconsistency causing linking failure when using cached builds sourced from multiple machines, such as with nix. Now, each cost centre symbol is annotated with the type of cost centre it is (CAF, expression annotation, declaration annotation, or HPC) and, when a single module has multiple cost centres with the same name and type, a 0-based index. Reviewers: bgamari, simonmar Reviewed By: bgamari Subscribers: niteria, simonmar, RyanGlScott, osa1, rwbarton, thomie, carter GHC Trac Issues: #4012, #12935 Differential Revision: https://phabricator.haskell.org/D4388
* Detect levity-polymorphic uses of unsafeCoerce#Simon Peyton Jones2017-12-131-1/+2
| | | | | | | | This bug was shown up by Trac #14561. The deguarer carefully detects unsaturated and levity-polymorphic uses of primops, but not of things like unsafeCoerce#. The fix is simple: see Note [Levity-polymorphic Ids] in Id.
* Revert "trees that grow" workBen Gamari2017-11-211-63/+59
| | | | | | | | | | | | | | 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.
* TTG3 Combined Step 1 and 3 for Trees That GrowAlan Zimmerman2017-11-141-1/+2
| | | | | | | | | | | | | | | | | | | Further progress on implementing Trees that Grow on hsSyn AST. See https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow Trees that grow extension points are added for - Rest of HsExpr.hs Updates haddock submodule Test Plan: ./validate Reviewers: bgamari, shayan-najd, goldfire Subscribers: goldfire, rwbarton, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D4186
* WIP on combined Step 1 and 3 for Trees That Grow, HsExprAlan Zimmerman2017-11-111-55/+57
| | | | | | | | | | | | | | | | | See https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow Trees that grow extension points are added for - HsExpr Updates haddock submodule Test Plan: ./validate Reviewers: bgamari, goldfire Subscribers: rwbarton, thomie, shayan-najd, mpickering Differential Revision: https://phabricator.haskell.org/D4177
* WIP on Doing a combined Step 1 and 3 for Trees That GrowAlan Zimmerman2017-11-081-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | 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-1/+1
| | | | | | | | 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-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* ApplicativeDo: handle BodyStmt (#12143)Simon Marlow2017-10-271-1/+1
| | | | | | | | | | | | | | | | | | | Summary: It's simple to treat BodyStmt just like a BindStmt with a wildcard pattern, which is enough to fix #12143 without going all the way to using `<*` and `*>` (#10892). Test Plan: * new test cases in `ado004.hs` * validate Reviewers: niteria, simonpj, bgamari, austin, erikd Subscribers: rwbarton, thomie GHC Trac Issues: #12143 Differential Revision: https://phabricator.haskell.org/D4128
* desugar: Catch levity polymorphism in unboxed sum expressionsBen Gamari2017-09-261-5/+5
| | | | Fixes #13929.
* 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
* Fix #13929 by adding another levity polymorphism checkRichard Eisenberg2017-09-141-5/+4
| | | | test case: typecheck/should_fail/T13929
* Small refactor of getRuntimeRepSimon Peyton Jones2017-08-291-1/+1
| | | | | | | | | 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.
* Improve the desugaring of -XStrictSimon Peyton Jones2017-07-311-11/+0
| | | | | | | | | | | | | | | | | | | | | | | Trac #14035 showed that -XStrict was generating some TERRIBLE desugarings, espcially for bindings with INLINE pragmas. Reason: with -XStrict, all AbsBinds (even for non-recursive functions) went via the general-case deguaring for AbsBinds, namely "generate a tuple and select from it", even though in this case there was only one variable in the tuple. And that in turn interacts terribly badly with INLINE pragmas. This patch cleans things up: * I killed off AbsBindsSig completely, in favour of a boolean flag abs_sig in AbsBinds. See Note [The abs_sig field of AbsBinds] This allowed me to delete lots of code; and instance-method declarations can enjoy the benefits too. (They could have before, but no one had changed them to use AbsBindsSig.) * I refactored all the AbsBinds handling in DsBinds into a new function DsBinds.dsAbsBinds. This allowed me to handle the strict case uniformly