summaryrefslogtreecommitdiff
path: root/compiler/hsSyn
Commit message (Collapse)AuthorAgeFilesLines
...
* Use a less confusing type variable in a few typesSimon Jakobi2018-05-292-6/+6
|
* Check for mismatched class methods during typecheckingRyan Scott2018-05-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Summary: Template Haskell provides a wormhole through which you can sneak methods that don't belong to a class into an instance for that class, bypassing the renamer's validity checks. The solution adopted here is to mirror the treatment for associated type family instances, which have an additional check in the typechecker which catch mismatched associated type families that were snuck through using Template Haskell. I've put a similar check for class methods into `tcMethods`. Test Plan: make test TEST=T12387 Reviewers: bgamari, simonpj Reviewed By: bgamari, simonpj Subscribers: simonpj, rwbarton, thomie, carter GHC Trac Issues: #12387 Differential Revision: https://phabricator.haskell.org/D4710
* Fix #14875 by introducing PprPrec, and using itRyan Scott2018-05-137-227/+254
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Trying to determine when to insert parentheses during TH conversion is a bit of a mess. There is an assortment of functions that try to detect this, such as: * `hsExprNeedsParens` * `isCompoundHsType` * `hsPatNeedsParens` * `isCompoundPat` * etc. To make things worse, each of them have slightly different semantics. Plus, they don't work well in the presence of explicit type signatures, as #14875 demonstrates. All of these problems can be alleviated with the use of an explicit precedence argument (much like what `showsPrec` currently does). To accomplish this, I introduce a new `PprPrec` data type, and define standard predences for things like function application, infix operators, function arrows, and explicit type signatures (that last one is new). I then added `PprPrec` arguments to the various `-NeedsParens` functions, and use them to make smarter decisions about when things need to be parenthesized. A nice side effect is that functions like `isCompoundHsType` are now completely unneeded, since they're simply aliases for `hsTypeNeedsParens appPrec`. As a result, I did a bit of refactoring to remove these sorts of functions. I also did a pass over various utility functions in GHC for constructing AST forms and used more appropriate precedences where convenient. Along the way, I also ripped out the existing `TyPrec` data type (which was tailor-made for pretty-printing `Type`s) and replaced it with `PprPrec` for consistency. Test Plan: make test TEST=T14875 Reviewers: alanz, goldfire, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14875 Differential Revision: https://phabricator.haskell.org/D4688
* TTG : complete for balance of hsSyn ASTAlan Zimmerman2018-04-2713-887/+1666
| | | | | | | | | | | | | | | | | | 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-1313-373/+971
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "Fix #14838 by marking TH-spliced code as FromSource"Ben Gamari2018-04-102-9/+9
| | | | | | | | | | | | | | | | This reverts commit ffb2738f86c4e4c3f0eaacf0a95d7326fdd2e383. Due to #14987. Reviewers: goldfire, RyanGlScott Reviewed By: RyanGlScott Subscribers: RyanGlScott, thomie, carter GHC Trac Issues: #14987, #14838 Differential Revision: https://phabricator.haskell.org/D4545
* Restore Trees That Grow reverted commitsAlan Zimmerman2018-04-0913-919/+1871
| | | | | | | | | | | | | | | | | | 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
* Remove HasSourceText and SourceTextX classesAlan Zimmerman2018-04-0711-383/+304
| | | | | | | | Updates haddock submodule to match. Test Plan : Validate Differential Revision: https://phabricator.haskell.org/D4199
* Track type variable scope more carefully.Richard Eisenberg2018-03-312-5/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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}
* Allow PartialTypeSignatures in standalone deriving contextsRyan Scott2018-03-232-2/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: At its core, this patch is a simple tweak that allows a user to write: ```lang=haskell deriving instance _ => Eq (Foo a) ``` Which is functionally equivalent to: ```lang=haskell data Foo a = ... deriving Eq ``` But with the added flexibility that `StandaloneDeriving` gives you (namely, the ability to use it anywhere, not just in the same module that `Foo` was declared in). This fixes #13324, and should hopefully address a use case brought up in #10607. Currently, only the use of a single, extra-constraints wildcard is permitted in a standalone deriving declaration. Any other wildcard is rejected, so things like `deriving instance (Eq a, _) => Eq (Foo a)` are currently forbidden. There are quite a few knock-on changes brought on by this change: * The `HsSyn` type used to represent standalone-derived instances was previously `LHsSigType`, which isn't sufficient to hold wildcard types. This needed to be changed to `LHsSigWcType` as a result. * Previously, `DerivContext` was a simple type synonym for `Maybe ThetaType`, under the assumption that you'd only ever be in the `Nothing` case if you were in a `deriving` clause. After this patch, that assumption no longer holds true, as you can also be in this situation with standalone deriving when an extra-constraints wildcard is used. As a result, I changed `DerivContext` to be a proper datatype that reflects the new wrinkle that this patch adds, and plumbed this through the relevant parts of `TcDeriv` and friends. * Relatedly, the error-reporting machinery in `TcErrors` also assumed that if you have any unsolved constraints in a derived instance, then you should be able to fix it by switching over to standalone deriving. This was always sound advice before, but with this new feature, it's possible to have unsolved constraints even when you're standalone-deriving something! To rectify this, I tweaked some constructors of `CtOrigin` a bit to reflect this new subtlety. This requires updating the Haddock submodule. See my fork at https://github.com/RyanGlScott/haddock/commit/067d52fd4be15a1842cbb05f42d9d482de0ad3a7 Test Plan: ./validate Reviewers: simonpj, goldfire, bgamari Reviewed By: simonpj Subscribers: goldfire, rwbarton, thomie, mpickering, carter GHC Trac Issues: #13324 Differential Revision: https://phabricator.haskell.org/D4383
* Turn a TH Name for built-in syntax into an unqualified RdrNameChaitanya Koparkar2018-03-191-1/+7
| | | | | | | | | | | | | | | | | | | Previously, the Renamer would turn any fully qualified Template Haskell name into a corresponding fully qualified `RdrName`. But this is not what we want for built-in syntax, as it produces unnecessarily qualified names (eg. GHC.Types.[], GHC.Tuple.(,) etc.). Test Plan: ./validate Reviewers: RyanGlScott, bgamari, goldfire Reviewed By: RyanGlScott, bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #13776 Differential Revision: https://phabricator.haskell.org/D4506
* Drop GHC 8.0 compatibilityRyan Scott2018-03-131-2/+0
| | | | | | | | | | | | | | | | GHC 8.4.1 is out, so now GHC's support window only extends back to GHC 8.2. This means we can delete gobs of code that were only used for GHC 8.0 support. Hooray! Test Plan: ./validate Reviewers: bgamari, erikd, dfeuer Reviewed By: bgamari, dfeuer Subscribers: alexbiehl, dfeuer, rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4492
* Fix #14838 by marking TH-spliced code as FromSourceRyan Scott2018-03-022-9/+9
| | | | | | | | | | | | | | | | | | | | | | Previously, any Template Haskell code that was spliced would be marked as `Generated`, which would completely suppress pattern- match coverage warnings for it, which several folks found confusing. Indeed, Template Haskell-spliced code is "source" code in some sense, as users specifically request that it be put into their program, so changing its designation to `FromSource` makes sense from that perspective. Test Plan: make test TEST=T14838 Reviewers: goldfire, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14838 Differential Revision: https://phabricator.haskell.org/D4440
* Permit conversion of partially applied PromotedTupleTsRyan Scott2018-03-021-0/+3
| | | | | | | | | | | | | | | | | | Summary: We were simply missing a case in `Convert` for when have a `PromotedTupleT` that wasn't fully saturated. Easily fixed. Test Plan: make test TEST=T14843 Reviewers: goldfire, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14843 Differential Revision: https://phabricator.haskell.org/D4442
* Fix #14817 by not double-printing data family instance kind signaturesRyan Scott2018-03-021-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | Within `pprDataFamInstDecl`, we were invoking `pprFamInstLHS` to pretty-print a data family instance header, and we were passing `Just` a kind signature to `pprFamInstLHS` to make it pretty-print the kind signature alongside it (this is a consequence of commit d1ef223cfebd23c25489a4b0c67fbaa2f91c1ec6). But this is silly, because then invoke `pp_data_defn`, which //also// pretty-prints the kind signature, resulting in the kind signature being printed twice by mistake. This fix is simple—pass `Nothing` to `pprFamInstLHS` instead. Test Plan: make test TEST=T14817 Reviewers: alanz, bgamari, mpickering Reviewed By: mpickering Subscribers: mpickering, rwbarton, thomie, carter GHC Trac Issues: #14817 Differential Revision: https://phabricator.haskell.org/D4418
* Improve exhaustive checking for guards in pattern bindings and MultiIf.HE, Tao2018-03-021-10/+19
| | | | | | | | | | | | | | | | | | | | | | | 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
* Fix #14681 and #14682 with precision-aimed parenthesesRyan Scott2018-01-185-8/+104
| | | | | | | | | | | | | | | | | | | | | | | | | | | | It turns out that `Convert` was recklessly leaving off parentheses in two places: * Negative numeric literals * Patterns in lambda position This patch fixes it by adding three new functions, `isCompoundHsLit`, `isCompoundHsOverLit`, and `isCompoundPat`, and using them in the right places in `Convert`. While I was in town, I also sprinkled `isCompoundPat` among some `Pat`-constructing functions in `HsUtils` to help avoid the likelihood of this problem happening in other places. One of these places is in `TcGenDeriv`, and sprinkling `isCompountPat` there fixes #14682 Test Plan: make test TEST="T14681 T14682" Reviewers: alanz, goldfire, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14681, #14682 Differential Revision: https://phabricator.haskell.org/D4323
* Parenthesize forall-type args in cvtTypeKindRyan Scott2018-01-151-4/+5
| | | | | | | | | | | | | | | | | Trac #14646 happened because we forgot to parenthesize `forall` types to the left of an arrow. This simple patch fixes that. Test Plan: make test TEST=T14646 Reviewers: alanz, goldfire, bgamari Reviewed By: alanz Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14646 Differential Revision: https://phabricator.haskell.org/D4298
* Make typeToLHsType produce kind signatures for tycon applicationsRyan Scott2018-01-031-2/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: `GeneralizedNewtypeDeriving` generates calls to `coerce` which take visible type arguments. These types must be produced by way of `typeToLHsType`, which converts a `Type` to an `LHsType`. However, `typeToLHsType` was leaving off important kind information when a `Type` contained a poly-kinded tycon application, leading to incorrectly generated code in #14579. This fixes the issue by tweaking `typeToLHsType` to generate explicit kind signatures for tycon applications. This makes the generated code noisier, but at least the program from #14579 now works correctly. Test Plan: make test TEST=T14579 Reviewers: simonpj, bgamari Reviewed By: simonpj Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14579 Differential Revision: https://phabricator.haskell.org/D4264
* Simplify HsPatSynDetailsSimon Peyton Jones2017-12-213-52/+9
| | | | | | This is a pure refactoring. Use HsConDetails to implement HsPatSynDetails, instead of defining a whole new data type. Less code, fewer types, all good.
* Improve treatment of sectioned holesRyan Scott2017-12-201-0/+4
| | | | | | | | | | | | | | | | | | | Summary: Previously, GHC was pretty-printing left-section holes incorrectly and not parsing right-sectioned holes at all. This patch fixes both problems. Test Plan: make test TEST=T14590 Reviewers: bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie, mpickering, carter GHC Trac Issues: #14590 Differential Revision: https://phabricator.haskell.org/D4273
* Fix #14578 by checking isCompoundHsType in more placesRyan Scott2017-12-202-6/+14
| | | | | | | | | | | | | | | | | | | | | Summary: The `HsType` pretty-printer does not automatically insert parentheses where necessary for type applications, so a function `isCompoundHsType` was created in D4056 towards this purpose. However, it was not used in as many places as it ought to be, resulting in #14578. Test Plan: make test TEST=T14578 Reviewers: alanz, bgamari, simonpj Reviewed By: alanz, simonpj Subscribers: simonpj, rwbarton, thomie, carter GHC Trac Issues: #14578 Differential Revision: https://phabricator.haskell.org/D4266
* Get rid of some stuttering in comments and docsGabor Greif2017-12-191-2/+2
|
* Add missing case to HsExpr.isMonadFailStmtContextSimon Peyton Jones2017-12-181-13/+10
| | | | | | This fixes Trac #14591 I took the opportunity to delete the dead code isMonadCompExpr
* Refactor ConDecl: Trac #14529Simon Peyton Jones2017-12-074-162/+169
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch refactors HsDecls.ConDecl. Specifically * ConDeclGADT was horrible, with all the information hidden inside con_res_ty. Now it's kept separate, as it should be. * ConDeclH98: use [LHsTyVarBndr] instead of LHsQTyVars for the existentials. There is no implicit binding here. * Add a field con_forall to both ConDeclGADT and ConDeclH98 which says if there is an explicit user-written forall. * Field renamings in ConDecl con_cxt to con_mb_cxt con_details to con_args There is an accompanying submodule update to Haddock. Also the following change turned out to remove a lot of clutter: * add a smart constructor for HsAppsTy, namely mkHsAppsTy, and use it consistently. This avoids a lot of painful pattern matching for the common singleton case. Two api-annotation tests (T10278, and T10399) are broken, hence marking them as expect_broken(14529). Alan is going to fix them, probably by changing the con_forall field to con_forall :: Maybe SrcSpan instead of Bool
* Revert "trees that grow" workBen Gamari2017-11-2113-2240/+1229
| | | | | | | | | | | | | | 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-149-161/+332
| | | | | | | | | | | | | | | | | | | 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-116-301/+569
| | | | | | | | | | | | | | | | | 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-0813-842/+1414
| | | | | | | | | | | | | | | | | | | | | | | | | 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-0713-1349/+795
| | | | | | | | 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-0713-795/+1349
| | | | | | | | | | | | | | | | | | | | | | | | | 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-272-9/+50
| | | | | | | | | | | | | | | | | | | 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
* Pretty-printing of derived multi-parameter classes omits parenthesesAlan Zimmerman2017-10-113-6/+42
| | | | | | | | | | | | | | | | | | | Summary: Pretty printing a splice with an HsAppType in the deriving clause, such as $([d| data Foo a = Foo a deriving (C a) |]) would omit the parens. Test Plan: ./validate Reviewers: RyanGlScott, austin, bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #14289 Differential Revision: https://phabricator.haskell.org/D4056
* Simply Data instance context for AmbiguousFieldOccRyan Scott2017-10-071-4/+1
| | | | | | The current, verbose instance context can be compacted into `DataId pass`. Indeed, that's what most of the `Data` instances in this module already do, so this just makes things consistent.
* Fix #14320 by looking through HsParTy in more placesRyan Scott2017-10-071-2/+4
| | | | | | | | | | | | | | | | | | | | | | Summary: GHC was needlessly rejecting GADT constructors' type signatures that were surrounded in parentheses due to the fact that `splitLHsForAllTy` and `splitLHsQualTy` (which are used to check as part of checking if GADT constructor return types are correct) weren't looking through parentheses (i.e., `HsParTy`). This is easily fixed, though. Test Plan: make test TEST=T14320 Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #14320 Differential Revision: https://phabricator.haskell.org/D4072
* Remove m_type from Match (#14313)Joachim Breitner2017-10-043-15/+3
| | | | | | | this is a remains from supporting Result Type Signaturs in the ancient past. Differential Revision: https://phabricator.haskell.org/D4066
* Pretty-printer missing parens for infix class declarationAlan Zimmerman2017-10-021-0/+4
| | | | | | | | | | class (a `C` b) c Is pretty printed as class a `C` b c Fixes #14306
* A bunch of typofixesGabor Greif2017-09-261-1/+1
|
* compiler: introduce custom "GhcPrelude" PreludeHerbert Valerio Riedel2017-09-1914-0/+28
| | | | | | | | | | | | | | | | | | 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 #14228 by marking SumPats as non-irrefutableRyan Scott2017-09-151-2/+25
| | | | | | | | | | | | | | | | | | | | `isIrrefutableHsPat` should always return `False` for unboxed sum patterns (`SumPat`s), since they always have at least one other corresponding pattern of the same arity (since the minimum arity for a `SumPat` is 2). Failure to do so causes incorrect code to be generated for pattern synonyms that use unboxed sums, as shown in #14228. Test Plan: make test TEST=T14228 Reviewers: austin, bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie GHC Trac Issues: #14228 Differential Revision: https://phabricator.haskell.org/D3951
* Allow CSE'ing of work-wrapped bindings (#14186)Joachim Breitner2017-09-122-3/+3
| | | | | | | | the worker/wrapper creates an artificial INLINE pragma, which caused CSE to not do its work. We now recognize such artificial pragmas by using `NoUserInline` instead of `Inline` as the `InlineSpec`. Differential Revision: https://phabricator.haskell.org/D3939
* Add debugPprTypeSimon Peyton Jones2017-08-315-18/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | We pretty-print a type by converting it to an IfaceType and pretty-printing that. But (a) that's a bit indirect, and (b) delibrately loses information about (e.g.) the kind on the /occurrences/ of a type variable So this patch implements debugPprType, which pretty prints the type directly, with no fancy formatting. It's just used for debugging. I took the opportunity to refactor the debug-pretty-printing machinery a little. In particular, define these functions and use them: ifPprDeubug :: SDoc -> SDOc -> SDoc -- Says what to do with and without -dppr-debug whenPprDebug :: SDoc -> SDoc -- Says what to do with -dppr-debug; without is empty getPprDebug :: (Bool -> SDoc) -> SDoc getPprDebug used to be called sdocPprDebugWith whenPprDebug used to be called ifPprDebug So a lot of files get touched in a very mechanical way
* HsExpr: Fix typoJames Michael DuPont2017-08-291-1/+1
|
* Refactor type family instance abstract syntax declarationsRyan Scott2017-08-293-81/+101
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This implements @simonpj's suggested refactoring of the abstract syntax for type/data family instances (from https://ghc.haskell.org/trac/ghc/ticket/14131#comment:9). This combines the previously separate `TyFamEqn` and `DataFamInstDecl` types into a single `FamEqn` datatype. This also factors the `HsImplicitBndrs` out of `HsTyPats` in favor of putting them just outside of `FamEqn` (as opposed to before, where all of the implicit binders were embedded inside of `TyFamEqn`/`DataFamInstDecl`). Finally, along the way I noticed that `dfid_fvs` and `tfid_fvs` were completely unused, so I removed them. Aside from some changes in parser test output, there is no change in behavior. Requires a Haddock submodule commit from my fork (at https://github.com/RyanGlScott/haddock/commit/815d2deb9c0222c916becccf84 64b740c26255fd) Test Plan: ./validate Reviewers: simonpj, austin, goldfire, bgamari, alanz Reviewed By: bgamari Subscribers: mpickering, goldfire, rwbarton, thomie, simonpj GHC Trac Issues: #14131 Differential Revision: https://phabricator.haskell.org/D3881
* Comments onlySimon Peyton Jones2017-08-292-7/+12
| | | | Better comment on con_qvars in ConDecl
* Make parsed AST dump output lazilyDavid Feuer2017-08-281-81/+79
| | | | | | | | | | | | | | | | | | | | | | | | | Previously, `showAstData` produced a `String`. That `String` would then be converted to a `Doc` using `text` to implement `-ddump-parsed-ast`. But rendering `text` calculates the length of the `String` before doing anything else. Since the AST can be very large, this was bad: the whole dump string (potentially hundreds of millions of `Char`s) was accumulated in memory. Now, `showAstData` produces a `Doc` directly, which seems to work a lot better. As an extra bonus, the code is simpler and cleaner. The formatting has changed a bit, as the previous ad hoc approach didn't really match the pretty printer too well. If someone cares enough to request adjustments, we can surely make them. Reviewers: austin, bgamari, mpickering, alanz Reviewed By: bgamari Subscribers: mpickering, rwbarton, thomie GHC Trac Issues: #14161 Differential Revision: https://phabricator.haskell.org/D3894
* Comments, plus adjust debug print of TcTyThing(ATyVar)Simon Peyton Jones2017-08-252-6/+3
|
* Better pretty-printing for CHoleCanSimon Peyton Jones2017-08-241-1/+2
| | | | Debug-only; no change in mainstream behaviour
* Revise function arity mismatch errors involving TypeApplicationsRyan Scott2017-08-221-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Currently, whenever you apply a function to too many arguments and some of those arguments happen to be visible type applications, the error message that GHC gives is rather confusing. Consider the message you receive when typechecking `id @Int 1 2`: ``` The function `id` is applied to three arguments, but its type `Int -> Int` has only one ``` This is baffling, since the two lines treat the visible type argument `@Int` differently. The top line ("applied to three arguments") includes `@Int`, whereas the bottom line ("has only one") excludes `@Int` from consideration. There are multiple ways one could fix this, which I explain in an addendum to `Note [Herald for matchExpectedFunTys]`. The approach adopted here is to change the herald of this error message to include visible type arguments, and to avoid counting them in the "applied to n arguments" part of the error. The end result is that the new error message for `id @Int 1 2` is now: ``` The expression `id @Int` is applied to two arguments, but its type `Int -> Int` has only one ``` Test Plan: make test TEST=T13902 Reviewers: goldfire, austin, bgamari Reviewed By: goldfire Subscribers: rwbarton, thomie GHC Trac Issues: #13902 Differential Revision: https://phabricator.haskell.org/D3868
* Use field names for all uses of datacon MatchSimon Peyton Jones2017-07-312-4/+7
| | | | | | | This is refactoring only... elimiante all positional uses of the data constructor Match in favour of field names. No change in behaviour.
View Lorry Controller Status