summaryrefslogtreecommitdiff
path: root/testsuite/tests/deriving
Commit message (Collapse)AuthorAgeFilesLines
...
* Enable -Wcompat=error in the testsuiteVladislav Zavialov2018-10-1511-18/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Enabling -Werror=compat in the testsuite allows us to easily see the impact that a new warning has on code. It also means that in the period between adding the warning and making the actual breaking change, all new test cases that are being added to the testsuite will be forwards-compatible. This is good because it will make the actual breaking change contain less irrelevant testsuite updates. Things that -Wcompat warns about are things that are going to break in the future, so we can be proactive and keep our testsuite forwards-compatible. This patch consists of two main changes: * Add `TEST_HC_OPTS += -Werror=compat` to the testsuite configuration. * Fix all broken test cases. Test Plan: Validate Reviewers: hvr, goldfire, bgamari, simonpj, RyanGlScott Reviewed By: goldfire, RyanGlScott Subscribers: rwbarton, carter GHC Trac Issues: #15278 Differential Revision: https://phabricator.haskell.org/D5200
* Fix #15637 by using VTA more in GNDRyan Scott2018-10-015-14/+32
| | | | | | | | | | | | | | | | | | | | | | Summary: The code that GND was generating before could crumple over if it derived an instance for a class with an ambiguous type variable in the class head, such as the example in #15637. The solution is straightforward: simply instantiate all variables bound by the class head explicitly using visible type application, which will nip any ambiguity in the bud. Test Plan: make test TEST=T15637 Reviewers: bgamari, simonpj, goldfire Reviewed By: simonpj Subscribers: simonpj, rwbarton, carter GHC Trac Issues: #15637 Differential Revision: https://phabricator.haskell.org/D5148
* Suppress -Winaccessible-code in derived codeRyan Scott2018-07-244-32/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: It's rather unfortunate that derived code can produce inaccessible code warnings (as demonstrated in #8128, #8740, and #15398), since the programmer has no control over the generated code. This patch aims to suppress `-Winaccessible-code` in all derived code. It accomplishes this by doing the following: * Generalize the `ic_env :: TcLclEnv` field of `Implication` to be of type `Env TcGblEnc TcLclEnv` instead. This way, it also captures `DynFlags`, which record the flag state at the time the `Implication` was created. * When typechecking derived code, turn off `-Winaccessible-code`. This way, any insoluble given `Implication`s that are created when typechecking this derived code will remember that `-Winaccessible-code` was disabled. * During error reporting, consult the `DynFlags` of an `Implication` before making the decision to report an inaccessible code warning. Test Plan: make test TEST="T8128 T8740 T15398" Reviewers: simonpj, bgamari Reviewed By: simonpj Subscribers: monoidal, rwbarton, thomie, carter GHC Trac Issues: #8128, #8740, #15398 Differential Revision: https://phabricator.haskell.org/D4993
* More refactoring in TcValiditySimon Peyton Jones2018-07-102-5/+3
| | | | | | | | | | | | | | | This patch responds to Trac #15334 by making it an error to write an instance declaration for a tuple constraint like (Eq [a], Show [a]). I then discovered that instance validity checking was scattered betweeen TcInstDcls and TcValidity, so I took the time to bring it all together, into TcValidity.checkValidInstHead In doing so I discovered that there are lot of special cases. I have not changed them, but at least they are all laid out clearly now.
* Mark AutoDeriveTypeable as deprecatedKrzysztof Gogolewski2018-07-063-3/+1
| | | | | | | | | | | | | | Test Plan: validate Reviewers: bgamari, alpmestan Reviewed By: alpmestan Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15342 Differential Revision: https://phabricator.haskell.org/D4933
* Instantiate GND bindings with an explicit type signatureRyan Scott2018-07-057-67/+132
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Before, we were using visible type application to apply impredicative types to `coerce` in `GeneralizedNewtypeDeriving`-generated bindings. This approach breaks down when combined with `QuantifiedConstraints` in certain ways, which #14883 and #15290 provide examples of. See Note [GND and QuantifiedConstraints] for all the gory details. To avoid this issue, we instead use an explicit type signature to instantiate each GND binding, and use that to bind any type variables that might be bound by a class method's type signature. This reduces the need to impredicative type applications, and more importantly, makes the programs from #14883 and #15290 work again. Test Plan: make test TEST="T15290b T15290c T15290d T14883" Reviewers: simonpj, bgamari Reviewed By: simonpj Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14883, #15290 Differential Revision: https://phabricator.haskell.org/D4895
* Fix #15307 by making nlHsFunTy parenthesize moreRyan Scott2018-07-051-4/+5
| | | | | | | | | | | | | | | | | | | | | | | Summary: `nlHsFunTy` wasn't parenthesizing its arguments at all, which led to `-ddump-deriv` producing incorrectly parenthesized types (since it uses `nlHsFunTy` to construct those types), as demonstrated in #15307. Fix this by changing `nlHsFunTy` to add parentheses à la `ppr_ty`: always parenthesizing the argument type with function precedence, and recursively processing the result type, adding parentheses for each function type it encounters. Test Plan: make test TEST=T14578 Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15307 Differential Revision: https://phabricator.haskell.org/D4890
* Add "quantified constraint" context in error message, fix #15231.HE, Tao2018-06-151-1/+1
| | | | | | | | | | | | | | | | | | | | This patch adds "quantified constraint" context in error message when UndecidableInstances checking fails for quantified constraints. See Trac #15231:comment#1. This patch also pretty-prints the instance head for better error messages. Test Plan: make test TEST="T15231" Reviewers: bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie, carter GHC Trac Issues: #15231 Differential Revision: https://phabricator.haskell.org/D4819
* Embrace -XTypeInType, add -XStarIsTypeVladislav Zavialov2018-06-1411-12/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-0412-0/+596
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Add tests for #8128 and #8740Ryan Scott2018-06-035-0/+60
| | | | | Commit 08073e16cf672d8009309e4e55d4566af1ecaff4 (#11066) ended up fixing these, fortunately enough.
* Orient TyVar/TyVar equalities with deepest on the leftSimon Peyton Jones2018-05-181-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Trac #15009 showed that, for Given TyVar/TyVar equalities, we really want to orient them with the deepest-bound skolem on the left. As it happens, we also want to do the same for Wanteds, but for a different reason (more likely to be touchable). Either way, deepest wins: see TcUnify Note [Deeper level on the left]. This observation led me to some significant changes: * A SkolemTv already had a TcLevel, but the level wasn't really being used. Now it is! * I updated added invariant (SkolInf) to TcType Note [TcLevel and untouchable type variables], documenting that the level number of all the ic_skols should be the same as the ic_tclvl of the implication * FlatSkolTvs and FlatMetaTvs previously had a dummy level-number of zero, which messed the scheme up. Now they get a level number the same way as all other TcTyVars, instead of being a special case. * To make sure that FlatSkolTvs and FlatMetaTvs are untouchable (which was previously done via their magic zero level) isTouchableMetaTyVar just tests for those two cases. * TcUnify.swapOverTyVars is the crucial orientation function; see the new Note [TyVar/TyVar orientation]. I completely rewrote this function, and it's now much much easier to understand. I ended up doing some related refactoring, of course * I noticed that tcImplicitTKBndrsX and tcExplicitTKBndrsX were doing a lot of useless work in the case where there are no skolems; I added a fast-patch * Elminate the un-used tcExplicitTKBndrsSig; and thereby get rid of the higher-order parameter to tcExpliciTKBndrsX. * Replace TcHsType.emitTvImplication with TcUnify.checkTvConstraints, by analogy with TcUnify.checkConstraints. * Inline TcUnify.buildImplication into its only call-site in TcUnify.checkConstraints * TcS.buildImplication becomes TcS.CheckConstraintsTcS, with a simpler API * Now that we have NoEvBindsVar we have no need of termEvidenceAllowed; nuke the latter, adding Note [No evidence bindings] to TcEvidence.
* Fix #15073 by suggesting UnboxedTuples in an error messageRyan Scott2018-05-164-0/+37
| | | | | | | | | | | | | | | | | | | | Under certain circumstances, `GeneralizedNewtypeDeriving` can emit code which uses unboxed tuple types, but if `UnboxedTuples` wasn't enabled, the error message that GHC gave didn't make it very clear that it could be worked around by explicitly enabling the extension. Easily fixed. Test Plan: make test TEST=T15073 Reviewers: bgamari Reviewed By: bgamari Subscribers: simonpj, thomie, carter GHC Trac Issues: #15073 Differential Revision: https://phabricator.haskell.org/D4620
* Fix #14875 by introducing PprPrec, and using itRyan Scott2018-05-131-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Trying to determine when to insert parentheses during TH conversion is a bit of a mess. There is an assortment of functions that try to detect this, such as: * `hsExprNeedsParens` * `isCompoundHsType` * `hsPatNeedsParens` * `isCompoundPat` * etc. To make things worse, each of them have slightly different semantics. Plus, they don't work well in the presence of explicit type signatures, as #14875 demonstrates. All of these problems can be alleviated with the use of an explicit precedence argument (much like what `showsPrec` currently does). To accomplish this, I introduce a new `PprPrec` data type, and define standard predences for things like function application, infix operators, function arrows, and explicit type signatures (that last one is new). I then added `PprPrec` arguments to the various `-NeedsParens` functions, and use them to make smarter decisions about when things need to be parenthesized. A nice side effect is that functions like `isCompoundHsType` are now completely unneeded, since they're simply aliases for `hsTypeNeedsParens appPrec`. As a result, I did a bit of refactoring to remove these sorts of functions. I also did a pass over various utility functions in GHC for constructing AST forms and used more appropriate precedences where convenient. Along the way, I also ripped out the existing `TyPrec` data type (which was tailor-made for pretty-printing `Type`s) and replaced it with `PprPrec` for consistency. Test Plan: make test TEST=T14875 Reviewers: alanz, goldfire, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14875 Differential Revision: https://phabricator.haskell.org/D4688
* Track type variable scope more carefully.Richard Eisenberg2018-03-311-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The main job of this commit is to track more accurately the scope of tyvars introduced by user-written foralls. For example, it would be to have something like this: forall a. Int -> (forall k (b :: k). Proxy '[a, b]) -> Bool In that type, a's kind must be k, but k isn't in scope. We had a terrible way of doing this before (not worth repeating or describing here, but see the old tcImplicitTKBndrs and friends), but now we have a principled approach: make an Implication when kind-checking a forall. Doing so then hooks into the existing machinery for preventing skolem-escape, performing floating, etc. This also means that we bump the TcLevel whenever going into a forall. The new behavior is done in TcHsType.scopeTyVars, but see also TcHsType.tc{Im,Ex}plicitTKBndrs, which have undergone significant rewriting. There are several Notes near there to guide you. Of particular interest there is that Implication constraints can now have skolems that are out of order; this situation is reported in TcErrors. A major consequence of this is a slightly tweaked process for type- checking type declarations. The new Note [Use SigTvs in kind-checking pass] in TcTyClsDecls lays it out. The error message for dependent/should_fail/TypeSkolEscape has become noticeably worse. However, this is because the code in TcErrors goes to some length to preserve pre-8.0 error messages for kind errors. It's time to rip off that plaster and get rid of much of the kind-error-specific error messages. I tried this, and doing so led to a lovely error message for TypeSkolEscape. So: I'm accepting the error message quality regression for now, but will open up a new ticket to fix it, along with a larger error-message improvement I've been pondering. This applies also to dependent/should_fail/{BadTelescope2,T14066,T14066e}, polykinds/T11142. Other minor changes: - isUnliftedTypeKind didn't look for tuples and sums. It does now. - check_type used check_arg_type on both sides of an AppTy. But the left side of an AppTy isn't an arg, and this was causing a bad error message. I've changed it to use check_type on the left-hand side. - Some refactoring around when we print (TYPE blah) in error messages. The changes decrease the times when we do so, to good effect. Of course, this is still all controlled by -fprint-explicit-runtime-reps Fixes #14066 #14749 Test cases: dependent/should_compile/{T14066a,T14749}, dependent/should_fail/T14066{,c,d,e,f,g,h}
* Fix #14916 with an additional validity check in deriveTyDataRyan Scott2018-03-253-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Manually-written instances and standalone-derived instances have the benefit of having the `checkValidInstHead` function run over them, which catches manual instances of built-in types like `(~)` and `Coercible`. However, instances generated from `deriving` clauses weren't being passed through `checkValidInstHead`, leading to confusing results as in #14916. `checkValidInstHead` also has additional validity checks for language extensions like `FlexibleInstances` and `MultiParamTypeClasses`. Up until now, GHC has never required these language extensions for `deriving` clause, so to avoid unnecessary breakage, I opted to suppress these language extension checks for `deriving` clauses, just like we currently suppress them for `SPECIALIZE instance` pragmas. Test Plan: make test TEST=T14916 Reviewers: goldfire, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14916 Differential Revision: https://phabricator.haskell.org/D4501
* Fix two pernicious bugs in DeriveAnyClassRyan Scott2018-03-253-0/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The way GHC was handling `DeriveAnyClass` was subtly wrong in two notable ways: * In `inferConstraintsDAC`, we were //always// bumping the `TcLevel` of newly created unification variables, under the assumption that we would always place those unification variables inside an implication constraint. But #14932 showed precisely the scenario where we had `DeriveAnyClass` //without// any of the generated constraints being used inside an implication, which made GHC incorrectly believe the unification variables were untouchable. * Even worse, we were using the generated unification variables from `inferConstraintsDAC` in every single iteration of `simplifyDeriv`. In #14933, however, we have a scenario where we fill in a unification variable with a skolem in one iteration, discard it, proceed on to another iteration, use the same unification variable (still filled in with the old skolem), and try to unify it with a //new// skolem! This results in an utter disaster. The root of both these problems is `inferConstraintsDAC`. This patch fixes the issue by no longer generating unification variables directly in `inferConstraintsDAC`. Instead, we store the original variables from a generic default type signature in `to_metas`, a new field of `ThetaOrigin`, and in each iteration of `simplifyDeriv`, we generate fresh meta tyvars (avoiding the second issue). Moreover, this allows us to more carefully fine-tune the `TcLevel` under which we create these meta tyvars, fixing the first issue. Test Plan: make test TEST="T14932 T14933" Reviewers: simonpj, bgamari Reviewed By: simonpj Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14932, #14933 Differential Revision: https://phabricator.haskell.org/D4507
* Special-case record fields ending with hash when deriving ReadRyan Scott2018-03-233-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In commit dbd81f7e86514498218572b9d978373b1699cc5b, a regression was inadvertently introduced which caused derived `Read` instances for record data types with fields ending in a `#` symbol (using `MagicHash`) would no longer parse on valid output. This is ultimately due to the same reasons as #5041, as we cannot parse a field name like `foo#` as a single identifier. We fix this issue by employing the same workaround as in #5041: first parse the identifier name `foo`, then then symbol `#`. This is accomplished by the new `readFieldHash` function in `GHC.Read`. This will likely warrant a `base-4.11.1.0` release. Test Plan: make test TEST=T14918 Reviewers: tdammers, hvr, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14918 Differential Revision: https://phabricator.haskell.org/D4502
* Implement stopgap solution for #14728Ryan Scott2018-02-185-0/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | It turns out that one can produce ill-formed Core by combining `GeneralizedNewtypeDeriving`, `TypeInType`, and `TypeFamilies`, as demonstrated in #14728. The root of the problem is allowing the last parameter of a class to appear in a //kind// of an associated type family, as our current approach to deriving associated type family instances simply doesn't work well for that situation. Although it might be possible to properly implement this feature today (see https://ghc.haskell.org/trac/ghc/ticket/14728#comment:3 for a sketch of how this might work), there does not currently exist a performant implementation of the algorithm needed to accomplish this. Until such an implementation surfaces, we will make this corner case of `GeneralizedNewtypeDeriving` an error. Test Plan: make test TEST="T14728a T14728b" Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14728 Differential Revision: https://phabricator.haskell.org/D4402
* Sequester deriving-related validity check into cond_stdOKRyan Scott2018-01-312-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, any standalone-derived instance must satisfy the property that the tycon of the data type having an instance being derived for it must be either a normal ADT tycon or a data family tycon. But there are several other primitive tycons—such as `(->)`, `Int#`, and others—which cannot have standalone-derived instances (via the `anyclass` strategy) as a result of this check! See https://ghc.haskell.org/trac/ghc/ticket/13154#comment:8 for an example of where this overly conservative restriction bites. Really, this validity check only makes sense in the context of `stock` deriving, where we need the property that the tycon is that of a normal ADT or a data family in order to inspect its data constructors. Other deriving strategies don't require this validity check, so the most sensible way to fix this error is to move the logic of this check into `cond_stdOK`, which is specific to `stock` deriving. This makes progress towards fixing (but does not entirely fix) Test Plan: make test TEST=T13154a Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #13154 Differential Revision: https://phabricator.haskell.org/D4337
* Fix #14692 by correcting an off-by-one error in TcGenDerivRyan Scott2018-01-211-1/+1
| | | | | | | | | | | | | | | | | | A silly mistake in `gen_Show_binds` was causing derived `Show` instances for empty data types to case on the precedence argument instead of the actual value being showed. Test Plan: make test TEST=drv-empty-data Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14692 Differential Revision: https://phabricator.haskell.org/D4328
* Fix #14681 and #14682 with precision-aimed parenthesesRyan Scott2018-01-183-0/+205
| | | | | | | | | | | | | | | | | | | | | | | | | | | | It turns out that `Convert` was recklessly leaving off parentheses in two places: * Negative numeric literals * Patterns in lambda position This patch fixes it by adding three new functions, `isCompoundHsLit`, `isCompoundHsOverLit`, and `isCompoundPat`, and using them in the right places in `Convert`. While I was in town, I also sprinkled `isCompoundPat` among some `Pat`-constructing functions in `HsUtils` to help avoid the likelihood of this problem happening in other places. One of these places is in `TcGenDeriv`, and sprinkling `isCompountPat` there fixes #14682 Test Plan: make test TEST="T14681 T14682" Reviewers: alanz, goldfire, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14681, #14682 Differential Revision: https://phabricator.haskell.org/D4323
* Make typeToLHsType produce kind signatures for tycon applicationsRyan Scott2018-01-033-7/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: `GeneralizedNewtypeDeriving` generates calls to `coerce` which take visible type arguments. These types must be produced by way of `typeToLHsType`, which converts a `Type` to an `LHsType`. However, `typeToLHsType` was leaving off important kind information when a `Type` contained a poly-kinded tycon application, leading to incorrectly generated code in #14579. This fixes the issue by tweaking `typeToLHsType` to generate explicit kind signatures for tycon applications. This makes the generated code noisier, but at least the program from #14579 now works correctly. Test Plan: make test TEST=T14579 Reviewers: simonpj, bgamari Reviewed By: simonpj Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14579 Differential Revision: https://phabricator.haskell.org/D4264
* Remove hack put in place for #12512Ryan Scott2017-12-201-2/+4
| | | | | | | | | | | | | | | | | | | | Summary: Previously, I added an ad hoc check for unboxed tuples and sums in standalone-derived instances to fix #12512, under the pretense that polymorphism over `UnboxedTupleRep` and `UnboxedSumRep` was a lie. But that is no longer the case, and so this ad hoc check can be removed entirely. Less code, and easier to understand. Test Plan: make test TEST=T12512 Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4271
* Fix #14578 by checking isCompoundHsType in more placesRyan Scott2017-12-203-0/+131
| | | | | | | | | | | | | | | | | | | | | Summary: The `HsType` pretty-printer does not automatically insert parentheses where necessary for type applications, so a function `isCompoundHsType` was created in D4056 towards this purpose. However, it was not used in as many places as it ought to be, resulting in #14578. Test Plan: make test TEST=T14578 Reviewers: alanz, bgamari, simonpj Reviewed By: alanz, simonpj Subscribers: simonpj, rwbarton, thomie, carter GHC Trac Issues: #14578 Differential Revision: https://phabricator.haskell.org/D4266
* Minimise provided dictionaries in pattern synonymsSimon Peyton Jones2017-11-081-1/+1
| | | | | | | | | | | Trac #14394 showed that it's possible to get redundant constraints in the inferred provided constraints of a pattern synonym. This patch removes the redundancy with mkMinimalBySCs. To do this I had to generalise the type of mkMinimalBySCs slightly. And, to reduce confusing reversal, I made it stable: it now returns its result in the same order as its input. That led to a raft of error message wibbles, mostly for the better.
* Implement the EmptyDataDeriving proposalRyan Scott2017-11-029-13/+276
| | | | | | | | | | | | | | | | | | | | | | | | | This implements the `EmptyDataDeriving` proposal put forth in https://github.com/ghc-proposals/ghc-proposals/blob/dbf51608/proposals/0006-deriving-empty.rst. This has two major changes: * The introduction of an `EmptyDataDeriving` extension, which permits directly deriving `Eq`, `Ord`, `Read`, and `Show` instances for empty data types. * An overhaul in the code that is emitted in derived instances for empty data types. To see an overview of the changes brought forth, refer to the changes to the 8.4.1 release notes. Test Plan: ./validate Reviewers: bgamari, dfeuer, austin, hvr, goldfire Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #7401, #10577, #13117 Differential Revision: https://phabricator.haskell.org/D4047
* Error when deriving instances in hs-boot filesRyan Scott2017-10-196-2/+35
| | | | | | | | | | | | | | | | | | | | | | | | Summary: According to the GHC users' guide, one cannot derive instances for data types in `.hs-boot` files. However, GHC was not enforcing this in practice, which led to #14365. Fix this by actually throwing an error if a derived instance is detected in an `.hs-boot` file (and recommend how to fix it in the error message.) Test Plan: make test TEST=T14365 Reviewers: ezyang, austin, bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie GHC Trac Issues: #14365 Differential Revision: https://phabricator.haskell.org/D4102
* Do not quantify over deriving clausesSimon Peyton Jones2017-10-122-0/+11
| | | | | | | | | | | | Trac #14331 showed that in a data type decl like data D = D deriving (C (a :: k)) we were quantifying D over the 'k' in the deriving clause. Yikes. Easily fixed, by deleting code in RnTypes.extractDataDefnKindVars See the discussion on the ticket, esp comment:8.
* Add a missing zonk in TcDerivInfer.simplifyDerivSimon Peyton Jones2017-10-112-0/+18
| | | | | | I'm astonished that anything worked without this! Fixes Trac #14339
* Remove wc_insol from WantedConstraintsSimon Peyton Jones2017-10-111-5/+11
| | | | | | | | | | | | | | | | | | | | | | | | This patch is a pure refactoring, which I've wanted to do for some time. The main payload is * Remove the wc_insol field from WantedConstraints; instead put all the insolubles in wc_simple * Remove inert_insols from InertCans Instead put all the insolubles in inert_irreds * Add a cc_insol flag to CIrredCan, to record that the constraint is definitely insoluble Reasons * Quite a bit of code gets slightly simpler * Fewer concepts to keep separate * Insolubles don't happen at all in production code that is just being recompiled, so previously there was a lot of moving-about of empty sets A couple of error messages acutally improved.
* TypofixesGabor Greif2017-09-271-1/+1
|
* Remove unneeded reqlibs for mtl and parsec in the GHC testsuiteRyan Scott2017-08-171-2/+2
| | | | | | | | | | | | | | | | Now that `mtl` and `parsec` are boot libraries, there's no need to qualify various tests in the testsuite with `reqlib('mtl')` or `reqlib('parsec')`. Test Plan: make test TEST="T4809 tcfail126 T4355 tc232 tc223 tc220 tc217 tc183 T5303 DoParamM qq005 qq006 galois_raytrace T1074 mod133 T3787 T4316 prog011 drvfail006 drvfail008" Reviewers: bgamari, austin Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3855
* Don't suppress unimplemented type family warnings with DeriveAnyClassRyan Scott2017-08-125-7/+47
| | | | | | | | | | | | | | | | | | | | | | | Summary: For some asinine reason, we were suppressing warnings when deriving associated type family instances with `DeriveAnyClass`. That seems like a bad idea. Let's not do that. Along the way, I noticed that the error contexts associated with these newly emitted warnings were less than ideal, so I did some minor refactoring to improve the story there. Fixes #14094 Test Plan: ./validate Reviewers: bgamari, austin Subscribers: rwbarton, thomie GHC Trac Issues: #14094 Differential Revision: https://phabricator.haskell.org/D3828
* Remove the deprecated Typeable{1..7} type synonymsRyan Scott2017-08-051-1/+1
| | | | | | | | | | | | | | | | | | | Summary: `Typeable{1..7}` (type synonyms for the poly-kinded `Typeable`) have been deprecated since GHC 7.8. They're now causing problems for users who try to still work with them in legacy code, since they can no longer be used in instances. To avoid this sort of confusion, let's just remove `Typeable{1..7}` altogether. Resolves #14047. Reviewers: bgamari, austin, hvr Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #14047 Differential Revision: https://phabricator.haskell.org/D3817
* Get the roles right for newtype instancesSimon Peyton Jones2017-08-022-0/+14
| | | | | | This was a simple slip, that gave rise to the bug reported in comment:13 of Trac #14045. We were supplying roles to mkAlgTyCon that didn't match the tyvars.
* Fix binder visiblity for default methodsSimon Peyton Jones2017-07-262-0/+44
| | | | | | | | | | | | | | | | | | | Trac #13998 showed that default methods were getting bogus tyvar binder visiblity info; and that it matters in the code genreated by the default-method fill-in mechanism * The actual fix: in TcTyDecls.mkDefaultMethodType, make TyVarBinders with the right visibility info by getting TyConBinders from the class TyCon. (Previously we made up visiblity info, but that caused #13998.) * Define TyCon.tyConTyVarBinders :: [TyConBinder] -> [TyVarBinder] which can build correct forall binders for a) default methods (Trac #13998) b) data constructors This was originally BuildTyCl.mkDataConUnivTyVarBinders * Move mkTyVarBinder, mkTyVarBinders from Type to Var
* Fix #10684 by processing deriving clauses with finer grainRyan Scott2017-07-255-0/+24
| | | | | | | | | | | | | | | | | | | | | | Summary: Previously, one could experience error cascades with deriving clauses when one class in a set of many failed to derive, causing the other derived classes to be skipped entirely and resulting in other errors down the line. The solution is to process each class in a data type's set of deriving clauses individually, and engineer it so that failure to derive an individual class within that set doesn't cancel out the others. Test Plan: make test TEST="T10684 T12801" Reviewers: austin, bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie GHC Trac Issues: #10684, #12801 Differential Revision: https://phabricator.haskell.org/D3771
* Fix some excessive spacing in error messagesRyan Scott2017-07-121-9/+9
| | | | | | | | | | Test Plan: If it builds, ship it Reviewers: austin, bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3729
* Suppress unused warnings for selectors for some derived classesRyan Scott2017-07-113-0/+17
| | | | | | | | | | | | | | | | | | | | | | Although derived `Read`, `Show`, and `Generic` instances technically don't //use// the record selectors of the data type for which an instance is being derived, the derived code is affected by the //presence// of record selectors. As a result, we should suppress `-Wunused-binds` for those record selectors when deriving these classes. This is accomplished by threading through more information from `hasStockDeriving`. Test Plan: make test TEST=T13919 Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13919 Differential Revision: https://phabricator.haskell.org/D3704
* Look through type synonyms in existential contexts when deriving FunctorRyan Scott2017-06-182-0/+14
| | | | | | | | | | | | | | | | | | | | Summary: This amounts to using `exactTyCoVarsOfType` instead of `tyCoVarsOfType` in the right place. I also fixed a similar issue for `-XDatatypeContexts` while I was in town (but couldn't be bothered to add a test for it). Test Plan: make test TEST=T13813 Reviewers: austin, bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie GHC Trac Issues: #13813 Differential Revision: https://phabricator.haskell.org/D3635
* Stop the specialiser generating loopy codeSimon Peyton Jones2017-06-071-1/+3
| | | | | | | | | | | | | | | | | | | | This patch fixes a bad bug in the specialiser, which showed up as Trac #13429. When specialising an imported DFun, the specialiser could generate a recusive loop where none existed in the original program. It's all rather tricky, and I've documented it at some length in Note [Avoiding loops] We'd encoutered exactly this before (Trac #3591) but I had failed to realise that the very same thing could happen for /imported/ DFuns. I did quite a bit of refactoring. The compiler seems to get a tiny bit faster on deriving/perf/T10858 but almost all the gain had occurred before now; this patch just pushed it over the line.
* Add regression test for #13758Ryan Scott2017-05-262-1/+59
|
* Re-engineer Given flatten-skolemsSimon Peyton Jones2017-05-261-6/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The big change here is to fix an outright bug in flattening of Givens, albeit one that is very hard to exhibit. Suppose we have the constraint forall a. (a ~ F b) => ..., (forall c. ....(F b)...) ... Then - we'll flatten the (F) b to a fsk, say (F b ~ fsk1) - we'll rewrite the (F b) inside the inner implication to 'fsk1' - when we leave the outer constraint we are suppose to unflatten; but that fsk1 will still be there - if we re-simplify the entire outer implication, we'll re-flatten the Given (F b) to, say, (F b ~ fsk2) Now we have two fsks standing for the same thing, and that is very wrong. Solution: make fsks behave more like fmvs: - A flatten-skolem is now a MetaTyVar, whose MetaInfo is FlatSkolTv - We "fill in" that meta-tyvar when leaving the implication - The old FlatSkol form of TcTyVarDetails is gone completely - We track the flatten-skolems for the current implication in a new field of InertSet, inert_fsks. See Note [The flattening story] in TcFlatten. In doing this I found various other things to fix: * I removed the zonkSimples from TcFlatten.unflattenWanteds; it wasn't needed. But I added one in TcSimplify.floatEqualities, which does the zonk precisely when it is needed. * Trac #13674 showed up a case where we had - an insoluble Given, e.g. a ~ [a] - the same insoluble Wanted a ~ [a] We don't use the Given to rewwrite the Wanted (obviously), but we therefore ended up reporting Can't deduce (a ~ [a]) from (a ~ [a]) which is silly. Conclusion: when reporting errors, make the occurs check "win" See Note [Occurs check wins] in TcErrors
* Don't derive showListDavid Feuer2017-04-011-1/+0
| | | | | | | | | | | | | | | | | There's no obvious reason to derive the definition of `showList`, manually inlining the default definition. Let's just use the default definition in the usual manner. Garbage collect a few unused `RdrNames` from `PrelNames`: `showList`, `showList__`, and `/=`. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: RyanGlScott, rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3403
* Remove Core Lint pass on occurrence analysis output (#13220)Reid Barton2017-03-311-7/+5
| | | | | | | | | | | | | | | It was expensive, as the simplifier runs for many iterations, and probably not very useful. Test Plan: harbormaster Reviewers: austin, bgamari, dfeuer Reviewed By: dfeuer Subscribers: dfeuer, thomie Differential Revision: https://phabricator.haskell.org/D3391
* Deriving for phantom and empty typesDavid Feuer2017-03-305-0/+122
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make `Functor`, `Foldable`, and `Traversable` take advantage of the case where the type parameter is phantom. In this case, * `fmap _ = coerce` * `foldMap _ _ = mempty` * `traverse _ x = pure (coerce x)` For the sake of consistency and especially simplicity, make other types with no data constructors behave the same: * `fmap _ x = case x of` * `foldMap _ _ = mempty` * `traverse _ x = pure (case x of)` Similarly, for `Generic`, * `to x = case x of` * `from x = case x of` Give all derived methods for types without constructors appropriate arities. For example, ``` compare _ _ = error ... ``` rather than ``` compare = error ... ``` Fixes #13117 and #13328 Reviewers: austin, bgamari, RyanGlScott Reviewed By: RyanGlScott Subscribers: ekmett, RyanGlScott, rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3374
* Improve error messages for skolemsSimon Peyton Jones2017-03-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | In error messages like this • Couldn't match type ‘c’ with ‘f0 (a -> b)’ ‘c’ is a rigid type variable bound by the type signature for: f :: ((a -> b) -> b) -> forall c. c -> a we need to take case both to actually show that 'forall c', and to make sure that its name lines with the 'c' in the error message. This has been shaky for some time, and this commit puts it on solid ground. See TcRnTypes: Note [SigSkol SkolemInfo] The main changes are * SigSkol gets an extra field that records the way in which the type signature was skolemised. * The type in SigSkol is now the /un/-skolemised version * pprSkolemInfo uses the info to make the tidy type line up nicely Lots of error message wibbles!
* Improve pretty-printing of typesSimon Peyton Jones2017-02-281-4/+4
| | | | | | | | | | | | | | | | | | | | | | | When doing debug-printing it's really important that the free vars of a type are printed with their uniques. The IfaceTcTyVar thing was a stab in that direction, but it only worked for TcTyVars, not TyVars. This patch does it properly, by keeping track of the free vars of the type when translating Type -> IfaceType, and passing that down through toIfaceTypeX. Then when we find a variable, look in that set, and translate it to IfaceFreeTyVar if so. (I renamed IfaceTcTyVar to IfaceFreeTyVar.) Fiddly but not difficult. Reviewers: austin, goldfire, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3201
* The Early Inline PatchSimon Peyton Jones2017-02-281-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This very small patch switches on sm_inline even in the InitialPhase (aka "gentle" phase). There is no reason not to... and the results are astonishing. I think the peformance of GHC itself improves by about 5%; and some programs get much smaller, quicker. Result: across the board irmprovements in compile time performance. Here are the changes in perf/compiler; the numbers are decreases in compiler bytes-allocated: 3% T5837 7% parsing001 9% T12234 35% T9020 9% T3064 13% T9961 20% T13056 5% T9872d 5% T9872c 5% T9872b 7% T9872a 5% T783 35% T12227 20% T1969 Plus in perf/should_run 5% lazy-bs-alloc It wasn't as easy as it sounds: I did a raft of preparatory work in earlier patches. But it's great! Reviewers: austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3203
View Lorry Controller Status