summaryrefslogtreecommitdiff
path: root/testsuite/tests/typecheck/should_fail/T5095.stderr
Commit message (Collapse)AuthorAgeFilesLines
* Diagnostic codes: acccept test changessheaf2022-09-131-1/+1
| | | | | | | | 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.
* compiler: Introduce and use RoughMap for instance environmentsBen Gamari2022-02-041-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Here we introduce a new data structure, RoughMap, inspired by the previous `RoughTc` matching mechanism for checking instance matches. This allows [Fam]InstEnv to be implemented as a trie indexed by these RoughTc signatures, reducing the complexity of instance lookup and FamInstEnv merging (done during the family instance conflict test) from O(n) to O(log n). The critical performance improvement currently realised by this patch is in instance matching. In particular the RoughMap mechanism allows us to discount many potential instances which will never match for constraints involving type variables (see Note [Matching a RoughMap]). In realistic code bases matchInstEnv was accounting for 50% of typechecker time due to redundant work checking instances when simplifying instance contexts when deriving instances. With this patch the cost is significantly reduced. The larger constants in InstEnv creation do mean that a few small tests regress in allocations slightly. However, the runtime of T19703 is reduced by a factor of 4. Moreover, the compilation time of the Cabal library is slightly improved. A couple of test cases are included which demonstrate significant improvements in compile time with this patch. This unfortunately does not fix the testcase provided in #19703 but does fix #20933 ------------------------- Metric Decrease: T12425 Metric Increase: T13719 T9872a T9872d hard_hole_fits ------------------------- Co-authored-by: Matthew Pickering <matthewtpickering@gmail.com>
* Include "not more specific" info in overlap msgsheaf2021-11-201-3/+4
| | | | | | | | | When instances overlap, we now include additional information about why we weren't able to select an instance: perhaps one instance overlapped another but was not strictly more specific, so we aren't able to directly choose it. Fixes #20542
* Improve overlap error for polykinded constraintssheaf2021-10-061-2/+2
| | | | | | | | | | | | | | There were two problems around `mkDictErr`: 1. An outdated call to `flattenTys` meant that we missed out on some instances. As we no longer flatten type-family applications, the logic is obsolete and can be removed. 2. We reported "out of scope" errors in a poly-kinded situation because `BoxedRep` and `Lifted` were considered out of scope. We fix this by using `pretendNameIsInScope`. fixes #20465
* Add more instances for SoloDavid Feuer2021-09-181-2/+2
| | | | | | | | | Oleg Grenrus pointed out that `Solo` was missing `Eq`, `Ord`, `Bounded`, `Enum`, and `Ix` instances, which were all apparently available for the `OneTuple` type (in the `OneTuple` package). Though only the first three really seem useful, there's no reason not to take them all. For `Ix`, `Solo` naturally fills a gap between `()` and `(,)`.
* Update testsuiteSylvain Henry2020-06-171-2/+1
| | | | | | | | | | | | | | * support detection of slow ghc-bignum backend (to replace the detection of integer-simple use). There are still some test cases that the native backend doesn't handle efficiently enough. * remove tests for GMP only functions that have been removed from ghc-bignum * fix test results showing dependent packages (e.g. integer-gmp) or showing suggested instances * fix test using Integer/Natural API or showing internal names
* Do eager instantation in termsSimon Peyton Jones2020-04-221-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements eager instantiation, a small but critical change to the type inference engine, #17173. The main change is this: When inferring types, always return an instantiated type (for now, deeply instantiated; in future shallowly instantiated) There is more discussion in https://www.tweag.io/posts/2020-04-02-lazy-eager-instantiation.html There is quite a bit of refactoring in this patch: * The ir_inst field of GHC.Tc.Utils.TcType.InferResultk has entirely gone. So tcInferInst and tcInferNoInst have collapsed into tcInfer. * Type inference of applications, via tcInferApp and tcInferAppHead, are substantially refactored, preparing the way for Quick Look impredicativity. * New pure function GHC.Tc.Gen.Expr.collectHsArgs and applyHsArgs are beatifully dual. We can see the zipper! * GHC.Tc.Gen.Expr.tcArgs is now much nicer; no longer needs to return a wrapper * In HsExpr, HsTypeApp now contains the the actual type argument, and is used in desugaring, rather than putting it in a mysterious wrapper. * I struggled a bit with good error reporting in Unify.matchActualFunTysPart. It's a little bit simpler than before, but still not great. Some smaller things * Rename tcPolyExpr --> tcCheckExpr tcMonoExpr --> tcLExpr * tcPatSig moves from GHC.Tc.Gen.HsType to GHC.Tc.Gen.Pat Metric Decrease: T9961 Reduction of 1.6% in comiler allocation on T9961, I think.
* testsuite: Fix a variety of issues when building with integer-simpleBen Gamari2018-12-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | * Mark arith011 as broken with integer-simple As noted in #16091, arith011 fails when run against integer-simple with a "divide by zero" exception. This suggests that integer-gmp and integer-simple are handling division by zero differently. * This also fixes broken_without_gmp; the lack of types made the previous failure silent, sadly. Improves situation of #16043. * Mark several tests implicitly depending upon integer-gmp as broken with integer-simple. These expect to see Core coming from integer-gmp, which breaks with integer-simple. * Increase runtime timeout multiplier of T11627a with integer-simple I previously saw that T11627a timed out in all profiling ways when run against integer-simple. I suspect this is due to integer-simple's rather verbose heap representation. Let's see whether increasing the runtime timeout helps. Fixes test for #11627. This is all in service of fixing #16043.
* Built-in Natural literals in CoreSylvain Henry2018-06-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Move NonEmpty definition into GHC.BaseHerbert Valerio Riedel2017-09-041-2/+2
| | | | | | This is a preparatory refactoring for Semigroup=>Monoid as it prevents a messy .hs-boot file which would interact inconveniently with the buildsystem...
* Add Eq instances for TrName, ModuleBen Gamari2017-02-281-1/+1
| | | | | | | | | | Test Plan: Validate Reviewers: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3227
* InstEnv: Ensure that instance visibility check is lazyBen Gamari2016-07-201-4/+4
| | | | | | | | | | | | | | | | | | | | | Previously instIsVisible had completely broken the laziness of lookupInstEnv' since it would examine is_dfun_name to check the name of the defining module (to know whether it is an interactive module). This resulted in the visibility check drawing in an interface file unnecessarily. This contributed to the unnecessary regression in compiler allocations reported in #12367. Test Plan: Validate, check nofib changes Reviewers: simonpj, ezyang, austin Reviewed By: ezyang Subscribers: thomie, ezyang Differential Revision: https://phabricator.haskell.org/D2411 GHC Trac Issues: #12367
* make accept for Make simplifyInstanceContexts deterministicBartosz Nitka2016-05-101-1/+1
| | | | | Making it deterministic changed some error messages and I forgot to make accept. Relevant change: b58b0e18a568.
* Add more type class instances for GHC.GenericsRyanGlScott2016-02-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | GHC.Generics provides several representation data types that have obvious instances of various type classes in base, along with various other types of meta-data (such as associativity and fixity). Specifically, instances have been added for the following type classes (where possible): - Applicative - Data - Functor - Monad - MonadFix - MonadPlus - MonadZip - Foldable - Traversable - Enum - Bounded - Ix - Generic1 Thanks to ocharles for starting this! Test Plan: Validate Reviewers: ekmett, austin, hvr, bgamari Reviewed By: bgamari Subscribers: RyanGlScott, thomie Differential Revision: https://phabricator.haskell.org/D1937 GHC Trac Issues: #9043
* TcErrors: Fix plural form of "instance" errorBen Gamari2016-02-091-1/+1
| | | | | | | | | Previously "types" was inappropriately made plural instead of "instance", instance Eq Ordering -- Defined in ‘GHC.Classes’ ...plus 24 others ...plus 13 instance involving out-of-scope typess
* Restore derived Eq instance for SrcLocRyanGlScott2016-02-091-1/+1
| | | | | | | | | | | | | | GHC 7.10.2 and 7.10.3 had a derived `Eq` instance for `SrcLoc`, but it seems to have been removed (see 6740d70d95cb81cea3859ff847afc61ec439db4f) during GHC 8.0 development. Reviewers: hvr, austin, gridaphobe, bgamari Reviewed By: gridaphobe, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1894
* Visible type applicationRichard Eisenberg2015-12-241-1/+1
| | | | | | | | | | | | | This re-working of the typechecker algorithm is based on the paper "Visible type application", by Richard Eisenberg, Stephanie Weirich, and Hamidhasan Ahmed, to be published at ESOP'16. This patch introduces -XTypeApplications, which allows users to say, for example `id @Int`, which has type `Int -> Int`. See the changes to the user manual for details. This patch addresses tickets #10619, #5296, #10589.
* Narrow scope of special-case for unqualified printing of names in core librariesBen Gamari2015-12-151-14/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 547c597112954353cef7157cb0a389bc4f6303eb modifies the pretty-printer to render names from a set of core packages (`base`, `ghc-prim`, `template-haskell`) as unqualified. The idea here was that many of these names typically are not in scope but are well-known by the user and therefore qualification merely introduces noise. This, however, is a very large hammer and potentially breaks any consumer who relies on parsing GHC output (hence #11208). This commit partially reverts this change, now only printing `Constraint` (which appears quite often in errors) as unqualified. Fixes #11208. Updates tests in `array` submodule. Test Plan: validate Reviewers: hvr, thomie, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1619 GHC Trac Issues: #11208
* Generate Typeable info at definition sitesBen Gamari2015-10-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the second attempt at merging D757. This patch implements the idea floated in Trac #9858, namely that we should generate type-representation information at the data type declaration site, rather than when solving a Typeable constraint. However, this turned out quite a bit harder than I expected. I still think it's the right thing to do, and it's done now, but it was quite a struggle. See particularly * Note [Grand plan for Typeable] in TcTypeable (which is a new module) * Note [The overall promotion story] in DataCon (clarifies existing stuff) The most painful bit was that to generate Typeable instances (ie TyConRepName bindings) for every TyCon is tricky for types in ghc-prim etc: * We need to have enough data types around to *define* a TyCon * Many of these types are wired-in Also, to minimise the code generated for each data type, I wanted to generate pure data, not CAFs with unpackCString# stuff floating about. Performance ~~~~~~~~~~~ Three perf/compiler tests start to allocate quite a bit more. This isn't surprising, because they all allocate zillions of data types, with practically no other code, esp. T1969 * T1969: GHC allocates 19% more * T4801: GHC allocates 13% more * T5321FD: GHC allocates 13% more * T9675: GHC allocates 11% more * T783: GHC allocates 11% more * T5642: GHC allocates 10% more I'm treating this as acceptable. The payoff comes in Typeable-heavy code. Remaining to do ~~~~~~~~~~~~~~~ * I think that "TyCon" and "Module" are over-generic names to use for the runtime type representations used in GHC.Typeable. Better might be "TrTyCon" and "TrModule". But I have not yet done this * Add more info the the "TyCon" e.g. source location where it was defined * Use the new "Module" type to help with Trac Trac #10068 * It would be possible to generate TyConRepName (ie Typeable instances) selectively rather than all the time. We'd need to persist the information in interface files. Lacking a motivating reason I have not done this, but it would not be difficult. Refactoring ~~~~~~~~~~~ As is so often the case, I ended up refactoring more than I intended. In particular * In TyCon, a type *family* (whether type or data) is repesented by a FamilyTyCon * a algebraic data type (including data/newtype instances) is represented by AlgTyCon This wasn't true before; a data family was represented as an AlgTyCon. There are some corresponding changes in IfaceSyn. * Also get rid of the (unhelpfully named) tyConParent. * In TyCon define 'Promoted', isomorphic to Maybe, used when things are optionally promoted; and use it elsewhere in GHC. * Cleanup handling of knownKeyNames * Each TyCon, including promoted TyCons, contains its TyConRepName, if it has one. This is, in effect, the name of its Typeable instance. Updates haddock submodule Test Plan: Let Harbormaster validate Reviewers: austin, hvr, goldfire Subscribers: goldfire, thomie Differential Revision: https://phabricator.haskell.org/D1404 GHC Trac Issues: #9858
* Revert "Generate Typeable info at definition sites"Ben Gamari2015-10-291-1/+1
| | | | | | | | This reverts commit bef2f03e4d56d88a7e9752a7afd6a0a35616da6c. This merge was botched Also reverts haddock submodule.
* Generate Typeable info at definition sitesBen Gamari2015-10-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements the idea floated in Trac #9858, namely that we should generate type-representation information at the data type declaration site, rather than when solving a Typeable constraint. However, this turned out quite a bit harder than I expected. I still think it's the right thing to do, and it's done now, but it was quite a struggle. See particularly * Note [Grand plan for Typeable] in TcTypeable (which is a new module) * Note [The overall promotion story] in DataCon (clarifies existing stuff) The most painful bit was that to generate Typeable instances (ie TyConRepName bindings) for every TyCon is tricky for types in ghc-prim etc: * We need to have enough data types around to *define* a TyCon * Many of these types are wired-in Also, to minimise the code generated for each data type, I wanted to generate pure data, not CAFs with unpackCString# stuff floating about. Performance ~~~~~~~~~~~ Three perf/compiler tests start to allocate quite a bit more. This isn't surprising, because they all allocate zillions of data types, with practically no other code, esp. T1969 * T3294: GHC allocates 110% more (filed #11030 to track this) * T1969: GHC allocates 30% more * T4801: GHC allocates 14% more * T5321FD: GHC allocates 13% more * T783: GHC allocates 12% more * T9675: GHC allocates 12% more * T5642: GHC allocates 10% more * T9961: GHC allocates 6% more * T9203: Program allocates 54% less I'm treating this as acceptable. The payoff comes in Typeable-heavy code. Remaining to do ~~~~~~~~~~~~~~~ * I think that "TyCon" and "Module" are over-generic names to use for the runtime type representations used in GHC.Typeable. Better might be "TrTyCon" and "TrModule". But I have not yet done this * Add more info the the "TyCon" e.g. source location where it was defined * Use the new "Module" type to help with Trac Trac #10068 * It would be possible to generate TyConRepName (ie Typeable instances) selectively rather than all the time. We'd need to persist the information in interface files. Lacking a motivating reason I have not done this, but it would not be difficult. Refactoring ~~~~~~~~~~~ As is so often the case, I ended up refactoring more than I intended. In particular * In TyCon, a type *family* (whether type or data) is repesented by a FamilyTyCon * a algebraic data type (including data/newtype instances) is represented by AlgTyCon This wasn't true before; a data family was represented as an AlgTyCon. There are some corresponding changes in IfaceSyn. * Also get rid of the (unhelpfully named) tyConParent. * In TyCon define 'Promoted', isomorphic to Maybe, used when things are optionally promoted; and use it elsewhere in GHC. * Cleanup handling of knownKeyNames * Each TyCon, including promoted TyCons, contains its TyConRepName, if it has one. This is, in effect, the name of its Typeable instance. Requires update of the haddock submodule. Differential Revision: https://phabricator.haskell.org/D757
* Improve the error messages for class instance errorsSimon Peyton Jones2015-09-021-73/+5
| | | | | | | | | | Summary: See Note [Displaying potential instances]. Reviewers: austin Subscribers: KaneTW, thomie Differential Revision: https://phabricator.haskell.org/D1176
* Error msg wibbles from reduced module prefixesSimon Peyton Jones2015-04-071-16/+11
|
* Add various instances to newtypes in Data.MonoidOleg Grenrus2015-03-031-0/+15
| | | | | | | | | | | | | | | | | | | | | | | Summary: Add Functor instances for Dual, Sum and Product Add Foldable instances for Dual, Sum and Product Add Traversable instances for Dual, Sum and Product Add Foldable and Traversable instances for First and Last Add Applicative, Monad instances to Dual, Sum, Product Add MonadFix to Data.Monoid wrappers Derive Data for Identity Add Data instances to Data.Monoid wrappers Add Data (Alt f a) instance Reviewers: ekmett, dfeuer, hvr, austin Reviewed By: dfeuer, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D673 GHC Trac Issues: #10107
* Filter instance visibility based on set of visible orphans, fixes #2182.ghc-instvisEdward Z. Yang2014-11-291-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Amazingly, the fix for this very old bug is quite simple: when type-checking, maintain a set of "visible orphan modules" based on the orphans list of modules which we explicitly imported. When we import an instance and it is an orphan, we check if it is in the visible modules set, and if not, ignore it. A little bit of refactoring for when orphan-hood is calculated happens so that we always know if an instance is an orphan or not. For GHCi, we preinitialize the visible modules set based on the list of interactive imports which are active. Future work: Cache the visible orphan modules set for GHCi, rather than recomputing it every type-checking round. (But it's tricky what to do when you /remove/ a module: you need a data structure a little more complicated than just a set of modules.) Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: new tests and validate Reviewers: simonpj, austin Subscribers: thomie, carter Differential Revision: https://phabricator.haskell.org/D488 GHC Trac Issues: #2182
* Implement new integer-gmp2 from scratch (re #9281)Herbert Valerio Riedel2014-11-121-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is done as a separate `integer-gmp2` backend library because it turned out to become a complete rewrite from scratch. Due to the different (over)allocation scheme and potentially different accounting (via the new `{shrink,resize}MutableByteArray#` primitives), some of the nofib benchmarks actually results in increased allocation numbers (but not necessarily an increase in runtime!). I believe the allocation numbers could improve if `{resize,shrink}MutableByteArray#` could be optimised to reallocate in-place more efficiently. Here are the more apparent changes in the latest nofib comparision between `integer-gmp` and `integer-gmp2`: ------------------------------------------------------------------ Program Size Allocs Runtime Elapsed TotalMem ------------------------------------------------------------------ ... bernouilli +1.6% +15.3% 0.132 0.132 0.0% ... cryptarithm1 -2.2% 0.0% -9.7% -9.7% 0.0% ... fasta -0.7% -0.0% +10.9% +10.9% 0.0% ... kahan +0.6% +38.9% 0.169 0.169 0.0% ... lcss -0.7% -0.0% -6.4% -6.4% 0.0% ... mandel +1.6% +33.6% 0.049 0.049 0.0% ... pidigits +0.8% +8.5% +3.9% +3.9% 0.0% power +1.4% -23.8% -18.6% -18.6% -16.7% ... primetest +1.3% +50.1% 0.085 0.085 0.0% ... rsa +1.6% +53.4% 0.026 0.026 0.0% ... scs +1.2% +6.6% +6.5% +6.6% +14.3% ... symalg +1.0% +9.5% 0.010 0.010 0.0% ... transform -0.6% -0.0% -5.9% -5.9% 0.0% ... ------------------------------------------------------------------ Min -2.3% -23.8% -18.6% -18.6% -16.7% Max +1.6% +53.4% +10.9% +10.9% +14.3% Geometric Mean -0.3% +1.9% -0.8% -0.8% +0.0% (see P35 / https://phabricator.haskell.org/P35 for full report) By default, `INTEGER_LIBRARY=integer-gmp2` is active now, which results in the package `integer-gmp-1.0.0.0` being registered in the package db. The previous `integer-gmp-0.5.1.0` can be restored by setting `INTEGER_LIBRARY=integer-gmp` (but will probably be removed altogether for GHC 7.12). In-tree GMP support has been stolen from the old `integer-gmp` (while unpatching the custom memory-allocators, as well as forcing `-fPIC`) A minor hack to `ghc-cabal` was necessary in order to support two different `integer-gmp` packages (in different folders) with the same package key. There will be a couple of follow-up commits re-implementing some features that were dropped to keep D82 minimal, as well as further clean-ups/improvements. More information can be found via #9281 and https://ghc.haskell.org/trac/ghc/wiki/Design/IntegerGmp2 Reviewed By: austin, rwbarton, simonmar Differential Revision: https://phabricator.haskell.org/D82
* Move `Maybe`-typedef into GHC.BaseHerbert Valerio Riedel2014-09-161-0/+1
| | | | | | | This is preparatory work for reintroducing SPECIALISEs that were lost in d94de87252d0fe2ae97341d186b03a2fbe136b04 Differential Revision: https://phabricator.haskell.org/D214
* Re-export Word from Prelude (re #9531)Herbert Valerio Riedel2014-08-311-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The original proposal text can be found at http://www.haskell.org/pipermail/libraries/2014-August/023491.html The proposal passed with a clear majority, and was additionally confirmed by the core libraries committee. *Compatibility Note* Only code that imports `Data.Word` for the sole purpose of using `Word` *and* requires to be `-Werror`-clean (due to `-fwarn-unused-imports`) is affected by this change. In order to write warning-free forward/backward compatible against `base`, a variant of the following CPP-based snippet can be used: -- Starting with base>4.7.0 or GHC>7.8 Prelude re-exports 'Word' -- The following is needed, if 'Word' is the *only* entity needed from Data.Word #ifdef MIN_VERSION_base # if !MIN_VERSION_base(4,7,1) import Data.Word (Word) # endif -- no cabal_macros.h -- fallback to __GLASGOW_HASKELL__ #elif __GLASGOW_HASKELL__ < 709 import Data.Word (Word) #endif This also updates the haddock submodule in order to avoid a compile warning
* Testsuite wibblesSimon Peyton Jones2014-08-281-1/+0
|
* Do not zero out version number when processing wired-in packages.Edward Z. Yang2014-08-221-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Previously, GHC would look for instances of wired-in packages in the in-memory package database and null out the version number. This was necessary when the sourcePackageId was used to determine the linker symbols; however, we now use a package key, so only that needs to be updated. Long-term, we can remove this hack by ensuring that Cabal actually records the proper package key in the database. This will also fix an unrelated hack elsewhere. Keeping version numbers means that wired in packages get rendered differently when output by GHC. This is the source of all the test-case output changes. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: hvr, austin Subscribers: simonmar, ezyang, carter Differential Revision: https://phabricator.haskell.org/D170
* Complete work on new OVERLAPPABLE/OVERLAPPING pragmas (Trac #9242)Simon Peyton Jones2014-07-311-1/+1
| | | | | | | | | | | | | | | | | * Deprecate -XOverlappingInstances * Update test suite. Several tests even had entirely unnecessary uses of -XOverlappingInstances * Update user manual with a careful description of the instance resolution story * Fix an outright bug in the handling of duplidate instances in GHCi, which are meant to silently overwrite the earlier duplicate. The logic was right for family instances but was both more complicated, and plain wrong, for class instances. (If you are interested, the bug was that we were eliminating the duplicate from the InstEnv, but not from the [ClsInst] held in tcg_insts.) Test is ghci044a.
* Deprecate the AMP warnings.Austin Seipp2014-04-201-2/+0
| | | | | | | | Now that we're in development mode, Applicative will soon be a superclass of Monad in HEAD. So let's go ahead and deprecate the -fno-warn-amp flag, remove the checks, and tweak a few tests Signed-off-by: Austin Seipp <austin@well-typed.com>
* Use U+2018 instead of U+201B quote mark in compiler messagesHerbert Valerio Riedel2014-02-251-29/+29
| | | | | | | This matches GCC's choice of Unicode quotation marks (i.e. U+2018 and U+2019) and therefore looks more familiar on the console. This addresses #2507. Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
* Adjust test suite to new Language Pragma warnignsJoachim Breitner2013-09-141-1/+1
| | | | (this is related to #3647)
* Fix remaining AMP fallout.Austin Seipp2013-09-111-0/+2
| | | | | | | | The perf tests can probably be rechecked and tightened a little; I fixed them with AMP the other day but some changes since then have made them wibble perhaps. Signed-off-by: Austin Seipp <austin@well-typed.com>
* Update outputs following the unicode quote change in GHC's outputIan Lynagh2013-02-241-28/+28
|
* Add tests for deriving Generic1Jose Pedro Magalhaes2012-06-211-3/+0
| | | | Most of these tests were written by Nicolas Frisby.
* Follow the move of Word from base to ghc-primIan Lynagh2012-05-221-2/+3
|
* Error message wibblesSimon Peyton Jones2011-09-021-27/+27
|
* Test Trac #5095Simon Peyton Jones2011-08-031-0/+66
View Lorry Controller Status