summaryrefslogtreecommitdiff
path: root/compiler/hsSyn
Commit message (Collapse)AuthorAgeFilesLines
...
* Enable rebindable fail with overloaded stringsShayne Fletcher2018-12-112-4/+9
| | | | | | | | | | | | | | Summary: enable rebindable fail with overloaded strings Reviewers: bgamari, simonpj Reviewed By: bgamari, simonpj Subscribers: simonpj, ndmitchell, rwbarton, carter GHC Trac Issues: #15645 Differential Revision: https://phabricator.haskell.org/D5251
* Taming the Kind Inference MonsterSimon Peyton Jones2018-11-292-69/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | My original goal was (Trac #15809) to move towards using level numbers as the basis for deciding which type variables to generalise, rather than searching for the free varaibles of the environment. However it has turned into a truly major refactoring of the kind inference engine. Let's deal with the level-numbers part first: * Augment quantifyTyVars to calculate the type variables to quantify using level numbers, and compare the result with the existing approach. That is; no change in behaviour, just a WARNing if the two approaches give different answers. * To do this I had to get the level number right when calling quantifyTyVars, and this entailed a bit of care, especially in the code for kind-checking type declarations. * However, on the way I was able to eliminate or simplify a number of calls to solveEqualities. This work is incomplete: I'm not /using/ level numbers yet. When I subsequently get rid of any remaining WARNings in quantifyTyVars, that the level-number answers differ from the current answers, then I can rip out the current "free vars of the environment" stuff. Anyway, this led me into deep dive into kind inference for type and class declarations, which is an increasingly soggy part of GHC. Richard already did some good work recently in commit 5e45ad10ffca1ad175b10f6ef3327e1ed8ba25f3 Date: Thu Sep 13 09:56:02 2018 +0200 Finish fix for #14880. The real change that fixes the ticket is described in Note [Naughty quantification candidates] in TcMType. but I kept turning over stones. So this patch has ended up with a pretty significant refactoring of that code too. Kind inference for types and classes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * Major refactoring in the way we generalise the inferred kind of a TyCon, in kcTyClGroup. Indeed, I made it into a new top-level function, generaliseTcTyCon. Plus a new Note to explain it Note [Inferring kinds for type declarations]. * We decided (Trac #15592) not to treat class type variables specially when dealing with Inferred/Specified/Required for associated types. That simplifies things quite a bit. I also rewrote Note [Required, Specified, and Inferred for types] * Major refactoring of the crucial function kcLHsQTyVars: I split it into kcLHsQTyVars_Cusk and kcLHsQTyVars_NonCusk because the two are really quite different. The CUSK case is almost entirely rewritten, and is much easier because of our new decision not to treat the class variables specially * I moved all the error checks from tcTyClTyVars (which was a bizarre place for it) into generaliseTcTyCon and/or the CUSK case of kcLHsQTyVars. Now tcTyClTyVars is extremely simple. * I got rid of all the all the subtleties in tcImplicitTKBndrs. Indeed now there is no difference between tcImplicitTKBndrs and kcImplicitTKBndrs; there is now a single bindImplicitTKBndrs. Same for kc/tcExplicitTKBndrs. None of them monkey with level numbers, nor build implication constraints. scopeTyVars is gone entirely, as is kcLHsQTyVarBndrs. It's vastly simpler. I found I could get rid of kcLHsQTyVarBndrs entirely, in favour of the bnew bindExplicitTKBndrs. Quantification ~~~~~~~~~~~~~~ * I now deal with the "naughty quantification candidates" of the previous patch in candidateQTyVars, rather than in quantifyTyVars; see Note [Naughty quantification candidates] in TcMType. I also killed off closeOverKindsCQTvs in favour of the same strategy that we use for tyCoVarsOfType: namely, close over kinds at the occurrences. And candidateQTyVars no longer needs a gbl_tvs argument. * Passing the ContextKind, rather than the expected kind itself, to tc_hs_sig_type_and_gen makes it easy to allocate the expected result kind (when we are in inference mode) at the right level. Type families ~~~~~~~~~~~~~~ * I did a major rewrite of the impenetrable tcFamTyPats. The result is vastly more comprehensible. * I got rid of kcDataDefn entirely, quite a big function. * I re-did the way that checkConsistentFamInst works, so that it allows alpha-renaming of invisible arguments. * The interaction of kind signatures and family instances is tricky. Type families: see Note [Apparently-nullary families] Data families: see Note [Result kind signature for a data family instance] and Note [Eta-reduction for data families] * The consistent instantation of an associated type family is tricky. See Note [Checking consistent instantiation] and Note [Matching in the consistent-instantation check] in TcTyClsDecls. It's now checked in TcTyClsDecls because that is when we have the relevant info to hand. * I got tired of the compromises in etaExpandFamInst, so I did the job properly by adding a field cab_eta_tvs to CoAxBranch. See Coercion.etaExpandCoAxBranch. tcInferApps and friends ~~~~~~~~~~~~~~~~~~~~~~~ * I got rid of the mysterious and horrible ClsInstInfo argument to tcInferApps, checkExpectedKindX, and various checkValid functions. It was horrible! * I got rid of [Type] result of tcInferApps. This list was used only in tcFamTyPats, when checking the LHS of a type instance; and if there is a cast in the middle, the list is meaningless. So I made tcInferApps simpler, and moved the complexity (not much) to tcInferApps. Result: tcInferApps is now pretty comprehensible again. * I refactored the many function in TcMType that instantiate skolems. Smaller things * I rejigged the error message in checkValidTelescope; I think it's quite a bit better now. * checkValidType was not rejecting constraints in a kind signature forall (a :: Eq b => blah). blah2 That led to further errors when we then do an ambiguity check. So I make checkValidType reject it more aggressively. * I killed off quantifyConDecl, instead calling kindGeneralize directly. * I fixed an outright bug in tyCoVarsOfImplic, where we were not colleting the tyvar of the kind of the skolems * Renamed ClsInstInfo to AssocInstInfo, and made it into its own data type * Some fiddling around with pretty-printing of family instances which was trickier than I thought. I wanted wildcards to print as plain "_" in user messages, although they each need a unique identity in the CoAxBranch. Some other oddments * Refactoring around the trace messages from reportUnsolved. * A bit of extra tc-tracing in TcHsSyn.commitFlexi This patch fixes a raft of bugs, and includes tests for them. * #14887 * #15740 * #15764 * #15789 * #15804 * #15817 * #15870 * #15874 * #15881
* [TTG: Handling Source Locations] Foundation and PatShayan-Najd2018-11-245-236/+317
| | | | | | | | | | | | | | | | | | 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
* Fix unused-import warningsDavid Eichmann2018-11-225-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes a fairly long-standing bug (dating back to 2015) in RdrName.bestImport, namely commit 9376249b6b78610db055a10d05f6592d6bbbea2f Author: Simon Peyton Jones <simonpj@microsoft.com> Date: Wed Oct 28 17:16:55 2015 +0000 Fix unused-import stuff in a better way In that patch got the sense of the comparison back to front, and thereby failed to implement the unused-import rules described in Note [Choosing the best import declaration] in RdrName This led to Trac #13064 and #15393 Fixing this bug revealed a bunch of unused imports in libraries; the ones in the GHC repo are part of this commit. The two important changes are * Fix the bug in bestImport * Modified the rules by adding (a) in Note [Choosing the best import declaration] in RdrName Reason: the previosu rules made Trac #5211 go bad again. And the new rule (a) makes sense to me. In unravalling this I also ended up doing a few other things * Refactor RnNames.ImportDeclUsage to use a [GlobalRdrElt] for the things that are used, rather than [AvailInfo]. This is simpler and more direct. * Rename greParentName to greParent_maybe, to follow GHC naming conventions * Delete dead code RdrName.greUsedRdrName Bumps a few submodules. Reviewers: hvr, goldfire, bgamari, simonmar, jrtc27 Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5312
* Smarter HsType pretty-print for promoted dataconsSimon Peyton Jones2018-11-152-28/+59
| | | | | | | | | | | | | | | | | | | | | Fix Trac #15898, by being smarter about when to print a space before a promoted data constructor, in a HsType. I had to implement a mildly tiresome function HsType.lhsTypeHasLeadingPromotionQuote It has multiple cases, of course, but it's very simple. The patch improves the error-message output in a bunch of cases, and (to my surprise) actually fixes a bug in the output of T14343 (Trac #14343), thus - In the expression: _ :: Proxy '('( 'True, 'False), 'False) + In the expression: _ :: Proxy '( '( 'True, 'False), 'False) I discovered that there were two copies of the PromotionFlag type (a boolean, with helpfully named data cons), one in IfaceType and one in HsType. So I combined into one, PromotionFlag, and moved it to BasicTypes. That's why quite a few files are touched, but it's all routine.
* Fix #15815 by parenthesizing the arguments to infix ~Ryan Scott2018-10-291-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An unfortunate consequence of commit b9483981d128f55d8dae3f434f49fa6b5b30c779 (`Remove HsEqTy and XEqTy`) is infix uses of `~` in TH quotes now desugar differently than before. In particular, we have that: ```haskell a ~ (Int -> Int) ``` Now desugars to: ```haskell HsOpTy a (~) (HsOpTy Int (->) Int) ``` Which GHC interprets as being: ```haskell a ~ Int -> Int ``` Or, equivalently: ```haskell (a ~ Int) -> Int ``` Which is different than what was intended! This is the cause of #15815. All of this has revealed that we likely need to renovate the way we desugar infix type operators to be more consistent with the treatment for infix expressions (see https://ghc.haskell.org/trac/ghc/ticket/15815#comment:5 for more on this.) Doing so would constitute a breaking change, however, so we will likely want to wait until another major GHC release to do this. In the meantime, this patch offers a non-invasive change to the way that infix uses of `~` are desugared. This makes the program in #15815 compile again by inserting extra `HsParTy`s around the arguments to `~` if they are lacking them. Test Plan: make test TEST=T15815 Reviewers: int-index, goldfire, bgamari Reviewed By: int-index Subscribers: int-e, rwbarton, carter GHC Trac Issues: #15815 Differential Revision: https://phabricator.haskell.org/D5274
* More explicit foralls (GHC Proposal 0007)Matthew Yacavone2018-10-277-108/+150
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix #15761 by adding parensRichard Eisenberg2018-10-171-7/+9
| | | | | | This was just a pretty-printer infelicity. Fixed now. Test case: printer/T15761
* Fix #15738 by defining (and using) parenthesizeHsContextRyan Scott2018-10-152-2/+15
| | | | | | | | | | | | | | | | | | | | | With `QuantifiedConstraints`, `forall`s can appear in more nested positions than they could before, but `Convert` and the TH pretty-printer were failing to take this into account. On the `Convert` side, this is fixed by using a `parenthesizeHsContext` to parenthesize singleton quantified constraints that appear to the left of a `=>`. (A similar fix is applied to the TH pretty-printer.) Test Plan: make test TEST=T15738 Reviewers: goldfire, bgamari Reviewed By: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #15738 Differential Revision: https://phabricator.haskell.org/D5222
* Minor documentation markup fix in HsExpr.hsJosh Price2018-10-141-1/+1
| | | | PR: https://github.com/ghc/ghc/pull/202/
* Don't drop arguments in TH type argumentsAlec Theriault2018-10-041-9/+13
| | | | | | | | | | | | | | | | | | | Summary: When converting from TH AST back to HsType, we were occasionally dropping type arguments. This resulted in incorrectly accepted programs as well as incorrectly rejected programs. Test Plan: make TEST=T15360a && make TEST=T15360b Reviewers: goldfire, bgamari, tdammers Reviewed By: bgamari, tdammers Subscribers: RyanGlScott, rwbarton, carter GHC Trac Issues: #15360 Differential Revision: https://phabricator.haskell.org/D5188
* Allow (unparenthesized) kind signaturesAlec Theriault2018-10-045-6/+6
| | | | | | | | | | | | | | | | Summary: This allows for things like `[t :: MyKind]`, `(a :: k, b)`, and so on. Test Plan: make TEST=T11622 && make TEST=T8708 Reviewers: RyanGlScott, bgamari, simonpj, goldfire, alanz Reviewed By: RyanGlScott, simonpj Subscribers: alanz, simonpj, rwbarton, mpickering, carter GHC Trac Issues: #11622, #8708 Differential Revision: https://phabricator.haskell.org/D5173
* Don't look up unnecessary return in LastStmtSimon Peyton Jones2018-09-231-17/+20
| | | | | | This fixes Trac #15607. The general pattern is well established (e.g. see the guard_op binding in rnStmt of BodyStme), but we weren't using it for LastStmt.
* Buglet in reporting out of scope errors in rulesSimon Peyton Jones2018-09-231-2/+9
| | | | | | | | Most out of scope errors get reported by the type checker these days, but not all. Example, the function on the LHS of a RULE. Trace #15659 pointed out that this less-heavily-used code path produce a "wacky" error message. Indeed so. Easily fixed.
* Add support for ImplicitParams and RecursiveDo in THMichael Sloan2018-09-141-8/+41
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This adds TH support for the ImplicitParams and RecursiveDo extensions. I'm submitting this as one review because I cannot cleanly make the two commits independent. Initially, my goal was just to add ImplicitParams support, and I found that reasonably straightforward, so figured I might as well use my newfound knowledge to address some other TH omissions. Test Plan: Validate Reviewers: goldfire, austin, bgamari, RyanGlScott Reviewed By: RyanGlScott Subscribers: carter, RyanGlScott, thomie GHC Trac Issues: #1262 Differential Revision: https://phabricator.haskell.org/D1979
* Rename kind vars in left-to-right order in bindHsQTyVarsRyan Scott2018-08-281-2/+15
| | | | | | | | | | | | | | | | | | | | Summary: When renaming kind variables in an `LHsQTyVars`, we were erroneously putting all of the kind variables in the binders //after// the kind variables in the body, resulting in #15568. The fix is simple: just swap the order of these two around. Test Plan: make test TEST=T15568 Reviewers: simonpj, bgamari, goldfire Reviewed By: goldfire Subscribers: goldfire, rwbarton, carter GHC Trac Issues: #15568 Differential Revision: https://phabricator.haskell.org/D5108
* Fix #15572 by checking for promoted names in ConTRyan Scott2018-08-281-1/+8
| | | | | | | | | | | | | | | | | | | | | | Summary: When converting `ConT`s to `HsTyVar`s in `Convert`, we were failing to account for the possibility of promoted data constructor names appearing in a `ConT`, which could result in improper pretty-printing results (as observed in #15572). The fix is straightforward: use `Promoted` instead of `NotPromoted` when the name of a `ConT` is a data constructor name. Test Plan: make test TEST=T15572 Reviewers: goldfire, bgamari, simonpj, monoidal Reviewed By: goldfire, simonpj Subscribers: monoidal, rwbarton, carter GHC Trac Issues: #15572 Differential Revision: https://phabricator.haskell.org/D5112
* Fix #15550 by quoting RULE names during TH conversionRyan Scott2018-08-271-2/+2
| | | | | | | | | | | | | | | | | | | Summary: When converting a `RuleP` to a GHC source `RuleD` during TH conversion, we were stupidly not double-quoting the name of the rule. Easily fixed. Test Plan: make test TEST=T15550 Reviewers: goldfire, bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, carter GHC Trac Issues: #15550 Differential Revision: https://phabricator.haskell.org/D5090
* Replace most occurences of foldl with foldl'.klebinger.andreas@gmx.at2018-08-212-8/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 redundant imports of ClassBen Gamari2018-08-211-1/+0
|
* Add a solveEqualities to tcClassDecl1Simon Peyton Jones2018-08-212-4/+5
| | | | | | | | | | | | | | Trac #15505 showed that, when we have a type error, we could have an unfilled-in coercion hole. We don't want an assertion error in that case. The underlying cause is that tcClassDecl1 should call solveEqualities to fully solve all top-level equalities (or fail in the attempt). I also refactored the ClassDecl case for tcTyClDecl1 into a new function tcClassDecl1. That makes it symmetrical with the others.
* Fix #15527 by pretty-printing an RdrName prefixlyRyan Scott2018-08-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Summary: When `(.) @Int` is used without enabling `TypeApplications`, the resulting error message will pretty-print the (symbolic) `RdrName` `(.)`. However, it does so without parenthesizing it, which causes the pretty-printed expression to appear as `.@Int`. Yuck. Since the expression in a type application will always be prefix, we can fix this issue by using `pprPrefixOcc` instead of plain ol' `ppr`. Test Plan: make test TEST=T15527 Reviewers: bgamari, monoidal, simonpj Reviewed By: monoidal, simonpj Subscribers: rwbarton, carter GHC Trac Issues: #15527 Differential Revision: https://phabricator.haskell.org/D5071
* Properly designate LambdaCase alts as CaseAlt in THRyan Scott2018-08-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | Summary: When `\case` expressions are parsed normally, their alternatives are marked as `CaseAlt` (which means that they are pretty-printed without a `\` character in front of them, unlike for lambda expressions). However, `\case` expressions created by way of Template Haskell (in `Convert`) inconsistently designated the case alternatives as `LambdaExpr`, causing them to be pretty-printed poorly (as shown in #15518). The fix is simple: use `CaseAlt` consistently. Test Plan: make test TEST=T15518 Reviewers: goldfire, bgamari Subscribers: rwbarton, carter GHC Trac Issues: #15518 Differential Revision: https://phabricator.haskell.org/D5069
* Remove decideKindGeneralisationPlanRichard Eisenberg2018-08-021-19/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TypeInType came with a new function: decideKindGeneralisationPlan. This type-level counterpart to the term-level decideGeneralisationPlan chose whether or not a kind should be generalized. The thinking was that if `let` should not be generalized, then kinds shouldn't either (under the same circumstances around -XMonoLocalBinds). However, this is too conservative -- the situation described in the motivation for "let should be be generalized" does not occur in types. This commit thus removes decideKindGeneralisationPlan, always generalizing. One consequence is that tc_hs_sig_type_and_gen no longer calls solveEqualities, which reports all unsolved constraints, instead relying on the solveLocalEqualities in tcImplicitTKBndrs. An effect of this is that reporing kind errors gets delayed more frequently. This seems to be a net benefit in error reporting; often, alongside a kind error, the type error is now reported (and users might find type errors easier to understand). Some of these errors ended up at the top level, where it was discovered that the GlobalRdrEnv containing the definitions in the local module was not in the TcGblEnv, and thus errors were reported with qualified names unnecessarily. This commit rejiggers some of the logic around captureTopConstraints accordingly. One error message (typecheck/should_fail/T1633) is a regression, mentioning the name of a default method. However, that problem is already reported as #10087, its solution is far from clear, and so I'm not addressing it here. This commit fixes #15141. As it's an internal refactor, there is no concrete test case for it. Along the way, we no longer need the hsib_closed field of HsImplicitBndrs (it was used only in decideKindGeneralisationPlan) and so it's been removed, simplifying the datatype structure. Along the way, I removed code in the validity checker that looks at coercions. This isn't related to this patch, really (though it was, at one point), but it's an improvement, so I kept it. This updates the haddock submodule.
* Fix #15385 by using addDictsDs in matchGuardsRyan Scott2018-07-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix pretty-printing of data declarations in splicesKrzysztof Gogolewski2018-07-221-2/+2
| | | | | | | | | | | | | | Test Plan: validate Reviewers: RyanGlScott, bgamari Reviewed By: RyanGlScott Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15365 Differential Revision: https://phabricator.haskell.org/D4998
* Fix the GHCi debugger with ApplicativeDoSimon Marlow2018-07-221-1/+5
| | | | | | | | | | | | | | | | | | | | | Summary: `collectLStmtsBinders` was returning nothing for `ApplicativeStmts`, which caused the debugger to not track free variables in many cases when using `ApplicativeDo`. Test Plan: * new test case * validate Reviewers: bgamari, erikd Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15422 Differential Revision: https://phabricator.haskell.org/D4991
* Fix #15423 by using pprAStmtContextRyan Scott2018-07-201-1/+1
| | | | | | | | | | | | | | | | | Summary: Previously, we were using `pprStmtContext` instead, which led to error messages missing indefinite articles where they were required. Test Plan: make test TEST="T13242a T7786 Typeable1" Reviewers: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15423 Differential Revision: https://phabricator.haskell.org/D4992
* TTG typo: XFieldOcc should be XCFieldOccAlan Zimmerman2018-07-153-10/+10
| | | | | | | | | | | | | | | | | | | In the following data FieldOcc pass = FieldOcc { extFieldOcc :: XFieldOcc pass , rdrNameFieldOcc :: Located RdrName -- ^ See Note [Located RdrNames] in HsExpr } | XFieldOcc (XXFieldOcc pass) we are using XFieldOcc for both the extFieldOcc type and the extra constructor. The first one should be XCFieldOcc Updates haddock submodule closes #15386
* Comments onlySimon Peyton Jones2018-07-131-0/+3
|
* Improve comments about CUSKsSimon Peyton Jones2018-07-131-23/+70
|
* Fix handling of unbound constructor names in TH #14627Michael Sloan2018-07-121-1/+5
| | | | | | | | | | | | | | | | Also adds a comment to UnboundVarE clarifying that it also is used for unbound constructor identifiers, since that isn't very clear from the name. Test Plan: testsuite/tests/th/T14627.hs Reviewers: goldfire, bgamari Reviewed By: goldfire Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4923
* Note [Ordering of implicit variables]Richard Eisenberg2018-07-101-0/+33
| | | | | | This addresses #14808 [ci skip]
* More refactoring in TcValiditySimon Peyton Jones2018-07-101-2/+2
| | | | | | | | | | | | | | | This patch responds to Trac #15334 by making it an error to write an instance declaration for a tuple constraint like (Eq [a], Show [a]). I then discovered that instance validity checking was scattered betweeen TcInstDcls and TcValidity, so I took the time to bring it all together, into TcValidity.checkValidInstHead In doing so I discovered that there are lot of special cases. I have not changed them, but at least they are all laid out clearly now.
* Fix #15331 with careful blasts of parenthesizeHsTypeRyan Scott2018-07-053-4/+8
| | | | | | | | | | | | | | | | | | Summary: Another `-ddump-splices` bug that can be solved with more judicious use of parentheses. Test Plan: make test TEST=T15331 Reviewers: goldfire, bgamari, alanz, tdammers Reviewed By: tdammers Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15331 Differential Revision: https://phabricator.haskell.org/D4920
* Parenthesize rank-n contexts in ConvertRyan Scott2018-07-051-1/+3
| | | | | | | | | | | | | | | | Summary: A simple oversight. Test Plan: make test TEST=T15324 Reviewers: goldfire, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15324 Differential Revision: https://phabricator.haskell.org/D4910
* Instantiate GND bindings with an explicit type signatureRyan Scott2018-07-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Before, we were using visible type application to apply impredicative types to `coerce` in `GeneralizedNewtypeDeriving`-generated bindings. This approach breaks down when combined with `QuantifiedConstraints` in certain ways, which #14883 and #15290 provide examples of. See Note [GND and QuantifiedConstraints] for all the gory details. To avoid this issue, we instead use an explicit type signature to instantiate each GND binding, and use that to bind any type variables that might be bound by a class method's type signature. This reduces the need to impredicative type applications, and more importantly, makes the programs from #14883 and #15290 work again. Test Plan: make test TEST="T15290b T15290c T15290d T14883" Reviewers: simonpj, bgamari Reviewed By: simonpj Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14883, #15290 Differential Revision: https://phabricator.haskell.org/D4895
* Fix #15307 by making nlHsFunTy parenthesize moreRyan Scott2018-07-051-1/+7
| | | | | | | | | | | | | | | | | | | | | | | Summary: `nlHsFunTy` wasn't parenthesizing its arguments at all, which led to `-ddump-deriv` producing incorrectly parenthesized types (since it uses `nlHsFunTy` to construct those types), as demonstrated in #15307. Fix this by changing `nlHsFunTy` to add parentheses à la `ppr_ty`: always parenthesizing the argument type with function precedence, and recursively processing the result type, adding parentheses for each function type it encounters. Test Plan: make test TEST=T14578 Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15307 Differential Revision: https://phabricator.haskell.org/D4890
* Refactor the kind-checking of tyvar bindersSimon Peyton Jones2018-06-251-13/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The refactoring here is driven by the ghastly mess described in comment:24 of Trac #1520. The overall goal is to simplify the kind-checking of typev-variable binders, and in particular to narrow the use of the "in-scope tyvar binder" stuff, which is needed only for associated types: see the new Note [Kind-checking tyvar binders for associated types] in TcHsType. Now * The "in-scope tyvar binder" stuff is done only in - kcLHsQTyVars, which is used for the LHsQTyVars of a data/newtype, or type family declaration. - tcFamTyPats, which is used for associated family instances; it now calls tcImplicitQTKBndrs, which in turn usese newFlexiKindedQTyVar * tcExpicitTKBndrs (which is used only for function signatures, data con signatures, pattern synonym signatures, and expression type signatures) now does not go via the "in-scope tyvar binder" stuff at all. While I'm still not happy with all this code, the code is generally simpler, and I think this is a useful step forward. It does cure the problem too. (It's hard to trigger the problem in vanilla Haskell code, because the renamer would normally use different names for nested binders, so I can't offer a test.)
* TTG for IPBind had wrong extension nameAlan Zimmerman2018-06-222-6/+6
| | | | | | | | | | | | | | | | | | | | 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
* Remove HsEqTy and XEqTyRyan Scott2018-06-203-22/+4
| | | | | | | | | | | | | | | | | | | | | After commit d650729f9a0f3b6aa5e6ef2d5fba337f6f70fa60, the `HsEqTy` constructor of `HsType` is essentially dead code. Given that we want to remove `HsEqTy` anyway as a part of #10056 (comment:27), let's just rip it out. Bumps the haddock submodule. Test Plan: ./validate Reviewers: goldfire, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #10056 Differential Revision: https://phabricator.haskell.org/D4876
* Fix API Annotations for GADT constructorsAlan Zimmerman2018-06-192-6/+9
| | | | | | | | | | | | | | | | | | | Summary: This patch completes the work for #14529 by making sure that all API Annotations end up attached to a SrcSpan that appears in the final ParsedSource. Updates Haddock submodule Test Plan: ./validate Reviewers: goldfire, bgamari Subscribers: rwbarton, thomie, mpickering, carter GHC Trac Issues: #14529 Differential Revision: https://phabricator.haskell.org/D4867
* Embrace -XTypeInType, add -XStarIsTypeVladislav Zavialov2018-06-145-141/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Implement the "Embrace Type :: Type" GHC proposal, .../ghc-proposals/blob/master/proposals/0020-no-type-in-type.rst GHC 8.0 included a major change to GHC's type system: the Type :: Type axiom. Though casual users were protected from this by hiding its features behind the -XTypeInType extension, all programs written in GHC 8+ have the axiom behind the scenes. In order to preserve backward compatibility, various legacy features were left unchanged. For example, with -XDataKinds but not -XTypeInType, GADTs could not be used in types. Now these restrictions are lifted and -XTypeInType becomes a redundant flag that will be eventually deprecated. * Incorporate the features currently in -XTypeInType into the -XPolyKinds and -XDataKinds extensions. * Introduce a new extension -XStarIsType to control how to parse * in code and whether to print it in error messages. Test Plan: Validate Reviewers: goldfire, hvr, bgamari, alanz, simonpj Reviewed By: goldfire, simonpj Subscribers: rwbarton, thomie, mpickering, carter GHC Trac Issues: #15195 Differential Revision: https://phabricator.haskell.org/D4748
* Fix deserialization of docs (#15240)Simon Jakobi2018-06-141-5/+8
| | | | | | | | | | | | | | | | | | | | We were using Map.fromDistinctAscList to deserialize a (Map Name HsDocString). As the Names' Uniques had changed, we ended up with an invalid map in which we couldn't lookup certain keys. Switching to Map.fromList fixed the issue. Added comments in several places. Reviewers: alexbiehl, hvr, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15240 Differential Revision: https://phabricator.haskell.org/D4816
* Refactor TcExpr.tcSeqSimon Peyton Jones2018-06-121-6/+3
| | | | | | | | | | | | | | | | | | The function TcExpr.tcSeq seemed much longer that is really justifiable; and was set to get worse with the fix to Trac #15242. This patch refactors the special cases for function applications, so that the special case for 'seq' can use the regular tcFunApp, which makes the code both clearer and shorter. And smooths the way for #15242. The special case for 'tagToEnum#' is even more weird and ad-hoc, so I refrained from meddling iwth it for now. I also combined HsUtils.mkHsAppType and mkHsAppTypeOut, so that I could have a single 'wrapHsArgs' function, thereby fixing a ToDo from Alan Zimmerman. That means tha tmkHsAppType now has an equality predicate, but I guess that's fair enough.
* Fix #15243 by fixing incorrect uses of NotPromotedRyan Scott2018-06-071-3/+3
| | | | | | | | | | | | | | | | | | | In `Convert`, we were incorrectly using `NotPromoted` to denote type constructors that were actually intended to be promoted, resulting in poor `-ddump-splices` output (as seen in #15243). Easily fixed. Test Plan: make test TEST=T15243 Reviewers: bgamari, goldfire Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15243 Differential Revision: https://phabricator.haskell.org/D4809
* Introduce DerivingViaRyan Scott2018-06-044-12/+85
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This implements the `DerivingVia` proposal put forth in https://github.com/ghc-proposals/ghc-proposals/pull/120. This introduces the `DerivingVia` deriving strategy. This is a generalization of `GeneralizedNewtypeDeriving` that permits the user to specify the type to `coerce` from. The major change in this patch is the introduction of the `ViaStrategy` constructor to `DerivStrategy`, which takes a type as a field. As a result, `DerivStrategy` is no longer a simple enumeration type, but rather something that must be renamed and typechecked. The process by which this is done is explained more thoroughly in section 3 of this paper ( https://www.kosmikus.org/DerivingVia/deriving-via-paper.pdf ), although I have inlined the relevant parts into Notes where possible. There are some knock-on changes as well. I took the opportunity to do some refactoring of code in `TcDeriv`, especially the `mkNewTypeEqn` function, since it was bundling all of the logic for (1) deriving instances for newtypes and (2) `GeneralizedNewtypeDeriving` into one huge broth. `DerivingVia` reuses much of part (2), so that was factored out as much as possible. Bumps the Haddock submodule. Test Plan: ./validate Reviewers: simonpj, bgamari, goldfire, alanz Subscribers: alanz, goldfire, rwbarton, thomie, mpickering, carter GHC Trac Issues: #15178 Differential Revision: https://phabricator.haskell.org/D4684
* Serialize docstrings to ifaces, display them with new GHCi :doc commandSimon Jakobi2018-06-041-2/+90
| | | | | | | | | | | | | | | | | | | | | | | | If `-haddock` is set, we now extract docstrings from the renamed ast and serialize them in the .hi-files. This includes some of the changes from D4749 with the notable exceptions of the docstring lexing and renaming. A currently limited and experimental GHCi :doc command can be used to display docstrings for declarations. The formatting of pretty-printed docstrings is changed slightly, causing some changes in testsuite/tests/haddock. Test Plan: ./validate Reviewers: alexbiehl, hvr, gershomb, harpocrates, bgamari Reviewed By: alexbiehl Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4758
* vectorise: Put it out of its miseryBen Gamari2018-06-027-276/+7
| | | | | | | | | | | | | | | | | | | | | 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
* Make HsDocString a newtype of ByteStringSimon Jakobi2018-05-301-8/+37
| | | | | | | | | | | | | | | | | Docstrings don't profit from FastString's interning, so we switch to a different type that doesn't incur this overhead. Updates the haddock submodule. Reviewers: alexbiehl, bgamari Reviewed By: alexbiehl, bgamari Subscribers: rwbarton, thomie, mpickering, carter GHC Trac Issues: #15157 Differential Revision: https://phabricator.haskell.org/D4743
View Lorry Controller Status