summaryrefslogtreecommitdiff
path: root/compiler/rename
Commit message (Collapse)AuthorAgeFilesLines
* Use DeriveFunctor throughout the codebase (#15654)Krzysztof Gogolewski2019-06-121-4/+3
|
* Refine the GHCI macro into HAVE[_{INTERNAL, EXTERNAL}]_INTERPRETERAlp Mestanogullari2019-06-111-1/+1
| | | | | | | | | | | | | | | | | As discussed in #16331, the GHCI macro, defined through 'ghci' flags in ghc.cabal.in, ghc-bin.cabal.in and ghci.cabal.in, is supposed to indicate whether GHC is built with support for an internal interpreter, that runs in the same process. It is however overloaded in a few places to mean "there is an interpreter available", regardless of whether it's an internal or external interpreter. For the sake of clarity and with the hope of more easily being able to build stage 1 GHCs with external interpreter support, this patch splits the previous GHCI macro into 3 different ones: - HAVE_INTERNAL_INTERPRETER: GHC is built with an internal interpreter - HAVE_EXTERNAL_INTERPRETER: GHC is built with support for external interpreters - HAVE_INTERPRETER: HAVE_INTERNAL_INTERPRETER || HAVE_EXTERNAL_INTERPRETER
* Do not report error if Name in pragma is unboundnineonine2019-06-091-1/+4
|
* Use HsTyPats in associated type family defaultsRyan Scott2019-05-221-51/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Associated type family default declarations behave strangely in a couple of ways: 1. If one tries to bind the type variables with an explicit `forall`, the `forall`'d part will simply be ignored. (#16110) 2. One cannot use visible kind application syntax on the left-hand sides of associated default equations, unlike every other form of type family equation. (#16356) Both of these issues have a common solution. Instead of using `LHsQTyVars` to represent the left-hand side arguments of an associated default equation, we instead use `HsTyPats`, which is what other forms of type family equations use. In particular, here are some highlights of this patch: * `FamEqn` is no longer parameterized by a `pats` type variable, as the `feqn_pats` field is now always `HsTyPats`. * The new design for `FamEqn` in chronicled in `Note [Type family instance declarations in HsSyn]`. * `TyFamDefltEqn` now becomes the same thing as `TyFamInstEqn`. This means that many of `TyFamDefltEqn`'s code paths can now reuse the code paths for `TyFamInstEqn`, resulting in substantial simplifications to various parts of the code dealing with associated type family defaults. Fixes #16110 and #16356.
* Guard CUSKs behind a language pragmaVladislav Zavialov2019-05-141-1/+2
| | | | | | | | | | | | | | GHC Proposal #36 describes a transition plan away from CUSKs and to top-level kind signatures: 1. Introduce a new extension, -XCUSKs, on by default, that detects CUSKs as they currently exist. 2. We turn off the -XCUSKs extension in a few releases and remove it sometime thereafter. This patch implements phase 1 of this plan, introducing a new language extension to control whether CUSKs are enabled. When top-level kind signatures are implemented, we can transition to phase 2.
* Implement ImportQualifiedPostShayne Fletcher2019-05-081-3/+5
|
* Pattern/expression ambiguity resolutionVladislav Zavialov2019-05-031-27/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch removes 'EWildPat', 'EAsPat', 'EViewPat', and 'ELazyPat' from 'HsExpr' by using the ambiguity resolution system introduced earlier for the command/expression ambiguity. Problem: there are places in the grammar where we do not know whether we are parsing an expression or a pattern, for example: do { Con a b <- x } -- 'Con a b' is a pattern do { Con a b } -- 'Con a b' is an expression Until we encounter binding syntax (<-) we don't know whether to parse 'Con a b' as an expression or a pattern. The old solution was to parse as HsExpr always, and rejig later: checkPattern :: LHsExpr GhcPs -> P (LPat GhcPs) This meant polluting 'HsExpr' with pattern-related constructors. In other words, limitations of the parser were affecting the AST, and all other code (the renamer, the typechecker) had to deal with these extra constructors. We fix this abstraction leak by parsing into an overloaded representation: class DisambECP b where ... newtype ECP = ECP { runECP_PV :: forall b. DisambECP b => PV (Located b) } See Note [Ambiguous syntactic categories] for details. Now the intricacies of parsing have no effect on the hsSyn AST when it comes to the expression/pattern ambiguity.
* Use pp_itemWojciech Baranowski2019-04-291-3/+1
|
* Suggest only local candidates from global envWojciech Baranowski2019-04-291-2/+4
|
* Comment on 'candidates' functionWojciech Baranowski2019-04-291-0/+2
|
* osa1's patch: consistent suggestion messageWojciech Baranowski2019-04-291-3/+4
|
* Print suggestions in a single messageWojciech Baranowski2019-04-291-5/+7
|
* rename: hadle type signatures with typosWojciech Baranowski2019-04-291-2/+18
| | | | | | | When encountering type signatures for unknown names, suggest similar alternatives. This fixes issue #16504
* Update Wiki URLs to point to GitLabTakenobu Tani2019-03-252-2/+2
| | | | | | | | | | | | | | | | | | | | | | | This moves all URL references to Trac Wiki to their corresponding GitLab counterparts. This substitution is classified as follows: 1. Automated substitution using sed with Ben's mapping rule [1] Old: ghc.haskell.org/trac/ghc/wiki/XxxYyy... New: gitlab.haskell.org/ghc/ghc/wikis/xxx-yyy... 2. Manual substitution for URLs containing `#` index Old: ghc.haskell.org/trac/ghc/wiki/XxxYyy...#Zzz New: gitlab.haskell.org/ghc/ghc/wikis/xxx-yyy...#zzz 3. Manual substitution for strings starting with `Commentary` Old: Commentary/XxxYyy... New: commentary/xxx-yyy... See also !539 [1]: https://gitlab.haskell.org/bgamari/gitlab-migration/blob/master/wiki-mapping.json
* base: Remove `Monad(fail)` method and reexport `MonadFail(fail)` insteadHerbert Valerio Riedel2019-03-222-54/+6
| | | | | | As per https://prime.haskell.org/wiki/Libraries/Proposals/MonadFail Coauthored-by: Ben Gamari <ben@well-typed.com>
* Update Trac ticket URLs to point to GitLabRyan Scott2019-03-1510-51/+51
| | | | | This moves all URL references to Trac tickets to their corresponding GitLab counterparts.
* Stop inferring over-polymorphic kindsSimon Peyton Jones2019-03-092-15/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | Before this patch GHC was trying to be too clever (Trac #16344); it succeeded in kind-checking this polymorphic-recursive declaration data T ka (a::ka) b = MkT (T Type Int Bool) (T (Type -> Type) Maybe Bool) As Note [No polymorphic recursion] discusses, the "solution" was horribly fragile. So this patch deletes the key lines in TcHsType, and a wodge of supporting stuff in the renamer. There were two regressions, both the same: a closed type family decl like this (T12785b) does not have a CUSK: type family Payload (n :: Peano) (s :: HTree n x) where Payload Z (Point a) = a Payload (S n) (a `Branch` stru) = a To kind-check the equations we need a dependent kind for Payload, and we don't get that any more. Solution: make it a CUSK by giving the result kind -- probably a good thing anyway. The other case (T12442) was very similar: a close type family declaration without a CUSK.
* Fix #16385 by appending _maybe to a use of lookupGlobalOccRyan Scott2019-03-061-8/+24
| | | | | | | | | `instance forall c. c` claimed that `c` was out of scope because the renamer was invoking `lookupGlobalOcc` on `c` (in `RnNames.getLocalNonValBinders`) without binding `c` first. To avoid this, this patch changes GHC to invoke `lookupGlobalOcc_maybe` on `c` instead, and if that returns `Nothing`, then bail out, resulting in a better error message.
* Be more careful when naming TyCon bindersSimon Peyton Jones2019-03-051-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes two rather gnarly test cases: * Trac #16342 (mutual recursion) See Note [Tricky scoping in generaliseTcTyCon] * Trac #16221 (shadowing) See Note [Unification variables need fresh Names] The main changes are: * Substantial reworking of TcTyClsDecls.generaliseTcTyCon This is the big change, and involves the rather tricky function TcHsSyn.zonkRecTyVarBndrs. See Note [Inferring kinds for type declarations] and Note [Tricky scoping in generaliseTcTyCon] for the details. * bindExplicitTKBndrs_Tv and bindImplicitTKBndrs_Tv both now allocate /freshly-named/ unification variables. Indeed, more generally, unification variables are always fresh; see Note [Unification variables need fresh Names] in TcMType * Clarify the role of tcTyConScopedTyVars. See Note [Scoped tyvars in a TcTyCon] in TyCon As usual, this dragged in some more refactoring: * Renamed TcMType.zonkTyCoVarBndr to zonkAndSkolemise * I renamed checkValidTelescope to checkTyConTelescope; it's only used on TyCons, and indeed takes a TyCon as argument. * I folded the slightly-mysterious reportFloatingKvs into checkTyConTelescope. (Previously all its calls immediately followed a call to checkTyConTelescope.) It makes much more sense there. * I inlined some called-once functions to simplify checkValidTyFamEqn. It's less spaghetti-like now. * This patch also fixes Trac #16251. I'm not quite sure why #16251 went wrong in the first place, nor how this patch fixes it, but hey, it's good, and life is short.
* Visible dependent quantificationRyan Scott2019-03-011-6/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This implements GHC proposal 35 (https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0035-forall-arrow.rst) by adding the ability to write kinds with visible dependent quantification (VDQ). Most of the work for supporting VDQ was actually done _before_ this patch. That is, GHC has been able to reason about kinds with VDQ for some time, but it lacked the ability to let programmers directly write these kinds in the source syntax. This patch is primarly about exposing this ability, by: * Changing `HsForAllTy` to add an additional field of type `ForallVisFlag` to distinguish between invisible `forall`s (i.e, with dots) and visible `forall`s (i.e., with arrows) * Changing `Parser.y` accordingly The rest of the patch mostly concerns adding validity checking to ensure that VDQ is never used in the type of a term (as permitting this would require full-spectrum dependent types). This is accomplished by: * Adding a `vdqAllowed` predicate to `TcValidity`. * Introducing `splitLHsSigmaTyInvis`, a variant of `splitLHsSigmaTy` that only splits invisible `forall`s. This function is used in certain places (e.g., in instance declarations) to ensure that GHC doesn't try to split visible `forall`s (e.g., if it tried splitting `instance forall a -> Show (Blah a)`, then GHC would mistakenly allow that declaration!) This also updates Template Haskell by introducing a new `ForallVisT` constructor to `Type`. Fixes #16326. Also fixes #15658 by documenting this feature in the users' guide.
* Treat kind/type variables identically, demolish FKTVVladislav Zavialov2019-02-272-295/+201
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implements GHC Proposal #24: .../ghc-proposals/blob/master/proposals/0024-no-kind-vars.rst Fixes Trac #16334, Trac #16315 With this patch, scoping rules for type and kind variables have been unified: kind variables no longer receieve special treatment. This simplifies both the language and the implementation. User-facing changes ------------------- * Kind variables are no longer implicitly quantified when an explicit forall is used: p :: Proxy (a :: k) -- still accepted p :: forall k a. Proxy (a :: k) -- still accepted p :: forall a. Proxy (a :: k) -- no longer accepted In other words, now we adhere to the "forall-or-nothing" rule more strictly. Related function: RnTypes.rnImplicitBndrs * The -Wimplicit-kind-vars warning has been deprecated. * Kind variables are no longer implicitly quantified in constructor declarations: data T a = T1 (S (a :: k) | forall (b::k). T2 (S b) -- no longer accepted data T (a :: k) = T1 (S (a :: k) | forall (b::k). T2 (S b) -- still accepted Related function: RnTypes.extractRdrKindSigVars * Implicitly quantified kind variables are no longer put in front of other variables: f :: Proxy (a :: k) -> Proxy (b :: j) f :: forall k j (a :: k) (b :: j). Proxy a -> Proxy b -- old order f :: forall k (a :: k) j (b :: j). Proxy a -> Proxy b -- new order This is a breaking change for users of TypeApplications. Note that we still respect the dpendency order: 'k' before 'a', 'j' before 'b'. See "Ordering of specified variables" in the User's Guide. Related function: RnTypes.rnImplicitBndrs * In type synonyms and type family equations, free variables on the RHS are no longer implicitly quantified unless used in an outermost kind annotation: type T = Just (Nothing :: Maybe a) -- no longer accepted type T = Just Nothing :: Maybe (Maybe a) -- still accepted The latter form is a workaround due to temporary lack of an explicit quantification method. Ideally, we would write something along these lines: type T @a = Just (Nothing :: Maybe a) Related function: RnTypes.extractHsTyRdrTyVarsKindVars * Named wildcards in kinds are fixed (Trac #16334): x :: (Int :: _t) -- this compiles, infers (_t ~ Type) Related function: RnTypes.partition_nwcs Implementation notes -------------------- * One of the key changes is the removal of FKTV in RnTypes: - data FreeKiTyVars = FKTV { fktv_kis :: [Located RdrName] - , fktv_tys :: [Located RdrName] } + type FreeKiTyVars = [Located RdrName] We used to keep track of type and kind variables separately, but now that they are on equal footing when it comes to scoping, we can put them in the same list. * extract_lty and family are no longer parametrized by TypeOrKind, as we now do not distinguish kind variables from type variables. * PatSynExPE and the related Note [Pattern synonym existentials do not scope] have been removed (Trac #16315). With no implicit kind quantification, we can no longer trigger the error. * reportFloatingKvs and the related Note [Free-floating kind vars] have been removed. With no implicit kind quantification, we can no longer trigger the error.
* Expression/command ambiguity resolutionVladislav Zavialov2019-02-231-12/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch removes 'HsArrApp' and 'HsArrForm' from 'HsExpr' by introducing a new ambiguity resolution system in the parser. Problem: there are places in the grammar where we do not know whether we are parsing an expression or a command: proc x -> do { (stuff) -< x } -- 'stuff' is an expression proc x -> do { (stuff) } -- 'stuff' is a command Until we encounter arrow syntax (-<) we don't know whether to parse 'stuff' as an expression or a command. The old solution was to parse as HsExpr always, and rejig later: checkCommand :: LHsExpr GhcPs -> P (LHsCmd GhcPs) This meant polluting 'HsExpr' with command-related constructors. In other words, limitations of the parser were affecting the AST, and all other code (the renamer, the typechecker) had to deal with these extra constructors by panicking. We fix this abstraction leak by parsing into an intermediate representation, 'ExpCmd': data ExpCmdG b where ExpG :: ExpCmdG HsExpr CmdG :: ExpCmdG HsCmd type ExpCmd = forall b. ExpCmdG b -> PV (Located (b GhcPs)) checkExp :: ExpCmd -> PV (LHsExpr GhcPs) checkCmd :: ExpCmd -> PV (LHsCmd GhcPs) checkExp f = f ExpG -- interpret as an expression checkCmd f = f CmdG -- interpret as a command See Note [Ambiguous syntactic categories] for details. Now the intricacies of parsing have no effect on the hsSyn AST when it comes to the expression/command ambiguity. Future work: apply the same principles to the expression/pattern ambiguity.
* 'forall' always a keyword, plus the dot type operatorVladislav Zavialov2019-02-152-19/+4
|
* Implement -Wredundant-record-wildcards and -Wunused-record-wildcardsMatthew Pickering2019-02-144-10/+106
| | | | | | | | | -Wredundant-record-wildcards warns when a .. pattern binds no variables. -Wunused-record-wildcards warns when none of the variables bound by a .. pattern are used. These flags are enabled by `-Wall`.
* API Annotations: AnnAt disconnected for TYPEAPPAlan Zimmerman2019-02-081-5/+5
| | | | | | | | | | | | For the code type family F1 (a :: k) (f :: k -> Type) :: Type where F1 @Peano a f = T @Peano f a the API annotation for the first @ is not attached to a SourceSpan in the ParsedSource Closes #16236
* Fix #16116 by removing badAssocRhsRyan Scott2019-01-151-15/+15
|
* Fix #16114 by adding a validity check to rnClsInstDeclRyan Scott2019-01-152-13/+20
|
* Run typed splices in the zonkerMatthew Pickering2019-01-111-2/+10
| | | | | | | | | | | | | | | | | Summary: This fixes #15471 In the typechecker we check that the splice has the right type but we crucially don't zonk the generated expression. This is because we might end up unifying type variables from outer scopes later on. Reviewers: simonpj, goldfire, bgamari Subscribers: rwbarton, carter GHC Trac Issues: #15471 Differential Revision: https://phabricator.haskell.org/D5286
* Fix #16133 by checking for TypeApplications in rnExprRyan Scott2019-01-063-9/+13
|
* Add -Wmissing-deriving-strategieschessai2019-01-061-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
* Visible kind applicationmynguyen2019-01-032-81/+63
| | | | | | | | | | | | | | | | | | | | | | | Summary: This patch implements visible kind application (GHC Proposal 15/#12045), as well as #15360 and #15362. It also refactors unnamed wildcard handling, and requires that type equations in type families in Template Haskell be written with full type on lhs. PartialTypeSignatures are on and warnings are off automatically with visible kind application, just like in term-level. There are a few remaining issues with this patch, as documented in ticket #16082. Includes a submodule update for Haddock. Test Plan: Tests T12045a/b/c/TH1/TH2, T15362, T15592a Reviewers: simonpj, goldfire, bgamari, alanz, RyanGlScott, Iceland_jack Subscribers: ningning, Iceland_jack, RyanGlScott, int-index, rwbarton, mpickering, carter GHC Trac Issues: `#12045`, `#15362`, `#15592`, `#15788`, `#15793`, `#15795`, `#15797`, `#15799`, `#15801`, `#15807`, `#15816` Differential Revision: https://phabricator.haskell.org/D5229
* 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
* Enable rebindable fail with overloaded stringsShayne Fletcher2018-12-111-21/+75
| | | | | | | | | | | | | | 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
* Misleading msg with qualified imports "No module named X imported"Roland Senn2018-12-111-22/+28
| | | | | | | | | | | | | | | | | | | | To check whether a given module has been imported, we do the following: From the list of all qualified names we extract the distinct module names to a list of module names. Then we check whether the given module name is in this list of module names. Test Plan: make test TEST=T14225 Reviewers: mpickering, hvr, monoidal, osa1, bgamari Reviewed By: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #14225 Differential Revision: https://phabricator.haskell.org/D5331
* 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-249-252/+315
| | | | | | | | | | | | | | | | | | 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-224-117/+138
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Respect naming conventions in module RnUnbound.hs in fix for #15611Roland Senn2018-11-111-11/+11
| | | | | | | | | | | | | | | | | | | | | | | | Summary: The patch https://phabricator.haskell.org/D5284 didn't respect the local naming conventions in module compiler/rename/RnUnbound.hs: - Top level functions names are written in camelCase. - Local function names in where clauses are written as names_with_underscores. This patch restores these conventions. Test Plan: make test TESTS="T15611a T15611b" Reviewers: DavidEichmann, monoidal, hvr, mpickering, bgamari Reviewed By: mpickering Subscribers: rwbarton, carter GHC Trac Issues: #15611 Differential Revision: https://phabricator.haskell.org/D5308
* Fix for Trac #15611: Scope errors lie about what modules are imported.roland2018-11-041-6/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: For the error message: Not in scope X.Y Module X does not export Y No module named ‘X’ is imported: there are 2 cases, where we don't show the last "no module named is imported" line: 1. If the module X has been imported. 2. If the module X is the current module. There are 2 subcases: 2.1 If the unknown module name is in a input source file, then we can use the getModule function to get the current module name. 2.2 If the unknown module name has been entered by the user in GHCi, then the getModule function returns something like "interactive:Ghci1", and we have to check the current module in the last added entry of the HomePackageTable. Test Plan: make test TESTS="T15611a T15611b" Reviewers: monoidal, hvr, thomie, dfeuer, bgamari, DavidEichmann Reviewed By: monoidal, DavidEichmann Subscribers: rwbarton, carter GHC Trac Issues: #15611 Differential Revision: https://phabricator.haskell.org/D5284
* Finish fix for #14880.Tobias Dammers2018-10-281-13/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The real change that fixes the ticket is described in Note [Naughty quantification candidates] in TcMType. Fixing this required reworking candidateQTyVarsOfType, the function that extracts free variables as candidates for quantification. One consequence is that we now must be more careful when quantifying: any skolems around must be quantified manually, and quantifyTyVars will now only quantify over metavariables. This makes good sense, as skolems are generally user-written and are listed in the AST. As a bonus, we now have more control over the ordering of such skolems. Along the way, this commit fixes #15711 and refines the fix to #14552 (by accepted a program that was previously rejected, as we can now accept that program by zapping variables to Any). This commit also does a fair amount of rejiggering kind inference of datatypes. Notably, we now can skip the generalization step in kcTyClGroup for types with CUSKs, because we get the kind right the first time. This commit also thus fixes #15743 and #15592, which both concern datatype kind generalisation. (#15591 is also very relevant.) For this aspect of the commit, see Note [Required, Specified, and Inferred in types] in TcTyClsDecls. Test cases: dependent/should_fail/T14880{,-2}, dependent/should_fail/T15743[cd] dependent/should_compile/T15743{,e} ghci/scripts/T15743b polykinds/T15592 dependent/should_fail/T15591[bc] ghci/scripts/T15591
* More explicit foralls (GHC Proposal 0007)Matthew Yacavone2018-10-276-77/+126
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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-262-109/+101
| | | | | | | | | | | 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.
* Make TcRnMonad independent of TcSplice (#14391)Krzysztof Gogolewski2018-10-041-4/+11
| | | | | | | | | | | | | | Test Plan: validate Reviewers: simonpj, bgamari Reviewed By: simonpj Subscribers: rwbarton, carter GHC Trac Issues: #14391 Differential Revision: https://phabricator.haskell.org/D5135
* Improve generated `GHC.Prim` docsAlec Theriault2018-10-041-2/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: * Extended `genprimcode` to generate Haddock-compatible deprecations, as well as displaying information about which functions are LLVM-only and which functions can fail with an unchecked exception. * Ported existing deprecations to the new format, and also added a deprecation on `par#` (see Trac #15227). * Emit an error on fixity/deprecation of builtins, unless we are processing the module in which that name is defined (see Trac #15233). That means the following is no longer accepted (outside of `GHC.Types`): ``` infixr 7 : {-# DEPRECATED (:) "cons is deprecated" #-} ``` * Generate `data (->) a b` with docs and fixity in `GHC.Prim`. This means: GHC can now parse `data (->) a b` and `infixr 0 ->` (only in `GHC.Prim`) and `genprimcode` can digest `primtype (->) a b` (See Trac #4861) as well as some misc fixes along the way. Reviewers: bgamari, RyanGlScott Reviewed By: RyanGlScott Subscribers: RyanGlScott, rwbarton, mpickering, carter GHC Trac Issues: #15227, #15233, #4861 Differential Revision: https://phabricator.haskell.org/D5167
* Don't show constraint tuples in errors (#14907)Alec Theriault2018-09-251-2/+2
| | | | | | | | | | | | | | | | | | | | | Summary: This means that 'GHC.Classes.(%,%)' is no longer mentioned in error messages for things like class (a,b,c) -- outside of 'GHC.Classes' class (a,Bool) Test Plan: make TEST=T14907a && make TEST=T14907b Reviewers: RyanGlScott, bgamari Reviewed By: RyanGlScott Subscribers: rwbarton, carter GHC Trac Issues: #14907 Differential Revision: https://phabricator.haskell.org/D5172
* Don't look up unnecessary return in LastStmtSimon Peyton Jones2018-09-231-5/+17
| | | | | | 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-232-9/+10
| | | | | | | | 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.
* Rename kind vars in left-to-right order in bindHsQTyVarsRyan Scott2018-08-281-9/+77
| | | | | | | | | | | | | | | | | | | | 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
* Replace most occurences of foldl with foldl'.klebinger.andreas@gmx.at2018-08-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds foldl' to GhcPrelude and changes must occurences of foldl to foldl'. This leads to better performance especially for quick builds where GHC does not perform strictness analysis. It does change strictness behaviour when we use foldl' to turn a argument list into function applications. But this is only a drawback if code looks ONLY at the last argument but not at the first. And as the benchmarks show leads to fewer allocations in practice at O2. Compiler performance for Nofib: O2 Allocations: -1 s.d. ----- -0.0% +1 s.d. ----- -0.0% Average ----- -0.0% O2 Compile Time: -1 s.d. ----- -2.8% +1 s.d. ----- +1.3% Average ----- -0.8% O0 Allocations: -1 s.d. ----- -0.2% +1 s.d. ----- -0.1% Average ----- -0.2% Test Plan: ci Reviewers: goldfire, bgamari, simonmar, tdammers, monoidal Reviewed By: bgamari, monoidal Subscribers: tdammers, rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4929
View Lorry Controller Status