summaryrefslogtreecommitdiff
path: root/compiler/deSugar
Commit message (Collapse)AuthorAgeFilesLines
* Support registering Plugins through the GHC APIDaniel Gröber2018-12-111-1/+1
| | | | | | | | | | | | | | | | | This allows tooling using the GHC API to use plugins internally. Hopefully this will make it possible to decouple the development of useful plugins from (currently) kitchen-sink type tooling projects such as ghc-mod or HIE -- at least to some extent. Test Plan: validate Reviewers: bgamari, mpickering Subscribers: mpickering, alanz, rwbarton, carter GHC Trac Issues: #15826 Differential Revision: https://phabricator.haskell.org/D5278
* Warn on all out-of-range literals in pats/exprsAlec Theriault2018-12-035-88/+181
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: These changes were motivated by #13256. While poking around, I realized we weren't very consistent in our "-Woverflowed-literals" warnings. This patch fixes that by: * warning earlier on in the pipeline (ie. before we've desugared 'Int' patterns into 'I# Int#') * handling 'HsLit' as well as 'HsOverLit' (this covers unboxed literals) * covering more pattern / expression forms 4/6 of the warnings in the 'Overflow' test are due to this patch. The other two are mostly for completeness. Also fixed a missing empty-enumeration warning for 'Natural'. This warnings were tripped up by the 'Bounded Word' instance (see #9505), but the fix was obvious and simple: use unboxed word literals. Test Plan: make TEST=Overflow && make TEST=T10930 Reviewers: hvr, bgamari, RyanGlScott Reviewed By: RyanGlScott Subscribers: RyanGlScott, rwbarton, carter GHC Trac Issues: #13256, #10930 Differential Revision: https://phabricator.haskell.org/D5181
* Fix #15953 by consistently using dumpIfSet_dyn to print debug outputChaitanya Koparkar2018-11-291-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | Summary: In some modules we directly dump the debugging output to STDOUT via 'putLogMsg', 'printInfoForUser' etc. However, if `-ddump-to-file` is enabled, that output should be written to a file. Easily fixed. Certain tests (T3017, Roles3, T12763 etc.) expect part of the output generated by `-ddump-types` to be in 'PprUser' style. However, generally we want all other debugging output to use 'PprDump' style. `traceTcRn` and `traceTcRnForUser` help us accomplish this. This patch also documents some missing flags in the users guide. Reviewers: RyanGlScott, bgamari, hvr Reviewed By: RyanGlScott Subscribers: rwbarton, carter GHC Trac Issues: #15953 Differential Revision: https://phabricator.haskell.org/D5382
* [TTG: Handling Source Locations] Foundation and PatShayan-Najd2018-11-2418-462/+551
| | | | | | | | | | | | | | | | | | 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
* Rename literal constructorsSylvain Henry2018-11-226-30/+30
| | | | | | | | | | | | | | | | | | | | | | | | In a previous patch we replaced some built-in literal constructors (MachInt, MachWord, etc.) with a single LitNumber constructor. In this patch we replace the `Mach` prefix of the remaining constructors with `Lit` for consistency (e.g., LitChar, LitLabel, etc.). Sadly the name `LitString` was already taken for a kind of FastString and it would become misleading to have both `LitStr` (literal constructor renamed after `MachStr`) and `LitString` (FastString variant). Hence this patch renames the FastString variant `PtrString` (which is more accurate) and the literal string constructor now uses the least surprising `LitString` name. Both `Literal` and `LitString/PtrString` have recently seen breaking changes so doing this kind of renaming now shouldn't harm much. Reviewers: hvr, goldfire, bgamari, simonmar, jrtc27, tdammers Subscribers: tdammers, rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4881
* Make `UniqDSet` a newtypeSebastian Graf2018-11-131-12/+11
| | | | | | | | | | | | | | | | | | | | Summary: This brings the situation of `UniqDSet` in line with `UniqSet`. @dfeuer said in D3146#92820 that he would do this, but probably never got around to it. Validated locally. Reviewers: AndreasK, mpickering, bgamari, dfeuer, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, carter, dfeuer GHC Trac Issues: #15879, #13114 Differential Revision: https://phabricator.haskell.org/D5313
* Finish fix for #14880.Tobias Dammers2018-10-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* plugins: search for .a files if necessarysheaf2018-10-281-40/+38
| | | | | | | | | | | | | | | | | | Summary: on windows, plugins are loaded via .a files, but those paths were not being searched when loading plugins Test Plan: ./validate Reviewers: Phyx, bgamari Reviewed By: Phyx Subscribers: RyanGlScott, rwbarton, carter GHC Trac Issues: #15700 Differential Revision: https://phabricator.haskell.org/D5253
* More explicit foralls (GHC Proposal 0007)Matthew Yacavone2018-10-278-86/+138
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Refactor the treatment of predicate typesSimon Peyton Jones2018-10-241-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Trac #15648 showed that GHC was a bit confused about the difference between the types for * Predicates * Coercions * Evidence (in the typechecker constraint solver) This patch cleans it up. See especially Type.hs Note [Types for coercions, predicates, and evidence] Particular changes * Coercion types (a ~# b) and (a ~#R b) are not predicate types (so isPredTy reports False for them) and are not implicitly instantiated by the type checker. This is a real change, but it consistently reflects that fact that (~#) and (~R#) really are different from predicates. * isCoercionType is renamed to isCoVarType * During type inference, simplifyInfer, we do /not/ want to infer a constraint (a ~# b), because that is no longer a predicate type. So we 'lift' it to (a ~ b). See TcType Note [Lift equality constaints when quantifying] * During type inference for pattern synonyms, we need to 'lift' provided constraints of type (a ~# b) to (a ~ b). See Note [Equality evidence in pattern synonyms] in PatSyn * But what about (forall a. Eq a => a ~# b)? Is that a predicate type? No -- it does not have kind Constraint. Is it an evidence type? Perhaps, but awkwardly so. In the end I decided NOT to make it an evidence type, and to ensure the the type inference engine never meets it. This made me /simplify/ the code in TcCanonical.makeSuperClasses; see TcCanonical Note [Equality superclasses in quantified constraints] Instead I moved the special treatment for primitive equality to TcInteract.doTopReactOther. See TcInteract Note [Looking up primitive equalities in quantified constraints] Also see Note [Evidence for quantified constraints] in Type. All this means I can have isEvVarType ty = isCoVarType ty || isPredTy ty which is nice. All in all, rather a lot of work for a small refactoring, but I think it's a real improvement.
* Normalise EmptyCase types using the constraint solverRyan Scott2018-09-281-29/+60
| | | | | | | | | | | | | | | | | | | | | Summary: Certain `EmptyCase` expressions were mistakently producing warnings since their types did not have as many type families reduced as they could have. The most direct way to fix this is to normalise these types initially using the constraint solver to solve for any local equalities that may be in scope. Test Plan: make test TEST=T14813 Reviewers: simonpj, bgamari, goldfire Reviewed By: simonpj Subscribers: rwbarton, carter GHC Trac Issues: #14813 Differential Revision: https://phabricator.haskell.org/D5094
* Add a recursivity check in nonVoidRyan Scott2018-09-231-49/+142
| | | | | | | | | | | | | | | | | | | | | | | Summary: Previously `nonVoid` outright refused to call itself recursively to avoid the risk of hitting infinite loops when checking recurisve types. But this is too conservative—we //can// call `nonVoid` recursively as long as we incorporate a way to detect the presence of recursive types, and bail out if we do detect one. Happily, such a mechanism already exists in the form of `checkRecTc`, so let's use it. Test Plan: make test TEST=T15584 Reviewers: simonpj, bgamari Reviewed By: simonpj Subscribers: rwbarton, carter GHC Trac Issues: #15584 Differential Revision: https://phabricator.haskell.org/D5116
* Coercion Quantificationningning2018-09-152-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch corresponds to #15497. According to https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase2, we would like to have coercion quantifications back. This will allow us to migrate (~#) to be homogeneous, instead of its current heterogeneous definition. This patch is (lots of) plumbing only. There should be no user-visible effects. An overview of changes: - Both `ForAllTy` and `ForAllCo` can quantify over coercion variables, but only in *Core*. All relevant functions are updated accordingly. - Small changes that should be irrelevant to the main task: 1. removed dead code `mkTransAppCo` in Coercion 2. removed out-dated Note Computing a coercion kind and roles in Coercion 3. Added `Eq4` in Note Respecting definitional equality in TyCoRep, and updated `mkCastTy` accordingly. 4. Various updates and corrections of notes and typos. - Haddock submodule needs to be changed too. Acknowledgments: This work was completed mostly during Ningning Xie's Google Summer of Code, sponsored by Google. It was advised by Richard Eisenberg, supported by NSF grant 1704041. Test Plan: ./validate Reviewers: goldfire, simonpj, bgamari, hvr, erikd, simonmar Subscribers: RyanGlScott, monoidal, rwbarton, carter GHC Trac Issues: #15497 Differential Revision: https://phabricator.haskell.org/D5054
* Add support for ImplicitParams and RecursiveDo in THMichael Sloan2018-09-141-3/+60
| | | | | | | | | | | | | | | | | | | | | | | | 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
* A few typos [ci skip]Gabor Greif2018-08-301-1/+1
|
* Take strict fields into account in coverage checkingRyan Scott2018-08-271-60/+257
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The current pattern-match coverage checker implements the formalism presented in the //GADTs Meet Their Match// paper in a fairly faithful matter. However, it was discovered recently that there is a class of unreachable patterns that //GADTs Meet Their Match// does not handle: unreachable code due to strict argument types, as demonstrated in #15305. This patch therefore goes off-script a little and implements an extension to the formalism presented in the paper to handle this case. Essentially, when determining if each constructor can be matched on, GHC checks if its associated term and type constraints are satisfiable. This patch introduces a new form of constraint, `NonVoid(ty)`, and checks if each constructor's strict argument types satisfy `NonVoid`. If any of them do not, then that constructor is deemed uninhabitable, and thus cannot be matched on. For the full story of how this works, see `Note [Extensions to GADTs Meet Their Match]`. Along the way, I did a little bit of much-needed refactoring. In particular, several functions in `Check` were passing a triple of `(ValAbs, ComplexEq, Bag EvVar)` around to represent a constructor and its constraints. Now that we're adding yet another form of constraint to the mix, I thought it appropriate to turn this into a proper data type, which I call `InhabitationCandidate`. Test Plan: make test TEST=T15305 Reviewers: simonpj, bgamari Reviewed By: simonpj Subscribers: rwbarton, carter GHC Trac Issues: #15305 Differential Revision: https://phabricator.haskell.org/D5087
* Replace most occurences of foldl with foldl'.klebinger.andreas@gmx.at2018-08-215-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-211-2/+2
| | | | | | | | | | | | | | 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.
* Be mindful of GADT tyvar order when desugaring record updatesRyan Scott2018-08-171-8/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: After commit ef26182e2014b0a2a029ae466a4b121bf235e4e4, the type variable binders in GADT constructor type signatures are now quantified in toposorted order, instead of always having all the universals before all the existentials. Unfortunately, that commit forgot to update some code (which was assuming the latter scenario) in `DsExpr` which desugars record updates. This wound up being the cause of #15499. This patch makes up for lost time by desugaring record updates in a way such that the desugared expression applies type arguments to the right-hand side constructor in the correct order—that is, the order in which they were quantified by the user. Test Plan: make test TEST=T15499 Reviewers: simonpj, bgamari Reviewed By: simonpj Subscribers: rwbarton, carter GHC Trac Issues: #15499 Differential Revision: https://phabricator.haskell.org/D5060
* Rename SigTv to TyVarTv (#15480)Joachim Breitner2018-08-161-6/+6
| | | | | | | | | | | | | because since #15050, these are no longer used in pattern SIGnatures, but still in other places where meta-variables should only be unified with TYpe VARiables. I also found mentions of `SigTv` in parts of the renamer and desugarer that do not seem to directly relate to `SigTv` as used in the type checker, but rather to uses of `forall a.` in type signatures. I renamed these to `ScopedTv`. Differential Revision: https://phabricator.haskell.org/D5074
* Filter plugin dylib locationsChristiaan Baaij2018-08-111-7/+28
| | | | | | | | | | | | | | | | | | | | | | | | Summary: Previously we just created a cartesian product of the library paths of the plugin package and the libraries of the package. Of course, some of these combinations result in a filepath of a file doesn't exists, leading to #15475. Instead of making `haskFile` return Nothing in case a file doesn't exist (which would hide errors), we look at all the possible dylib locations and ensure that at least one of those locations is an existing file. If the list turns out to be empty however, we panic. Reviewers: mpickering, bgamari Reviewed By: mpickering Subscribers: monoidal, rwbarton, carter GHC Trac Issues: #15475 Differential Revision: https://phabricator.haskell.org/D5048
* Turn on MonadFail desugaring by defaultHerbert Valerio Riedel2018-08-071-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This contains two commits: ---- Make GHC's code-base compatible w/ `MonadFail` There were a couple of use-sites which implicitly used pattern-matches in `do`-notation even though the underlying `Monad` didn't explicitly support `fail` This refactoring turns those use-sites into explicit case discrimations and adds an `MonadFail` instance for `UniqSM` (`UniqSM` was the worst offender so this has been postponed for a follow-up refactoring) --- Turn on MonadFail desugaring by default This finally implements the phase scheduled for GHC 8.6 according to https://prime.haskell.org/wiki/Libraries/Proposals/MonadFail#Transitionalstrategy This also preserves some tests that assumed MonadFail desugaring to be active; all ghc boot libs were already made compatible with this `MonadFail` long ago, so no changes were needed there. Test Plan: Locally performed ./validate --fast Reviewers: bgamari, simonmar, jrtc27, RyanGlScott Reviewed By: bgamari Subscribers: bgamari, RyanGlScott, rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D5028
* Remove decideKindGeneralisationPlanRichard Eisenberg2018-08-021-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 #15450 by refactoring checkEmptyCase'Ryan Scott2018-08-011-40/+97
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `checkEmptyCase'` (the code path for coverage-checking `EmptyCase` expressions) had a fair bit of code duplication from the code path for coverage-checking non-`EmptyCase` expressions, and to make things worse, it behaved subtly different in some respects (for instance, emitting different warnings under unsatisfiable constraints, as shown in #15450). This patch attempts to clean up both this discrepancy and the code duplication by doing the following: * Factor out a `pmInitialTmTyCs` function, which returns the initial set of term and type constraints to use when beginning coverage checking. If either set of constraints is unsatisfiable, we use an empty set in its place so that we can continue to emit as many warnings as possible. (The code path for non-`EmptyCase` expressions was doing this already, but not the code path for `EmptyCase` expressions, which is the root cause of #15450.) Along the way, I added a `Note` to explain why we do this. * Factor out a `pmIsSatisfiable` constraint which checks if a set of term and type constraints are satisfiable. This does not change any existing behavior; this is just for the sake of deduplicating code. Test Plan: make test TEST=T15450 Reviewers: simonpj, bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15450 Differential Revision: https://phabricator.haskell.org/D5017
* Plugin dependency information is stored separatelyChristiaan Baaij2018-08-012-6/+102
| | | | | | | | | | | | | | | | | | | | | | | | We need to store the used plugins so that we recompile a module when a plugin that it uses is recompiled. However, storing the `ModuleName`s of the plugins used by a module in the `dep_mods` field made the rest of GHC think that they belong in the HPT, causing at least the issues reported in #15234 We therefor store the `ModuleName`s of the plugins in a new field, `dep_plgins`, which is only used the the recompilation logic. Reviewers: mpickering, bgamari Reviewed By: mpickering, bgamari Subscribers: alpmestan, rwbarton, thomie, carter GHC Trac Issues: #15234 Differential Revision: https://phabricator.haskell.org/D4937
* Fix #15385 by using addDictsDs in matchGuardsRyan Scott2018-07-304-39/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Small refactor in desugar of pattern matchingSimon Peyton Jones2018-07-275-20/+54
| | | | | | | | | | | | | | | | In reviewing Phab:D4968 for Trac #15385 I saw a small but simple refactor to avoid unnecessary work in the desugarer. This patch just arranges to call matchSinglePatVar v ... rather than matchSinglePat (Var v) ... The more specialised function already existed, as match_single_pat_var I also added more comments about decideBangHood
* Comments onlySimon Peyton Jones2018-07-251-2/+3
|
* Add comments on Typeable (n :: Nat)Simon Peyton Jones2018-07-041-1/+2
| | | | | See Note [Typeable for Nat and Symbol] in TcInteract, which I added after discussion on Trac #15322
* TTG for IPBind had wrong extension nameAlan Zimmerman2018-06-222-2/+2
| | | | | | | | | | | | | | | | | | | | 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-201-5/+0
| | | | | | | | | | | | | | | | | | | | | 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-191-2/+2
| | | | | | | | | | | | | | | | | | | 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
* Built-in Natural literals in CoreSylvain Henry2018-06-151-38/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for built-in Natural literals in Core. - Replace MachInt,MachWord, LitInteger, etc. with a single LitNumber constructor with a LitNumType field - Support built-in Natural literals - Add desugar warning for negative literals - Move Maybe(..) from GHC.Base to GHC.Maybe for module dependency reasons This patch introduces only a few rules for Natural literals (compared to Integer's rules). Factorization of the built-in rules for numeric literals will be done in another patch as this one is already big to review. Test Plan: validate test build with integer-simple Reviewers: hvr, bgamari, goldfire, Bodigrim, simonmar Reviewed By: bgamari Subscribers: phadej, simonpj, RyanGlScott, carter, hsyl20, rwbarton, thomie GHC Trac Issues: #14170, #14465 Differential Revision: https://phabricator.haskell.org/D4212
* Embrace -XTypeInType, add -XStarIsTypeVladislav Zavialov2018-06-141-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* desugar: Rip out unsafeGlobalDynFlags usage in decomposeRuleLhsBen Gamari2018-06-142-9/+10
| | | | | | | | | | Reviewers: dfeuer Reviewed By: dfeuer Subscribers: dfeuer, rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4776
* Don't use unsafeGlobalDynFlags in optCoercionBen Gamari2018-06-072-5/+5
| | | | | | | | | | | | | | | | | This plumbs DynFlags through CoreOpt so optCoercion can finally eliminate its usage of `unsafeGlobalDynFlags`. Note that this doesn't completely eliminate `unsafeGlobalDynFlags` usage from this bit of the compiler. A few uses are introduced in call-sites where we don't (yet) have ready access to `DynFlags`. Test Plan: Validate Reviewers: goldfire Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4774
* Introduce DerivingViaRyan Scott2018-06-041-8/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-042-1/+351
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Implement QuantifiedConstraintsSimon Peyton Jones2018-06-041-5/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have wanted quantified constraints for ages and, as I hoped, they proved remarkably simple to implement. All the machinery was already in place. The main ticket is Trac #2893, but also relevant are #5927 #8516 #9123 (especially! higher kinded roles) #14070 #14317 The wiki page is https://ghc.haskell.org/trac/ghc/wiki/QuantifiedConstraints which in turn contains a link to the GHC Proposal where the change is specified. Here is the relevant Note: Note [Quantified constraints] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The -XQuantifiedConstraints extension allows type-class contexts like this: data Rose f x = Rose x (f (Rose f x)) instance (Eq a, forall b. Eq b => Eq (f b)) => Eq (Rose f a) where (Rose x1 rs1) == (Rose x2 rs2) = x1==x2 && rs1 >= rs2 Note the (forall b. Eq b => Eq (f b)) in the instance contexts. This quantified constraint is needed to solve the [W] (Eq (f (Rose f x))) constraint which arises form the (==) definition. Here are the moving parts * Language extension {-# LANGUAGE QuantifiedConstraints #-} and add it to ghc-boot-th:GHC.LanguageExtensions.Type.Extension * A new form of evidence, EvDFun, that is used to discharge such wanted constraints * checkValidType gets some changes to accept forall-constraints only in the right places. * Type.PredTree gets a new constructor ForAllPred, and and classifyPredType analyses a PredType to decompose the new forall-constraints * Define a type TcRnTypes.QCInst, which holds a given quantified constraint in the inert set * TcSMonad.InertCans gets an extra field, inert_insts :: [QCInst], which holds all the Given forall-constraints. In effect, such Given constraints are like local instance decls. * When trying to solve a class constraint, via TcInteract.matchInstEnv, use the InstEnv from inert_insts so that we include the local Given forall-constraints in the lookup. (See TcSMonad.getInstEnvs.) * topReactionsStage calls doTopReactOther for CIrredCan and CTyEqCan, so they can try to react with any given quantified constraints (TcInteract.matchLocalInst) * TcCanonical.canForAll deals with solving a forall-constraint. See Note [Solving a Wanted forall-constraint] Note [Solving a Wanted forall-constraint] * We augment the kick-out code to kick out an inert forall constraint if it can be rewritten by a new type equality; see TcSMonad.kick_out_rewritable Some other related refactoring ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * Move SCC on evidence bindings to post-desugaring, which fixed #14735, and is generally nicer anyway because we can use existing CoreSyn free-var functions. (Quantified constraints made the free-vars of an ev-term a bit more complicated.) * In LookupInstResult, replace GenInst with OneInst and NotSure, using the latter for multiple matches and/or one or more unifiers
* Fix broken test T14547.HE, Tao2018-06-041-12/+26
| | | | | | | | | | | | | | | | | | | | | | Phab:D4571 lags behind HEAD for too many commits. The commit of Phab:4571 1f88f541aad1e36d01f22f9e71dfbc247e6558e2 brought some unintentional changes (not belong to [Phab:4571's Diff 16314](https://phabricator.haskell.org/differential/diff/16314/)) into ghc-head, breaking T14557. Let's fix that. Test Plan: make test TEST="T14547" Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15222 Differential Revision: https://phabricator.haskell.org/D4778
* Improve exhaustiveness checking for literal values and patterns, fix #14546HE, Tao2018-06-034-72/+141
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, we parse both the **integral literal** value and the patterns as `OverLit HsIntegral`. For example: ``` case 0::Int of 0 -> putStrLn "A" 1 -> putStrLn "B" _ -> putStrLn "C" ``` When checking the exhaustiveness of pattern matching, we translate the `0` in value position as `PmOLit`, but translate the `0` and `1` in pattern position as `PmSLit`. The inconsistency leads to the failure of `eqPmLit` to detect the equality and report warning of "Pattern match is redundant" on pattern `0`, as reported in #14546. In this patch we remove the specialization of `OverLit` patterns, and keep the overloaded number literal in pattern as it is to maintain the consistency. Now we can capture the exhaustiveness of pattern `0` and the redundancy of pattern `1` and `_`. For **string literals**, we parse the string literals as `HsString`. When `OverloadedStrings` is enabled, it further be turned as `HsOverLit HsIsString`, whether it's type is `String` or not. For example: ``` case "foo" of "foo" -> putStrLn "A" "bar" -> putStrLn "B" "baz" -> putStrLn "C" ``` Previously, the overloaded string values are translated to `PmOLit` and the non-overloaded string values are translated to `PmSLit`. However the string patterns, both overloaded and non-overloaded, are translated to list of characters. The inconsistency leads to wrong warnings about redundant and non-exhaustive pattern matching warnings, as reported in #14546. In order to catch the redundant pattern in following case: ``` case "foo" of ('f':_) -> putStrLn "A" "bar" -> putStrLn "B" ``` In this patch, we translate non-overloaded string literals, both in value position and pattern position, as list of characters. For overloaded string literals, we only translate it to list of characters only when it's type is `stringTy`, since we know nothing about the `toString` methods. But we know that if two overloaded strings are syntax equal, then they are equal. Then if it's type is not `stringTy`, we just translate it to `PmOLit`. We can still capture the exhaustiveness of pattern `"foo"` and the redundancy of pattern `"bar"` and `"baz"` in the following code: ``` {-# LANGUAGE OverloadedStrings #-} main = do case "foo" of "foo" -> putStrLn "A" "bar" -> putStrLn "B" "baz" -> putStrLn "C" ``` Test Plan: make test TEST="T14546" Reviewers: bgamari, simonpj Reviewed By: bgamari, simonpj Subscribers: simonpj, thomie, carter GHC Trac Issues: #14546 Differential Revision: https://phabricator.haskell.org/D4571
* Fix a bad interaction between GADTs and COMPLETE setsRyan Scott2018-06-021-5/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As observed in #14059 (starting at comment 5), the error messages surrounding a program involving GADTs and a `COMPLETE` set became worse between 8.2 and 8.4. The culprit was a new validity check in 8.4 which filters out `COMPLETE` set candidates if a return type of any conlike in the set doesn't match the type of the scrutinee. However, this check was too conservative, since it removed perfectly valid `COMPLETE` sets that contained GADT constructors, which quite often have return types that don't match the type of a scrutinee. To fix this, I adopted the most straightforward possible solution of only performing this validity check on //pattern synonym// constructors, not //data// constructors. Note that this does not fix #14059 entirely, but instead simply fixes a particular buglet that was discovered in that ticket. Test Plan: make test TEST=T14059 Reviewers: bgamari, mpickering Reviewed By: mpickering Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14059 Differential Revision: https://phabricator.haskell.org/D4752
* vectorise: Put it out of its miseryBen Gamari2018-06-0212-560/+15
| | | | | | | | | | | | | | | | | | | | | 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
* Implement "An API for deciding whether plugins should cause recompilation"Matthew Pickering2018-05-302-7/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements the API proposed as pull request #108 for plugin authors to influence the recompilation checker. It adds a new field to a plugin which computes a `FingerPrint`. This is recorded in interface files and if it changes then we recompile the module. There are also helper functions such as `purePlugin` and `impurePlugin` for constructing plugins which have simple recompilation semantics but in general, an author can compute a hash as they wish. Fixes #12567 and #7414 https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/002 2-plugin-recompilation.rst Reviewers: bgamari, ggreif Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #7414, #12567 Differential Revision: https://phabricator.haskell.org/D4366
* Remove TcType.toTcTypeSimon Peyton Jones2018-05-213-7/+6
| | | | | | | | | | In the olden days we insisted that only TcTyVars could appear in a TcType. But now we are more accommodating; see TcType Note [TcTyVars and TyVars in the typechecker] This patch removes a function that converted a Type to a TcType. It didn't do anything useful except statisfy an invariant that we no longer have. Now it's gone.
* Normalize the element type of ListPat, fix #14547HE, Tao2018-05-081-13/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The element type of `List` maybe a type family instacen, rather than a trivial type. For example in Trac #14547, ``` {-# LANGUAGE TypeFamilies, OverloadedLists #-} class Foo f where type It f foo :: [It f] -> f data List a = Empty | a :! List a deriving Show instance Foo (List a) where type It (List a) = a foo [] = Empty foo (x : xs) = x :! foo xs ``` Here the element type of `[]` is `It (List a)`, we should also normalize it as `a`. Test Plan: make test TEST="T14547" Reviewers: bgamari Reviewed By: bgamari Subscribers: thomie, carter GHC Trac Issues: #14547 Differential Revision: https://phabricator.haskell.org/D4624
* Revert "Normalize the element type of ListPat, fix #14547"Ben Gamari2018-05-081-4/+1
| | | | This reverts commit 981bf4718de7daef7817a363ccc14030c2688632.
* Normalize the element type of ListPat, fix #14547Ben Gamari2018-05-081-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The element type of `List` maybe a type family instacen, rather than a trivial type. For example in Trac #14547, ``` {-# LANGUAGE TypeFamilies, OverloadedLists #-} class Foo f where type It f foo :: [It f] -> f data List a = Empty | a :! List a deriving Show instance Foo (List a) where type It (List a) = a foo [] = Empty foo (x : xs) = x :! foo xs ``` Here the element type of `[]` is `It (List a)`, we should also normalize it as `a`. Test Plan: make test TEST="T14547" Reviewers: bgamari Reviewed By: bgamari Subscribers: thomie, carter GHC Trac Issues: #14547 Differential Revision: https://phabricator.haskell.org/D4624
View Lorry Controller Status