summaryrefslogtreecommitdiff
path: root/testsuite/tests/generics
Commit message (Collapse)AuthorAgeFilesLines
* Testsuite: more precise test optionsSylvain Henry2022-10-261-2/+3
| | | | | Necessary for newer cross-compiling backends (JS, Wasm) that don't support TH yet.
* Diagnostic codes: acccept test changessheaf2022-09-1317-57/+57
| | | | | | | | The testsuite output now contains diagnostic codes, so many tests need to be updated at once. We decided it was best to keep the diagnostic codes in the testsuite output, so that contributors don't inadvertently make changes to the diagnostic codes.
* Change GHC.Prim to GHC.Exts in docs and testsKrzysztof Gogolewski2022-04-011-1/+1
| | | | | Users are supposed to import GHC.Exts rather than GHC.Prim. Part of #18749.
* Delete GenericKind_ in favor of GenericKind_DCRyan Scott2022-03-072-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When deriving a `Generic1` instance, we need to know what the last type variable of a data type is. Previously, there were two mechanisms to determine this information: * `GenericKind_`, where `Gen1_` stored the last type variable of a data type constructor (i.e., the `tyConTyVars`). * `GenericKind_DC`, where `Gen1_DC` stored the last universally quantified type variable in a data constructor (i.e., the `dataConUnivTyVars`). These had different use cases, as `GenericKind_` was used for generating `Rep(1)` instances, while `GenericKind_DC` was used for generating `from(1)` and `to(1)` implementations. This was already a bit confusing, but things went from confusing to outright wrong after !6976. This is because after !6976, the `deriving` machinery stopped using `tyConTyVars` in favor of `dataConUnivTyVars`. Well, everywhere with the sole exception of `GenericKind_`, which still continued to use `tyConTyVars`. This lead to disaster when deriving a `Generic1` instance for a GADT family instance, as the `tyConTyVars` do not match the `dataConUnivTyVars`. (See #21185.) The fix is to stop using `GenericKind_` and replace it with `GenericKind_DC`. For the most part, this proves relatively straightforward. Some highlights: * The `forgetArgVar` function was deleted entirely, as it no longer proved necessary after `GenericKind_`'s demise. * The substitution that maps from the last type variable to `Any` (see `Note [Generating a correctly typed Rep instance]`) had to be moved from `tc_mkRepTy` to `tc_mkRepFamInsts`, as `tc_mkRepTy` no longer has access to the last type variable. Fixes #21185.
* Eradicate TcRnUnknownMessage from GHC.Tc.DerivAlfredo Di Napoli2021-10-054-6/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This (big) commit finishes porting the GHC.Tc.Deriv module to support the new diagnostic infrastructure (#18516) by getting rid of the legacy calls to `TcRnUnknownMessage`. This work ended up being quite pervasive and touched not only the Tc.Deriv module but also the Tc.Deriv.Utils and Tc.Deriv.Generics module, which needed to be adapted to use the new infrastructure. This also required generalising `Validity`. More specifically, this is a breakdown of the work done: * Add and use the TcRnUselessTypeable data constructor * Add and use TcRnDerivingDefaults data constructor * Add and use the TcRnNonUnaryTypeclassConstraint data constructor * Add and use TcRnPartialTypeSignatures * Add T13324_compile2 test to test another part of the TcRnPartialTypeSignatures diagnostic * Add and use TcRnCannotDeriveInstance data constructor, which introduces a new data constructor to TcRnMessage called TcRnCannotDeriveInstance, which is further sub-divided to carry a `DeriveInstanceErrReason` which explains the reason why we couldn't derive a typeclass instance. * Add DerivErrSafeHaskellGenericInst data constructor to DeriveInstanceErrReason * Add DerivErrDerivingViaWrongKind and DerivErrNoEtaReduce * Introduce the SuggestExtensionInOrderTo Hint, which adds (and use) a new constructor to the hint type `LanguageExtensionHint` called `SuggestExtensionInOrderTo`, which can be used to give a bit more "firm" recommendations when it's obvious what the required extension is, like in the case for the `DerivingStrategies`, which automatically follows from having enabled both `DeriveAnyClass` and `GeneralizedNewtypeDeriving`. * Wildcard-free pattern matching in mk_eqn_stock, which removes `_` in favour of pattern matching explicitly on `CanDeriveAnyClass` and `NonDerivableClass`, because that determine whether or not we can suggest to the user `DeriveAnyClass` or not.
* Add Generically (generic Semigroup, Monoid instances) and Generically1 ↵Baldur Blöndal2021-08-023-0/+20
| | | | (generic Functor, Applicative, Alternative, Eq1, Ord1 instances) to GHC.Generics.
* Correct warning for deprecated and unrecognised flagsAlfredo Di Napoli2021-04-053-3/+3
| | | | | | | | | | Fixes #19616. This commit changes the `GHC.Driver.Errors.handleFlagWarnings` function to rely on the newly introduced `DiagnosticReason`. This allows us to correctly pretty-print the flags which triggered some warnings and in turn remove the cruft around this function (like the extra filtering and the `shouldPrintWarning` function.
* GHC Exactprint main commitAlan Zimmerman2021-03-201-28/+28
| | | | | | | | Metric Increase: T10370 parsing001 Updates haddock submodule
* Use GHC2021 as default languageJoachim Breitner2021-03-1010-25/+30
|
* Remove deprecated -XGenerics and -XMonoPatBindsKrzysztof Gogolewski2021-02-131-3/+0
| | | | | They have no effect since 2011 (GHC 7.2/7.4), commits cb698570b2b and 49dbe60558.
* Revert "Specify kind variables for inferred kinds in base."Ben Gamari2020-05-251-51/+51
| | | | | | | | As noted in !3132, this has rather severe knock-on consequences in user-code. We'll need to revisit this before merging something along these lines. This reverts commit 9749fe1223d182b1f8e7e4f7378df661c509f396.
* Specify kind variables for inferred kinds in base.Baldur Blöndal2020-05-081-51/+51
|
* Make DeriveFunctor-generated code require fewer beta reductionsRyan Scott2020-03-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Issue #17880 demonstrates that `DeriveFunctor`-generated code is surprisingly fragile when rank-_n_ types are involved. The culprit is that `$fmap` (the algorithm used to generate `fmap` implementations) was too keen on applying arguments with rank-_n_ types to lambdas, which fail to typecheck more often than not. In this patch, I change `$fmap` (both the specification and the implementation) to produce code that avoids creating as many lambdas, avoiding problems when rank-_n_ field types arise. See the comments titled "Functor instances" in `TcGenFunctor` for a more detailed description. Not only does this fix #17880, but it also ensures that the code that `DeriveFunctor` generates will continue to work after simplified subsumption is implemented (see #17775). What is truly amazing is that #17880 is actually a regression (introduced in GHC 7.6.3) caused by commit 49ca2a37bef18aa57235ff1dbbf1cc0434979b1e, the fix #7436. Prior to that commit, the version of `$fmap` that was used was almost identical to the one used in this patch! Why did that commit change `$fmap` then? It was to avoid severe performance issues that would arise for recursive `fmap` implementations, such as in the example below: ```hs data List a = Nil | Cons a (List a) deriving Functor -- ===> instance Functor List where fmap f Nil = Nil fmap f (Cons x xs) = Cons (f x) (fmap (\y -> f y) xs) ``` The fact that `\y -> f y` was eta expanded caused significant performance overheads. Commit 49ca2a37bef18aa57235ff1dbbf1cc0434979b1e fixed this performance issue, but it went too far. As a result, this patch partially reverts 49ca2a37bef18aa57235ff1dbbf1cc0434979b1e. To ensure that the performance issues pre-#7436 do not resurface, I have taken some precautionary measures: * I have added a special case to `$fmap` for situations where the last type variable in an application of some type occurs directly. If this special case fires, we avoid creating a lambda expression. This ensures that we generate `fmap f (Cons x xs) = Cons (f x) (fmap f xs)` in the derived `Functor List` instance above. For more details, see `Note [Avoid unnecessary eta expansion in derived fmap implementations]` in `TcGenFunctor`. * I have added a `T7436b` test case to ensure that the performance of this derived `Functor List`-style code does not regress. When implementing this, I discovered that `$replace`, the algorithm which generates implementations of `(<$)`, has a special case that is very similar to the `$fmap` special case described above. `$replace` marked this special case with a custom `Replacer` data type, which was a bit overkill. In order to use the same machinery for both `Functor` methods, I ripped out `Replacer` and instead implemented a simple way to detect the special case. See the updated commentary in `Note [Deriving <$]` for more details.
* Pretty-printing of the * kindVladislav Zavialov2019-12-051-53/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this patch, GHC always printed the * kind unparenthesized. This led to two issues: 1. Sometimes GHC printed invalid or incorrect code. For example, GHC would print: type F @* x = x when it meant to print: type F @(*) x = x In the former case, instead of a kind application we were getting a type operator (@*). 2. Sometimes GHC printed kinds that were correct but hard to read. Should Either * Int be read as Either (*) Int or as (*) Either Int ? This depends on whether -XStarIsType is enabled, but it would be easier if we didn't have to check for the flag when reading the code. We can solve both problems by assigning (*) a different precedence. Note that Haskell98 kinds are not affected: ((* -> *) -> *) -> * does NOT become (((*) -> (*)) -> (*)) -> (*) The parentheses are added when (*) is used in a function argument position: F * * * becomes F (*) (*) (*) F A * B becomes F A (*) B Proxy * becomes Proxy (*) a * -> * becomes a (*) -> *
* Produce all DerivInfo in tcTyAndClassDeclsVladislav Zavialov2019-07-043-452/+452
| | | | | | | | | | | | | | | 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.
* testsuite: Use makefile_testBen Gamari2019-01-301-2/+1
| | | | | This eliminates most uses of run_command in the testsuite in favor of the more structured makefile_test.
* Revert "Batch merge"Ben Gamari2019-01-301-1/+2
| | | | This reverts commit 76c8fd674435a652c75a96c85abbf26f1f221876.
* Batch mergeBen Gamari2019-01-301-2/+1
|
* Overhaul -fprint-explicit-kinds to use VKARyan Scott2018-11-221-301/+296
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch changes the behavior of `-fprint-explicit-kinds` so that it displays kind argument using visible kind application. In other words, the flag now: 1. Prints instantiations of specified variables with `@(...)`. 2. Prints instantiations of inferred variables with `@{...}`. In addition, this patch removes the `Use -fprint-explicit-kinds to see the kind arguments` error message that often arises when a type mismatch occurs due to different kinds. Instead, whenever there is a kind mismatch, we now enable the `-fprint-explicit-kinds` flag locally to help cue to the programmer where the error lies. (See `Note [Kind arguments in error messages]` in `TcErrors`.) As a result, these funny `@{...}` things can now appear to the user even without turning on the `-fprint-explicit-kinds` flag explicitly, so I took the liberty of documenting them in the users' guide. Test Plan: ./validate Reviewers: goldfire, simonpj, bgamari Reviewed By: simonpj Subscribers: rwbarton, carter GHC Trac Issues: #15871 Differential Revision: https://phabricator.haskell.org/D5314
* Enable -Wcompat=error in the testsuiteVladislav Zavialov2018-10-153-6/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Built-in Natural literals in CoreSylvain Henry2018-06-154-42/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-2/+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
* Fix #15012 with a well-placed use of AnyRyan Scott2018-04-194-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, derived `Generic1` instances could have associated `Rep1` type family instances with unbound variables, such as in the following example: ```lang=haskell data T a = MkT (FakeOut a) deriving Generic1 type FakeOut a = Int ==> instance Generic1 T where type Rep1 T = ... (Rec0 (FakeOut a)) ``` Yikes! To avoid this, we simply map the last type variable in a derived `Generic1` instance to `Any`. Test Plan: make test TEST=T15012 Reviewers: bgamari Reviewed By: bgamari Subscribers: simonpj, thomie, carter GHC Trac Issues: #15012 Differential Revision: https://phabricator.haskell.org/D4602
* Some tidying up of type pretty-printingSimon Peyton Jones2017-05-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Triggered by the changes in #13677, I ended up doing a bit of refactoring in type pretty-printing. * We were using TyOpPrec and FunPrec rather inconsitently, so I made it consisent. * That exposed the fact that we were a bit undecided about whether to print a + b -> c + d vs (a+b) -> (c+d) and similarly a ~ [b] => blah vs (a ~ [b]) => blah I decided to make TyOpPrec and FunPrec compare equal (in BasicTypes), so (->) is treated as equal precedence with other type operators, so you get the unambiguous forms above, even though they have more parens. We could readily reverse this decision. See Note [Type operator precedence] in BasicTypes * I fixed a bug in pretty-printing of HsType where some parens were omitted by mistake.
* Deriving for phantom and empty typesDavid Feuer2017-03-301-73/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* tests: remove extra_files.py (#12223)Reid Barton2017-02-264-4/+4
| | | | | | | | | | | | The script I used is included as testsuite/driver/kill_extra_files.py, though at this point it is for mostly historical interest. Some of the tests in libraries/hpc relied on extra_files.py, so this commit includes an update to that submodule. One test in libraries/process also relies on extra_files.py, but we cannot update that submodule so easily, so for now we special-case it in the test driver.
* tests: manually move some extra_files into *.T filesReid Barton2017-02-261-3/+4
| | | | | Some of the *.T files were in libraries/hpc, so this contains an update to that submodule.
* Derive <$David Feuer2017-02-072-12/+4
| | | | | | | | | | | | | | | | Using the default definition of `<$` for derived `Functor` instance is very bad for recursive data types. Derive the definition instead. Fixes #13218 Reviewers: austin, bgamari, RyanGlScott Reviewed By: RyanGlScott Subscribers: RyanGlScott, thomie Differential Revision: https://phabricator.haskell.org/D3072
* Check that a default type signature aligns with the non-default signatureRyan Scott2017-01-301-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before, GHC was extremely permissive about the form a default type signature could take on in a class declaration. Notably, it would accept garbage like this: class Monad m => MonadSupply m where fresh :: m Integer default fresh :: MonadTrans t => t m Integer fresh = lift fresh And then give an extremely confusing error message when you actually tried to declare an empty instance of MonadSupply. We now do extra validity checking of default type signatures to ensure that they align with their non-default type signature counterparts. That is, a default type signature is allowed to differ from the non-default one only in its context - they must otherwise be alpha-equivalent. Fixes #12918. Test Plan: ./validate Reviewers: goldfire, simonpj, austin, bgamari Reviewed By: bgamari Subscribers: mpickering, dfeuer, thomie Differential Revision: https://phabricator.haskell.org/D2983 GHC Trac Issues: #12918
* Remove clean_cmd and extra_clean usage from .T filesThomas Miedema2017-01-226-17/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | The `clean_cmd` and `extra_clean` setup functions don't do anything. Remove them from .T files. Created using https://github.com/thomie/refactor-ghc-testsuite. This diff is a test for the .T-file parser/processor/pretty-printer in that repository. find . -name '*.T' -exec ~/refactor-ghc-testsuite/Main "{}" \; Tests containing inline comments or multiline strings are not modified. Preparation for #12223. Test Plan: Harbormaster Reviewers: austin, hvr, simonmar, mpickering, bgamari Reviewed By: mpickering Subscribers: mpickering Differential Revision: https://phabricator.haskell.org/D3000 GHC Trac Issues: #12223
* print * in unicode correctly (fixes #12550)John Leo2016-12-131-19/+19
| | | | | | | | | | | | Test Plan: validate Reviewers: simonpj, austin, bgamari, goldfire Reviewed By: bgamari, goldfire Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2829
* Add HsSyn prettyprinter testsAlan Zimmerman2016-12-074-126/+127
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Add prettyprinter tests, which take a file, parse it, pretty print it, re-parse the pretty printed version and then compare the original and new ASTs (ignoring locations) Updates haddock submodule to match the AST changes. There are three issues outstanding 1. Extra parens around a context are not reproduced. This will require an AST change and will be done in a separate patch. 2. Currently if an `HsTickPragma` is found, this is not pretty-printed, to prevent noise in the output. I am not sure what the desired behaviour in this case is, so have left it as before. Test Ppr047 is marked as expected fail for this. 3. Apart from in a context, the ParsedSource AST keeps all the parens from the original source. Something is happening in the renamer to remove the parens around visible type application, causing T12530 to fail, as the dumped splice decl is after the renamer. This needs to be fixed by keeping the parens, but I do not know where they are being removed. I have amended the test to pass, by removing the parens in the expected output. Test Plan: ./validate Reviewers: goldfire, mpickering, simonpj, bgamari, austin Reviewed By: simonpj, bgamari Subscribers: simonpj, goldfire, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D2752 GHC Trac Issues: #3384
* Replace -fshow-source-paths with -fhide-source-pathsSylvain Henry2016-11-291-2/+2
| | | | | | | | | | | | | | | | | | | | | This patch reverts the change introduced with 587dcccfdfa7a319e27300a4f3885071060b1f8e and restores the previous default output of GHC (i.e., show source path and object path for each compiled module). The -fhide-source-paths flag can be used to hide these paths and reduce the line noise. Reviewers: gracjan, nomeata, austin, bgamari, simonmar, hvr Reviewed By: hvr Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2728 GHC Trac Issues: #12851
* Make default output less verbose (source/object paths)Sylvain HENRY2016-11-111-2/+2
| | | | | | | | | | | | Reviewers: simonmar, mpickering, austin, bgamari Reviewed By: bgamari Subscribers: mpickering, nomeata, thomie Differential Revision: https://phabricator.haskell.org/D2679 GHC Trac Issues: #12807
* Allow GeneralizedNewtypeDeriving for classes with associated type familiesRyan Scott2016-11-064-8/+8
| | | | | | | | | | | | | | | | | | | | | | Summary: This implements the ability to derive associated type family instances for newtypes automatically using `GeneralizedNewtypeDeriving`. Refer to the users' guide additions for how this works; I essentially follow the pattern laid out in https://ghc.haskell.org/trac/ghc/ticket/8165#comment:18. Fixes #2721 and #8165. Test Plan: ./validate Reviewers: simonpj, goldfire, austin, bgamari Reviewed By: simonpj Subscribers: mpickering, thomie Differential Revision: https://phabricator.haskell.org/D2636 GHC Trac Issues: #2721, #8165
* Implement deriving strategiesRyan Scott2016-09-301-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | Allows users to explicitly request which approach to `deriving` to use via keywords, e.g., ``` newtype Foo = Foo Bar deriving Eq deriving stock Ord deriving newtype Show ``` Fixes #10598. Updates haddock submodule. Test Plan: ./validate Reviewers: hvr, kosmikus, goldfire, alanz, bgamari, simonpj, austin, erikd, simonmar Reviewed By: alanz, bgamari, simonpj Subscribers: thomie, mpickering, oerjan Differential Revision: https://phabricator.haskell.org/D2280 GHC Trac Issues: #10598
* Improve typechecking of instance defaultsSimon Peyton Jones2016-06-245-1/+52
| | | | | | | | | | | | | | | | | | | | | | | | | In an instance declaration when you don't specify the code for a method, GHC fills in from the default binding in the class. The type of the default method can legitmiately be ambiguous --- see Note [Default methods in instances] in TcInstDcls --- so typechecking it can be tricky. Trac #12220 showed that although we were dealing with that ambiguity for /vanilla/ default methods, we were not doing so for /generic/ default methods. Moreover we were dealing with it clumsily, by generating post-typechecked code. This patch fixes the bug AND deletes code! We now use the same code path for both vanilla and generic default methods; and generate /pre-typechecked/ code in both cases. The key trick is that we can use Visible Type Application to deal with the ambiguity, which wasn't possible before. Hooray. There is a small hit to performance in compiler/perf/T1969 which consists of nothing BUT instance declarations with several default methods to fill, which we now have to typecheck. The actual hit is from 724 -> 756 or 4% in that extreme example. Real world programs have vastly fewer instance decls.
* Improve error message in deriving( Functor )Simon Peyton Jones2016-06-222-6/+6
| | | | Fixes Trac #12163. Pretty simple.
* Refactor derived Generic instances to reduce allocationsRyan Scott2016-06-194-343/+381
| | | | | | | | | | | | | | | | | | | | | | | | | | Previously, derived implementations of `to`/`from` in `Generic` instances were wastefully putting extra `M1`s in every case, which led to an O(n) increase in the number of coercions, resulting in a slowdown during the typechecker phase. This factors out the common `M1` in every case of a `to`/`from` definition so that the typechecker has far fewer coercions to deal with. For a datatype with 300 constructors, this change has been observed to save almost 3 seconds of compilation time. This is one step towards coming up with a solution for #5642. Test Plan: ./validate Reviewers: hvr, austin, simonpj, bgamari Reviewed By: bgamari Subscribers: basvandijk, carter, thomie, osa1 Differential Revision: https://phabricator.haskell.org/D2304 GHC Trac Issues: #5642
* Major patch to introduce TyConBinderSimon Peyton Jones2016-06-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this patch, following the TypeInType innovations, each TyCon had two lists: - tyConBinders :: [TyBinder] - tyConTyVars :: [TyVar] They were in 1-1 correspondence and contained overlapping information. More broadly, there were many places where we had to pass around this pair of lists, instead of a single list. This commit tidies all that up, by having just one list of binders in a TyCon: - tyConBinders :: [TyConBinder] The new data types look like this: Var.hs: data TyVarBndr tyvar vis = TvBndr tyvar vis data VisibilityFlag = Visible | Specified | Invisible type TyVarBinder = TyVarBndr TyVar VisibilityFlag TyCon.hs: type TyConBinder = TyVarBndr TyVar TyConBndrVis data TyConBndrVis = NamedTCB VisibilityFlag | AnonTCB TyCoRep.hs: data TyBinder = Named TyVarBinder | Anon Type Note that Var.TyVarBdr has moved from TyCoRep and has been made polymorphic in the tyvar and visiblity fields: type TyVarBinder = TyVarBndr TyVar VisibilityFlag -- Used in ForAllTy type TyConBinder = TyVarBndr TyVar TyConBndrVis -- Used in TyCon type IfaceForAllBndr = TyVarBndr IfaceTvBndr VisibilityFlag type IfaceTyConBinder = TyVarBndr IfaceTvBndr TyConBndrVis -- Ditto, in interface files There are a zillion knock-on changes, but everything arises from these types. It was a bit fiddly to get the module loops to work out right! Some smaller points ~~~~~~~~~~~~~~~~~~~ * Nice new functions TysPrim.mkTemplateKiTyVars TysPrim.mkTemplateTyConBinders which help you make the tyvar binders for dependently-typed TyCons. See comments with their definition. * The change showed up a bug in TcGenGenerics.tc_mkRepTy, where the code was making an assumption about the order of the kind variables in the kind of GHC.Generics.(:.:). I fixed this; see TcGenGenerics.mkComp.
* Make Generic1 poly-kindedRyanGlScott2016-05-129-0/+615
| | | | | | | | | | | | | | | | | | | | | | | This generalizes the `Generic1` typeclass to be of kind `k -> *`, and this also makes the relevant datatypes and typeclasses in `GHC.Generics` poly-kinded. If `PolyKinds` is enabled, `DeriveGeneric` derives `Generic1` instances such that they use the most general kind possible. Otherwise, deriving `Generic1` defaults to make an instance where the argument is of kind `* -> *` (the current behavior). Fixes #10604. Depends on D2117. Test Plan: ./validate Reviewers: kosmikus, dreixel, goldfire, austin, hvr, simonpj, bgamari Reviewed By: simonpj, bgamari Subscribers: thomie, ekmett Differential Revision: https://phabricator.haskell.org/D2168 GHC Trac Issues: #10604
* Remove the instantiation check when deriving Generic(1)RyanGlScott2016-04-101-20/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, deriving `Generic(1)` bailed out when attempting to instantiate visible type parameters (#5939), but this instantiation check was quite fragile and doesn't interact well with `-XTypeInType`. It has been decided that `Generic(1)` shouldn't be subjected to this check anyway, so it has been removed, and `gen_Generic_binds`'s machinery has been updated to substitute the type variables in a generated `Rep`/`Rep1` instance with the user-supplied type arguments. In addition, this also refactors `Condition` in `TcDeriv` a bit. Namely, since we no longer need `tc_args` to check any conditions, the `[Type]` component of `Condition` has been removed. Fixes #11732. Test Plan: ./validate Reviewers: goldfire, kosmikus, simonpj, bgamari, austin Reviewed By: simonpj, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2061 GHC Trac Issues: #5939, #11732
* Testsuite: delete Windows line endings [skip ci] (#11631)Thomas Miedema2016-02-231-1/+1
|
* Restore old GHC generics behavior vis-à-vis FixityRyanGlScott2016-01-063-1/+35
| | | | | | | | | | | | | | | | | | | | | | | Phab:D493 accidentally changed the way GHC generics looks up `Fixity` information when deriving `Generic` or `Generic1`. Before, a `Fixity` of `Infix` would be given only if a data constructor was declared infix, but now, `Infix` is given to any data constructor that has a fixity declaration (not to be confused with being declared infix!). This commit reverts back to the original behavior for consistency's sake. Fixes #11358. Test Plan: ./validate Reviewers: kosmikus, dreixel, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1740 GHC Trac Issues: #11358
* Fix GEq1 when optimizations are enabledRyanGlScott2015-12-291-0/+2
| | | | | | | | | | | | | | | | | | | | When optimizations are enabled, primitive string literals can be inlined, which can create two copies of a string constant with different addresses. We want to avoid this behavior at all costs in the `GEq1` test, since the output depends on the result of `eqAddr#`. We prevent such inlining through use of the `{-# NOINLINE #-}` pragma. Fixes #11292. Test Plan: Validate with T11292 Reviewers: thomie, austin, bgamari Reviewed By: bgamari Differential Revision: https://phabricator.haskell.org/D1714 GHC Trac Issues: #11292
* Encode strictness in GHC generics metadataRyanGlScott2015-12-216-86/+253
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This augments `MetaSel` with a `Bang` field, which gives generic programmers access to the following information about each field selector: * `SourceUnpackedness`: whether a field was marked `{-# NOUNPACK #-}`, `{-# UNPACK #-}`, or not * `SourceStrictness`: whether a field was given a strictness (`!`) or laziness (`~`) annotation * `DecidedStrictness`: what strictness GHC infers for a field during compilation, which may be influenced by optimization levels, `-XStrictData`, `-funbox-strict-fields`, etc. Unlike in Phab:D1603, generics does not grant a programmer the ability to "splice" in metadata, so there is no issue including `DecidedStrictness` with `Bang` (whereas in Template Haskell, it had to be split off). One consequence of this is that `MetaNoSel` had to be removed, since it became redundant. The `NoSelector` empty data type was also removed for similar reasons. Fixes #10716. Test Plan: ./validate Reviewers: dreixel, goldfire, kosmikus, austin, hvr, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1646 GHC Trac Issues: #10716
* Use TypeLits in the meta-data encoding of GHC.GenericsRyanGlScott2015-12-074-345/+244
| | | | | | | | | | | | | | Test Plan: Validate. Reviewers: simonpj, goldfire, hvr, dreixel, kosmikus, austin, bgamari Reviewed By: kosmikus, austin, bgamari Subscribers: RyanGlScott, Fuuzetsu, bgamari, thomie, carter, dreixel Differential Revision: https://phabricator.haskell.org/D493 GHC Trac Issues: #9766
* Fill in associated type defaults with DeriveAnyClassRyanGlScott2015-10-033-0/+92
| | | | | | | | | | | | | | | | | | | | | | | Summary: Unlike `-XDefaultSignatures`, `-XDeriveAnyClass` would not fill in associated type family defaults when deriving a class which contained them. In order to fix this properly, `tcATDefault` needed to be used from `TcGenDeriv`. To avoid a module import cycle, `tcATDefault` was moved from `TcInstDcls` to `TcClsDcl`. Fixes #10361. Test Plan: ./validate Reviewers: kosmikus, dreixel, bgamari, austin, simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1283 GHC Trac Issues: #10361
* Make GHC generics capable of handling unboxed typesRyanGlScott2015-10-037-23/+79
| | | | | | | | | | | | | | | | | | | | | | | | This adds a data family (`URec`) and six data family instances (`UAddr`, `UChar`, `UDouble`, `UFloat`, `UInt`, and `UWord`) which a `deriving Generic(1)` clause will generate if it sees `Addr#`, `Char#`, `Double#`, `Float#`, `Int#`, or `Word#`, respectively. The programmer can then provide instances for these data family instances to provide custom implementations for unboxed types, similar to how derived `Eq`, `Ord`, and `Show` instances currently special-case unboxed types. Fixes #10868. Test Plan: ./validate Reviewers: goldfire, dreixel, bgamari, austin, hvr, kosmikus Reviewed By: dreixel, kosmikus Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D1239 GHC Trac Issues: #10868
* Fix DeriveGeneric for types with same OccName (#10487)Ömer Sinan Ağacan2015-09-243-129/+179
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: DeriveGeneric generates some data types (for data type constructors and for selectors of those constructors) and instances for those types. This patch changes name generation for these new types to make it working with data types with same names imported from different modules and with data types with same names imported from same modules(using module imports). Bonus content: - Some refactoring in `TcGenGenerics.metaTyConsToDerivStuff` to remove some redundant partial function applications and to remove a duplicated function. - Remove some unused names from `OccName`. (those were used for an old implementation of `DeriveGeneric`) Reviewers: kosmikus, simonpj, dreixel, ezyang, bgamari, austin Reviewed By: bgamari, austin Subscribers: ezyang, thomie Differential Revision: https://phabricator.haskell.org/D1081 GHC Trac Issues: #10487
View Lorry Controller Status