summaryrefslogtreecommitdiff
path: root/compiler/rename/RnSource.hs
Commit message (Collapse)AuthorAgeFilesLines
* Add -Wmissing-deriving-strategieswip/D5451chessai2019-01-011-0/+25
| | | | | | | | | | | | | | | Warn users when -XDerivingStrategies is enabled but not used, at each potential use site. add -Wmissing-deriving-strategies Reviewers: bgamari, RyanGlScott Subscribers: andrewthad, rwbarton, carter GHC Trac Issues: #15798 Differential Revision: https://phabricator.haskell.org/D5451
* Comments onlySimon Peyton Jones2018-12-211-2/+4
|
* Fix #16002 by moving a validity check to the renamerRyan Scott2018-12-201-14/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The validity check which rejected things like: ```lang=haskell type family B x where A x = x ``` Used to live in the typechecker. But it turns out that this validity check was //only// being run on closed type families without CUSKs! This meant that GHC would silently accept something like this: ```lang=haskell type family B (x :: *) :: * where A x = x ``` This patch fixes the issue by moving this validity check to the renamer, where we can be sure that the check will //always// be run. Test Plan: make test TEST=T16002 Reviewers: simonpj, bgamari Reviewed By: simonpj Subscribers: goldfire, rwbarton, carter GHC Trac Issues: #16002 Differential Revision: https://phabricator.haskell.org/D5420
* Fix #15828, from `More explicit foralls`Matthew Yacavone2018-11-291-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Fix a bug in commit 12eeb9 which permits the following: ``` class C a where type T a b instance C (Maybe a) where type forall a b. T (Maybe a) b = b ``` where instead, the user should write: ``` instance C (Maybe a) where type forall b. T (Maybe a) b = b ``` Update the users guide to discuss scoping of type variables in explicit foralls in type family instances. Test Plan: validate Reviewers: bgamari, goldfire, monoidal Reviewed By: goldfire Subscribers: monoidal, rwbarton, carter GHC Trac Issues: #15828 Differential Revision: https://phabricator.haskell.org/D5283
* [TTG: Handling Source Locations] Foundation and PatShayan-Najd2018-11-241-93/+112
| | | | | | | | | | | | | | | | | | 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-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* More explicit foralls (GHC Proposal 0007)Matthew Yacavone2018-10-271-43/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* De-monadise the 'extract' functions in RnTypesSimon Peyton Jones2018-10-261-13/+13
| | | | | | | | | | | As Trac #15765 says, Once upon a time, the extract functions at the bottom of RnTypes were pure. Then, along came -XTypeInType, which needed to do a check in these functions for users mixing type variables with kind variables. Now, however, with -XTypeInType gone again, we no longer do this check. Thus, there is no reason to keep these functions monadic.
* Buglet in reporting out of scope errors in rulesSimon Peyton Jones2018-09-231-4/+4
| | | | | | | | 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.
* Fix redundant imports of ClassBen Gamari2018-08-211-1/+0
|
* Add a solveEqualities to tcClassDecl1Simon Peyton Jones2018-08-211-2/+1
| | | | | | | | | | | | | | 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.
* Add comment explaining change in syntax error suggestion for #12146.Aditya2018-08-171-0/+4
|
* Remove decideKindGeneralisationPlanRichard Eisenberg2018-08-021-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* 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 API Annotations for GADT constructorsAlan Zimmerman2018-06-191-1/+1
| | | | | | | | | | | | | | | | | | | 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
* Typofixes in docs and comments [ci skip]Gabor Greif2018-06-181-1/+1
|
* Embrace -XTypeInType, add -XStarIsTypeVladislav Zavialov2018-06-141-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Introduce DerivingViaRyan Scott2018-06-041-22/+136
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* vectorise: Put it out of its miseryBen Gamari2018-06-021-59/+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
* Used named fields for DataDeclRnSimon Peyton Jones2018-05-081-3/+6
|
* TTG : complete for balance of hsSyn ASTAlan Zimmerman2018-04-271-102/+157
| | | | | | | | | | | | | | | | | | 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
* Fix #14710 with more validity checks during renamingRyan Scott2018-04-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: #14710 revealed two unfortunate regressions related to kind polymorphism that had crept in in recent GHC releases: 1. While GHC was able to catch illegal uses of kind polymorphism (i.e., if `PolyKinds` wasn't enabled) in limited situations, it wasn't able to catch kind polymorphism of the following form: ```lang=haskell f :: forall a. a -> a f x = const x g where g :: Proxy (x :: a) g = Proxy ``` Note that the variable `a` is being used as a kind variable in the type signature of `g`, but GHC happily accepts it, even without the use of `PolyKinds`. 2. If you have `PolyKinds` (but not `TypeInType`) enabled, then GHC incorrectly accepts the following definition: ```lang=haskell f :: forall k (a :: k). Proxy a f = Proxy ``` Even though `k` is explicitly bound and then later used as a kind variable within the same telescope. This patch fixes these two bugs as follows: 1. Whenever we rename any `HsTyVar`, we check if the following three criteria are met: (a) It's a type variable (b) It's used at the kind level (c) `PolyKinds` is not enabled If so, then we have found an illegal use of kind polymorphism, so throw an error. This check replaces the `checkBadKindBndrs` function, which could only catch illegal uses of kind polymorphism in very limited situations (when the bad kind variable happened to be implicitly quantified in the same type signature). 2. In `extract_hs_tv_bndrs`, we must error if `TypeInType` is not enabled and either of the following criteria are met: (a) An explicitly bound type variable is used in kind position in the body of a `forall` type. (b) An explicitly bound type variable is used in kind position in the kind of a bound type variable in a `forall` type. `extract_hs_tv_bndrs` was checking (a), but not (b). Easily fixed. Test Plan: ./validate Reviewers: goldfire, simonpj, bgamari, hvr Reviewed By: simonpj Subscribers: thomie, carter GHC Trac Issues: #14710 Differential Revision: https://phabricator.haskell.org/D4554
* Comments onlySimon Peyton Jones2018-04-171-3/+1
| | | | Deleting misleading comments, to fix Trac #15047
* TTG for HsBinds and Data instances Plan BAlan Zimmerman2018-04-131-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-14/+15
| | | | | | | | | | | | | | | | | | 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
* Allow PartialTypeSignatures in standalone deriving contextsRyan Scott2018-03-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Wombling around in Trac #14808Simon Peyton Jones2018-03-051-3/+6
| | | | | | | | | | | Comment:4 in Trac #14808 explains why I'm unhappy with the current state of affairs -- at least the lack of documentation. This smallpatch does nothing major: * adds comments * uses existing type synonyms more (notably FreeKiTyVarsWithDups) * adds another test case to T14808
* Rename the types in a GADT constructor in toposorted orderRyan Scott2018-02-181-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | Previously, we were extracting the free variables from a GADT constructor in an incorrect order, which caused the type variables for the constructor's type signature to end up in non-toposorted order. Thankfully, rearranging the order of types during renaming makes swift work of this bug. This fixes a regression introduced in commit fa29df02a1b0b926afb2525a258172dcbf0ea460. For whatever reason, that commit also commented out a significant portion of the `T13123` test. This code appears to work, so I've opted to uncomment it. Test Plan: make test TEST=T14808 Reviewers: simonpj, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14808 Differential Revision: https://phabricator.haskell.org/D4413
* Simplify HsPatSynDetailsSimon Peyton Jones2017-12-211-1/+1
| | | | | | This is a pure refactoring. Use HsConDetails to implement HsPatSynDetails, instead of defining a whole new data type. Less code, fewer types, all good.
* Get rid of some stuttering in comments and docsGabor Greif2017-12-191-1/+1
|
* Refactor ConDecl: Trac #14529Simon Peyton Jones2017-12-071-39/+77
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Make use of boot TyThings during typechecking.Edward Z. Yang2017-11-301-120/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Suppose that you are typechecking A.hs, which transitively imports, via B.hs, A.hs-boot. When we poke on B.hs and discover that it has a reference to a type from A, what TyThing should we wire it up with? Clearly, if we have already typechecked A, we should use the most up-to-date TyThing: the one we freshly generated when we typechecked A. But what if we haven't typechecked it yet? For the longest time, GHC adopted the policy that this was *an error condition*; that you MUST NEVER poke on B.hs's reference to a thing defined in A.hs until A.hs has gotten around to checking this. However, actually ensuring this is the case has proven to be a bug farm. The problem was especially poignant with type family consistency checks, which eagerly happen before any typechecking takes place. This patch takes a different strategy: if we ever try to access an entity from A which doesn't exist, we just fall back on the definition of A from the hs-boot file. This means that you may end up with a mix of A.hs and A.hs-boot TyThings during the course of typechecking. Signed-off-by: Edward Z. Yang <ezyang@fb.com> Test Plan: validate Reviewers: simonpj, bgamari, austin, goldfire Subscribers: thomie, rwbarton GHC Trac Issues: #14396 Differential Revision: https://phabricator.haskell.org/D4154
* Revert "trees that grow" workBen Gamari2017-11-211-15/+14
| | | | | | | | | | | | | | As documented in #14490, the Data instances currently blow up compilation time by too much to stomach. Alan will continue working on this in a branch and we will perhaps merge to 8.2 before 8.2.1 to avoid having to perform painful cherry-picks in 8.2 minor releases. Reverts haddock submodule. This reverts commit 47ad6578ea460999b53eb4293c3a3b3017a56d65. This reverts commit e3ec2e7ae94524ebd111963faf34b84d942265b4. This reverts commit 438dd1cbba13d35f3452b4dcef3f94ce9a216905. This reverts commit 0ff152c9e633accca48815e26e59d1af1fe44ceb.
* WIP on combined Step 1 and 3 for Trees That Grow, HsExprAlan Zimmerman2017-11-111-7/+8
| | | | | | | | | | | | | | | | | 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-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | 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-6/+6
| | | | | | | | 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-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix #10816 by renaming FixitySigs more consistentlyRyan Scott2017-10-111-40/+2
| | | | | | | | | | | | | | | | | | | | | Summary: #10816 surfaced because we were renaming top-level fixity declarations with a different code path (`rnSrcFixityDecl`) than the code path for fixity declarations inside of type classes, which is not privy to names that exist in the type namespace. Luckily, the fix is simple: use `rnSrcFixityDecl` in both places. Test Plan: make test TEST=T10816 Reviewers: austin, bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie GHC Trac Issues: #10816 Differential Revision: https://phabricator.haskell.org/D4077
* 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
* Implicitly bind kind variables in type family instance RHSes when it's sensibleRyan Scott2017-09-051-27/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Before, there was a discrepancy in how GHC renamed type synonyms as opposed to type family instances. That is, GHC would accept definitions like this one: ```lang=haskell type T = (Nothing :: Maybe a) ``` However, it would not accept a very similar type family instance: ```lang=haskell type family T :: Maybe a type instance T = (Nothing :: Maybe a) ``` The primary goal of this patch is to bring the renaming of type family instances up to par with that of type synonyms, causing the latter definition to be accepted, and fixing #14131. In particular, we now allow kind variables on the right-hand sides of type (and data) family instances to be //implicitly// bound by LHS type (or kind) patterns (as opposed to type variables, which must always be explicitly bound by LHS type patterns only). As a consequence, this allows programs reported in #7938 and #9574 to typecheck, whereas before they would have been rejected. Implementation-wise, there isn't much trickery involved in making this happen. We simply need to bind additional kind variables from the RHS of a type family in the right place (in particular, see `RnSource.rnFamInstEqn`, which has undergone a minor facelift). While doing this has the upside of fixing #14131, it also made it easier to trigger #13985, so I decided to fix that while I was in town. This was accomplished by a careful blast of `reportFloatingKvs` in `tcFamTyPats`. Test Plan: ./validate Reviewers: simonpj, goldfire, austin, bgamari Reviewed By: simonpj Subscribers: rwbarton, thomie GHC Trac Issues: #13985, #14131 Differential Revision: https://phabricator.haskell.org/D3872
* Refactor type family instance abstract syntax declarationsRyan Scott2017-08-291-50/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Refactor bindHsQTyVars and friendsSimon Peyton Jones2017-08-291-54/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This work was triggered by Trac #13738, which revealed to me that the code RnTypes.bindHsQTyVars and bindLHsTyVarBndrs was a huge tangled mess -- and outright wrong on occasion as the ticket showed. The big problem was that bindLHsTyVarBndrs (which is invoked at every HsForAll, including nested higher rank ones) was attempting to bind implicit kind variables, which it has absolutely no busineess doing. Imlicit kind quantification is done at the outside only, in fact precisely where we have HsImplicitBndrs or LHsQTyVars (which also has implicit binders). Achieving this move was surprisingly hard, because more and more barnacles had accreted aroud the original mistake. It's much much better now. Summary of changes. Almost all the action is in RnTypes. * Implicit kind variables are bound only by - By bindHsQTyVars, which deals with LHsQTyVars - By rnImplicitBndrs, which deals with HsImplicitBndrs * bindLHsTyVarBndrs, and bindLHsTyVarBndr are radically simplified. They simply does far less, and have lots their forest of incomprehensible accumulating parameters. (To be fair, some of the code in bindLHsTyVarBndrs just moved to bindHsQTyVars, but in much more perspicuous form.) * The code that checks if a variable appears in both a kind and a type (triggering RnTypes.mixedVarsErr) was bizarre. E.g. we had this in RnTypes.extract_hs_tv_bndrs ; check_for_mixed_vars bndr_kvs acc_tvs ; check_for_mixed_vars bndr_kvs body_tvs ; check_for_mixed_vars body_tvs acc_kvs ; check_for_mixed_vars body_kvs acc_tvs ; check_for_mixed_vars locals body_kvs I cleaned all this up; now we check for mixed use at binding sites only. * Checks for "Variable used as a kind before being bound", like data T (a :: k) k = rhs now just show up straightforwardly as "k is not in scope". See Note [Kind variable ordering] * There are some knock-on simplifications in RnSource.
* Use NonEmpty lists to represent lists of duplicate elementsRyan Scott2017-08-121-10/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Three functions in `ListSetOps` which compute duplicate elements represent lists of duplicates of `[a]`. This is a really bad way to go about things, because these lists are guaranteed to always have at least one element (the "representative" of the duplicates), and several places in the GHC API call `head` (a partial function) on these lists of duplicates to retrieve the representative. This changes the representation of duplicates to `NonEmpty` lists instead, which allow for many partial uses of `head` to be made total. Fixes #13823. Test Plan: ./validate Reviewers: bgamari, austin, goldfire Reviewed By: bgamari Subscribers: goldfire, rwbarton, thomie GHC Trac Issues: #13823 Differential Revision: https://phabricator.haskell.org/D3823
* Fix ungrammatical error messageRyan Scott2017-07-211-1/+1
| | | | | | | | | | | | Test Plan: If it builds, ship it Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3772
* Udate hsSyn AST to use Trees that GrowAlan Zimmerman2017-06-061-89/+98
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: See https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow This commit prepares the ground for a full extensible AST, by replacing the type parameter for the hsSyn data types with a set of indices into type families, data GhcPs -- ^ Index for GHC parser output data GhcRn -- ^ Index for GHC renamer output data GhcTc -- ^ Index for GHC typechecker output These are now used instead of `RdrName`, `Name` and `Id`/`TcId`/`Var` Where the original name type is required in a polymorphic context, this is accessible via the IdP type family, defined as type family IdP p type instance IdP GhcPs = RdrName type instance IdP GhcRn = Name type instance IdP GhcTc = Id These types are declared in the new 'hsSyn/HsExtension.hs' module. To gain a better understanding of the extension mechanism, it has been applied to `HsLit` only, also replacing the `SourceText` fields in them with extension types. To preserve extension generality, a type class is introduced to capture the `SourceText` interface, which must be honoured by all of the extension points which originally had a `SourceText`. The class is defined as class HasSourceText a where -- Provide setters to mimic existing constructors noSourceText :: a sourceText :: String -> a setSourceText :: SourceText -> a getSourceText :: a -> SourceText And the constraint is captured in `SourceTextX`, which is a constraint type listing all the extension points that make use of the class. Updating Haddock submodule to match. Test Plan: ./validate Reviewers: simonpj, shayan-najd, goldfire, austin, bgamari Subscribers: rwbarton, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D3609
* Split up RnEnv into 4 modules, RnUnbound, RnUtils and RnFixityMatthew Pickering2017-04-121-0/+5
| | | | | | | | | | | | | | | | | | | Summary: RnEnv contains functions which convertn RdrNames into Names. RnUnbound contains helper functions for reporting and creating unbound variables. RnFixity contains code which maintains the fixity environent whilst renaming. RnUtils contains the other stuff in RnEnv. Reviewers: austin, goldfire, bgamari Subscribers: goldfire, rwbarton, thomie, snowleopard Differential Revision: https://phabricator.haskell.org/D3436
* Replace Digraph's Node type synonym with a data typeMatthew Pickering2017-04-041-2/+3
| | | | | | | | | | | | | This refactoring makes it more obvious when we are constructing a Node for the digraph rather than a less useful 3-tuple. Reviewers: austin, goldfire, bgamari, simonmar, dfeuer Reviewed By: dfeuer Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3414
* Fix #13337.Richard Eisenberg2017-03-141-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The big change is the introduction of solveSomeEqualities. This is just like solveEqualities, but it doesn't fail if there are unsolved equalities when it's all done. Anything unsolved is re-emitted. This is appropriate if we are not kind-generalizing, so this new form is used when decideKindGeneralizationPlan says not to. We initially thought that any use of solveEqualities would be tied to kind generalization, but this isn't true. For example, we need to solveEqualities a bunch in the "tc" pass in TcTyClsDecls (which is really desugaring). These equalities are all surely going to be soluble (if they weren't the "kc" pass would fail), but we still need to solve them again. Perhaps if the "kc" pass produced type- checked output that is then desugared, solveEqualities really would be tied only to kind generalization. Updates haddock submodule. Test Plan: ./validate, typecheck/should_compile/T13337 Reviewers: simonpj, bgamari, austin Reviewed By: simonpj Subscribers: RyanGlScott, rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3315
* Upgrade UniqSet to a newtypeDavid Feuer2017-03-011-3/+3
| | | | | | | | | | | | | | | | | | | | | The fundamental problem with `type UniqSet = UniqFM` is that `UniqSet` has a key invariant `UniqFM` does not. For example, `fmap` over `UniqSet` will generally produce nonsense. * Upgrade `UniqSet` from a type synonym to a newtype. * Remove unused and shady `extendVarSet_C` and `addOneToUniqSet_C`. * Use cached unique in `tyConsOfType` by replacing `unitNameEnv (tyConName tc) tc` with `unitUniqSet tc`. Reviewers: austin, hvr, goldfire, simonmar, niteria, bgamari Reviewed By: niteria Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3146
* Type-indexed TypeableBen Gamari2017-02-181-16/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This at long last realizes the ideas for type-indexed Typeable discussed in A Reflection on Types (#11011). The general sketch of the project is described on the Wiki (Typeable/BenGamari). The general idea is that we are adding a type index to `TypeRep`, data TypeRep (a :: k) This index allows the typechecker to reason about the type represented by the `TypeRep`. This index representation mechanism is exposed as `Type.Reflection`, which also provides a number of patterns for inspecting `TypeRep`s, ```lang=haskell pattern TRFun :: forall k (fun :: k). () => forall (r1 :: RuntimeRep) (r2 :: RuntimeRep) (arg :: TYPE r1) (res :: TYPE r2). (k ~ Type, fun ~~ (arg -> res)) => TypeRep arg -> TypeRep res -> TypeRep fun pattern TRApp :: forall k2 (t :: k2). () => forall k1 (a :: k1 -> k2) (b :: k1). (t ~ a b) => TypeRep a -> TypeRep b -> TypeRep t -- | Pattern match on a type constructor. pattern TRCon :: forall k (a :: k). TyCon -> TypeRep a -- | Pattern match on a type constructor including its instantiated kind -- variables. pattern TRCon' :: forall k (a :: k). TyCon -> [SomeTypeRep] -> TypeRep a ``` In addition, we give the user access to the kind of a `TypeRep` (#10343), typeRepKind :: TypeRep (a :: k) -> TypeRep k Moreover, all of this plays nicely with 8.2's levity polymorphism, including the newly levity polymorphic (->) type constructor. Library changes --------------- The primary change here is the introduction of a Type.Reflection module to base. This module provides access to the new type-indexed TypeRep introduced in this patch. We also continue to provide the unindexed Data.Typeable interface, which is simply a type synonym for the existentially quantified SomeTypeRep, data SomeTypeRep where SomeTypeRep :: TypeRep a -> SomeTypeRep Naturally, this change also touched Data.Dynamic, which can now export the Dynamic data constructor. Moreover, I removed a blanket reexport of Data.Typeable from Data.Dynamic (which itself doesn't even import Data.Typeable now). We also add a kind heterogeneous type equality type, (:~~:), to Data.Type.Equality. Implementation -------------- The implementation strategy is described in Note [Grand plan for Typeable] in TcTypeable. None of it was difficult, but it did exercise a number of parts of the new levity polymorphism story which had not yet been exercised, which took some sorting out. The rough idea is that we augment the TyCon produced for each type constructor with information about the constructor's kind (which we call a KindRep). This allows us to reconstruct the monomorphic result kind of an particular instantiation of a type constructor given its kind arguments. Unfortunately all of this takes a fair amount of work to generate and send through the compilation pipeline. In particular, the KindReps can unfortunately get quite large. Moreover, the simplifier will float out various pieces of them, resulting in numerous top-level bindings. Consequently we mark the KindRep bindings as noinline, ensuring that the float-outs don't make it into the interface file. This is important since there is generally little benefit to inlining KindReps and they would otherwise strongly affect compiler performance. Performance ----------- Initially I was hoping to also clear up the remaining holes in Typeable's coverage by adding support for both unboxed tuples (#12409) and unboxed sums (#13276). While the former was fairly straightforward, the latter ended up being quite difficult: while the implementation can support them easily, enabling this support causes thousands of Typeable bindings to be emitted to the GHC.Types as each arity-N sum tycon brings with it N promoted datacons, each of which has a KindRep whose size which itself scales with N. Doing this was simply too expensive to be practical; consequently I've disabled support for the time being. Even after disabling sums this change regresses compiler performance far more than I would like. In particular there are several testcases in the testsuite which consist mostly of types which regress by over 30% in compiler allocations. These include (considering the "bytes allocated" metric), * T1969: +10% * T10858: +23% * T3294: +19% * T5631: +41% * T6048: +23% * T9675: +20% * T9872a: +5.2% * T9872d: +12% * T9233: +10% * T10370: +34% * T12425: +30% * T12234: +16% * 13035: +17% * T4029: +6.1% I've spent quite some time chasing down the source of this regression and while I was able to make som improvements, I think this approach of generating Typeable bindings at time of type definition is doomed to give us unnecessarily large compile-time overhead. In the future I think we should consider moving some of all of the Typeable binding generation logic back to the solver (where it was prior to 91c6b1f54aea658b0056caec45655475897f1972). I've opened #13261 documenting this proposal.
View Lorry Controller Status