summaryrefslogtreecommitdiff
path: root/testsuite/tests/deriving
Commit message (Collapse)AuthorAgeFilesLines
* testsuite: Set -dinitial-unique when reversing uniquesBen Gamari2019-07-181-1/+1
| | | | | Otherwise the unique counter starts at 0, causing us to immediately underflow.
* Don't typecheck too much (or too little) in DerivingVia (#16923)Ryan Scott2019-07-113-0/+11
| | | | | | | | | | | Previously, GHC would typecheck the `via` type once per class in a `deriving` clause, which caused the problems observed in #16923. This patch restructures some of the functionality in `TcDeriv` and `TcHsType` to avoid this problem. We now typecheck the `via` type exactly once per `deriving` clause and *then* typecheck all of the classes in the clause. See `Note [Don't typecheck too much in DerivingVia]` in `TcDeriv` for the full details.
* Produce all DerivInfo in tcTyAndClassDeclsVladislav Zavialov2019-07-042-47/+47
| | | | | | | | | | | | | | | Before this refactoring: * DerivInfo for data family instances was returned from tcTyAndClassDecls * DerivInfo for data declarations was generated with mkDerivInfos and added at a later stage of the pipeline in tcInstDeclsDeriv After this refactoring: * DerivInfo for both data family instances and data declarations is returned from tcTyAndClassDecls in a single list. This uniform treatment results in a more convenient arrangement to fix #16731.
* Some forall-related cleanup in deriving codeRyan Scott2019-05-232-0/+15
| | | | | | | | * Tweak the parser to allow `deriving` clauses to mention explicit `forall`s or kind signatures without gratuitous parentheses. (This fixes #14332 as a consequence.) * Allow Haddock comments on `deriving` clauses with explicit `forall`s. This requires corresponding changes in Haddock.
* TH: make `Lift` and `TExp` levity-polymorphicAlec Theriault2019-04-182-14/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Besides the obvious benefits of being able to manipulate `TExp`'s of unboxed types, this also simplified `-XDeriveLift` all while making it more capable. * `ghc-prim` is explicitly depended upon by `template-haskell` * The following TH things are parametrized over `RuntimeRep`: - `TExp(..)` - `unTypeQ` - `unsafeTExpCoerce` - `Lift(..)` * The following instances have been added to `Lift`: - `Int#`, `Word#`, `Float#`, `Double#`, `Char#`, `Addr#` - unboxed tuples of lifted types up to arity 7 - unboxed sums of lifted types up to arity 7 Ideally we would have levity-polymorphic _instances_ of unboxed tuples and sums. * The code generated by `-XDeriveLift` uses expression quotes instead of generating large amounts of TH code and having special hard-coded cases for some unboxed types.
* Fix #16518 with some more kind-splitting smartsRyan Scott2019-04-042-0/+37
| | | | | | | | | | | | | | | | This patch corrects two simple oversights that led to #16518: 1. `HsUtils.typeToLHsType` was taking visibility into account in the `TyConApp` case, but not the `AppTy` case. I've factored out the visibility-related logic into its own `go_app` function and now invoke `go_app` from both the `TyConApp` and `AppTy` cases. 2. `Type.fun_kind_arg_flags` did not properly split kinds with nested `forall`s, such as `(forall k. k -> Type) -> (forall k. k -> Type)`. This was simply because `fun_kind_arg_flags`'s `FunTy` case always bailed out and assumed all subsequent arguments were `Required`, which clearly isn't the case for nested `forall`s. I tweaked the `FunTy` case to recur on the result kind.
* Update Wiki URLs to point to GitLabTakenobu Tani2019-03-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | 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
* Update Trac ticket URLs to point to GitLabRyan Scott2019-03-1510-10/+10
| | | | | This moves all URL references to Trac tickets to their corresponding GitLab counterparts.
* Add `liftedTyped` to `Lift` classAlec Theriault2019-02-131-0/+7
| | | | | | | | Implements GHC proposal 43, adding a `liftTyped` method to the `Lift` typeclass. This also adds some documentation to `TExp`, describing typed splices and their advantages over their untyped counterparts. Resolves #14671.
* Fix #14579 by defining tyConAppNeedsKindSig, and using itRyan Scott2019-02-055-35/+79
|
* testsuite: Use makefile_testBen Gamari2019-01-302-6/+4
| | | | | This eliminates most uses of run_command in the testsuite in favor of the more structured makefile_test.
* Revert "Batch merge"Ben Gamari2019-01-302-4/+6
| | | | This reverts commit 76c8fd674435a652c75a96c85abbf26f1f221876.
* Batch mergeBen Gamari2019-01-302-6/+4
|
* Mention DerivingStrategies in the warning when DAC and GND are both enabledChaitanya Koparkar2019-01-203-0/+13
| | | | | | | | | | | Summary: When DeriveAnyClass and GeneralizedNewtypeDeriving are both enabled, GHC prints out a warning that specifies the strategy it used to derive a class. This patch updates the warning to mention that users may pick a particular strategy by using DerivingStrategies. Test plan: make test TEST=T16179
* Visible kind applicationmynguyen2019-01-032-0/+23
| | | | | | | | | | | | | | | | | | | | | | | 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
* testsuite: Save performance metrics in git notes.David Eichmann2018-11-071-9/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch makes the following improvement: - Automatically records test metrics (per test environment) so that the programmer need not supply nor update expected values in *.T files. - On expected metric changes, the programmer need only indicate the direction of change in the git commit message. - Provides a simple python tool "perf_notes.py" to compare metrics over time. Issues: - Using just the previous commit allows performance to drift with each commit. - Currently we allow drift as we have a preference for minimizing false positives. - Some possible alternatives include: - Use metrics from a fixed commit per test: the last commit that allowed a change in performance (else the oldest metric) - Or use some sort of aggregate since the last commit that allowed a change in performance (else all available metrics) - These alternatives may result in a performance issue (with the test driver) having to heavily search git commits/notes. - Run locally, performance tests will trivially pass unless the tests were run locally on the previous commit. This is often not the case e.g. after pulling recent changes. Previously, *.T files contain statements such as: ``` stats_num_field('peak_megabytes_allocated', (2, 1)) compiler_stats_num_field('bytes allocated', [(wordsize(64), 165890392, 10)]) ``` This required the programmer to give the expected values and a tolerance deviation (percentage). With this patch, the above statements are replaced with: ``` collect_stats('peak_megabytes_allocated', 5) collect_compiler_stats('bytes allocated', 10) ``` So that programmer must only enter which metrics to test and a tolerance deviation. No expected value is required. CircleCI will then run the tests per test environment and record the metrics to a git note for that commit and push them to the git.haskell.org ghc repo. Metrics will be compared to the previous commit. If they are different by the tolerance deviation from the *.T file, then the corresponding test will fail. By adding to the git commit message e.g. ``` # Metric (In|De)crease <metric(s)> <options>: <tests> Metric Increase ['bytes allocated', 'peak_megabytes_allocated'] \ (test_env='linux_x86', way='default'): Test012, Test345 Metric Decrease 'bytes allocated': Test678 Metric Increase: Test711 ``` This will allow the noted changes (letting the test pass). Note that by omitting metrics or options, the change will apply to all possible metrics/options (i.e. in the above, an increase for all metrics in all test environments is allowed for Test711) phabricator will use the message in the description Reviewers: bgamari, hvr Reviewed By: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #12758 Differential Revision: https://phabricator.haskell.org/D5059
* 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
View Lorry Controller Status