summaryrefslogtreecommitdiff
path: root/testsuite/tests/ghci.debugger
Commit message (Collapse)AuthorAgeFilesLines
...
* Make 'error' include the CCS call stack when profiledSimon Marlow2015-11-133-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The idea here is that this gives a more detailed stack trace in two cases: 1. With `-prof` and `-fprof-auto` 2. In GHCi (see #11047) Example, with an error inserted in nofib/shootout/binary-trees: ``` $ ./Main 3 Main: z CallStack (from ImplicitParams): error, called at Main.hs:67:29 in main:Main CallStack (from -prof): Main.check' (Main.hs:(67,1)-(68,82)) Main.check (Main.hs:63:1-21) Main.stretch (Main.hs:32:35-57) Main.main.c (Main.hs:32:9-57) Main.main (Main.hs:(27,1)-(43,42)) Main.CAF (<entire-module>) ``` This doesn't quite obsolete +RTS -xc, which also attempts to display more information in the case when the error is in a CAF, but I'm exploring other solutions to that. Includes submodule updates. Test Plan: validate Reviewers: simonpj, ezyang, gridaphobe, bgamari, hvr, austin Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1426
* Make GHCi & TH work when the compiler is built with -profSimon Marlow2015-11-073-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Amazingly, there were zero changes to the byte code generator and very few changes to the interpreter - mainly because we've used good abstractions that hide the differences between profiling and non-profiling. So that bit was pleasantly straightforward, but there were a pile of other wibbles to get the whole test suite through. Note that a compiler built with -prof is now like one built with -dynamic, in that to use TH you have to build the code the same way. For dynamic, we automatically enable -dynamic-too when TH is required, but we don't have anything equivalent for profiling, so you have to explicitly use -prof when building code that uses TH with a profiled compiler. For this reason Cabal won't work with TH. We don't expect to ship a profiled compiler, so I think that's OK. Test Plan: validate with GhcProfiled=YES in validate.mk Reviewers: goldfire, bgamari, rwbarton, austin, hvr, erikd, ezyang Reviewed By: ezyang Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1407 GHC Trac Issues: #4837, #545
* Generate Typeable info at definition sitesBen Gamari2015-10-3012-31/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-2912-31/+31
| | | | | | | | This reverts commit bef2f03e4d56d88a7e9752a7afd6a0a35616da6c. This merge was botched Also reverts haddock submodule.
* Generate Typeable info at definition sitesBen Gamari2015-10-2912-31/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 error messages for ambiguous type variablesDavid Kraeutmann2015-10-072-3/+3
| | | | | | | | | | | | | | | Improved error messages are only printed when the old message would be "No instance for...", since they're not as helpful for "Could not deduce..." No special test case as error messages are tested by other tests already. Signed-off-by: David Kraeutmann <kane@kane.cx> Reviewed By: austin, goldfire Differential Revision: https://phabricator.haskell.org/D1182 GHC Trac Issues: #10733
* Injective type familiesJan Stolarek2015-09-031-1/+1
| | | | | | | | | | | | | | | | | | | For details see #6018, Phab:D202 and the wiki page: https://ghc.haskell.org/trac/ghc/wiki/InjectiveTypeFamilies This patch also wires-in Maybe data type and updates haddock submodule. Test Plan: ./validate Reviewers: simonpj, goldfire, austin, bgamari Subscribers: mpickering, bgamari, alanz, thomie, goldfire, simonmar, carter Differential Revision: https://phabricator.haskell.org/D202 GHC Trac Issues: #6018
* Improve the error messages for class instance errorsSimon Peyton Jones2015-09-022-34/+37
| | | | | | | | | | Summary: See Note [Displaying potential instances]. Reviewers: austin Subscribers: KaneTW, thomie Differential Revision: https://phabricator.haskell.org/D1176
* Use IP based CallStack in error and undefinedEric Seidel2015-09-023-6/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch modifies `error`, `undefined`, and `assertError` to use implicit call-stacks to provide better error messages to users. There are a few knock-on effects: - `GHC.Classes.IP` is now wired-in so it can be used in the wired-in types for `error` and `undefined`. - `TysPrim.tyVarList` has been replaced with a new function `TysPrim.mkTemplateTyVars`. `tyVarList` made it easy to introduce subtle bugs when you need tyvars of different kinds. The naive ``` tv1 = head $ tyVarList kind1 tv2 = head $ tyVarList kind2 ``` would result in `tv1` and `tv2` sharing a `Unique`, thus substitutions would be applied incorrectly, treating `tv1` and `tv2` as the same tyvar. `mkTemplateTyVars` avoids this pitfall by taking a list of kinds and producing a single tyvar of each kind. - The types `GHC.SrcLoc.SrcLoc` and `GHC.Stack.CallStack` now live in ghc-prim. - The type `GHC.Exception.ErrorCall` has a new constructor `ErrorCallWithLocation` that takes two `String`s instead of one, the 2nd one being arbitrary metadata about the error (but usually the call-stack). A bi-directional pattern synonym `ErrorCall` continues to provide the old API. Updates Cabal, array, and haddock submodules. Reviewers: nh2, goldfire, simonpj, hvr, rwbarton, austin, bgamari Reviewed By: simonpj Subscribers: rwbarton, rodlogic, goldfire, maoe, simonmar, carter, liyang, bgamari, thomie Differential Revision: https://phabricator.haskell.org/D861 GHC Trac Issues: #5273
* Ensure DynFlags are consistentBen Gamari2015-08-061-4/+1
| | | | | | | | | | | | | | | | | | | | | | | While we have always had makeDynFlagsConsistent to enforce a variety of consistency invariants on DynFlags, it hasn't been widely used. GHC.Main, for instance, ignored it entirely. This leads to issues like Trac #10549, where an OPTIONS_GHC pragma introduced an inconsistency, leading to a perplexing crash later in compilation. Here I add consistency checks in GHC.Main.set{Session,Program}DynFlags, closing this hole. Fixes #10549. Test Plan: Validate with T10549 Reviewers: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1128 GHC Trac Issues: #10549
* Fix off-by-one error in GHCi line reporting (Trac #10578)Ömer Sinan Ağacan2015-07-173-7/+7
| | | | | | | | | | | | | | | Test Plan: I couldn't add tests because apparently line number reporting was already working correctly when loading script files. I don't know how to test by running commands using stdin, is this supported? Reviewers: austin, thomie, bgamari Reviewed By: thomie, bgamari Subscribers: hvr, thomie Differential Revision: https://phabricator.haskell.org/D1067
* Testsuite: delete *.stderr-ghc-7.0 *.stdout-ghc-7.0Thomas Miedema2015-07-141-28/+0
| | | | No point in pretending the testsuite can be run with older versions of GHC.
* Improve error message for Typeable k (T k)Simon Peyton Jones2015-06-261-6/+5
| | | | | | | | GHC can't yest build a TypeRep for a type involving kind variables. (We await kinds = types for that.) But the error message was terrible, as fixing #10524 reminded me. This improves it a lot.
* compiler: make sure we reject -O + HscInterpretedAustin Seipp2015-06-021-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When using GHCi, we explicitly reject optimization, because the compilers optimization passes can introduce unboxed tuples, which the interpreter is not able to handle. But this goes the other way too: using GHCi on optimized code may cause the optimizer to float out breakpoints that the interpreter introduces. This manifests itself in weird ways, particularly if you as an API client use custom DynFlags to introduce optimization in combination with HscInterpreted. It turns out we weren't checking for consistent DynFlag settings when doing `setSessionDynFlags`, as #10052 showed. While the main driver handled it in `DynFlags` via `parseDynamicFlags`, we didn't check this elsewhere. This does a little refactoring to split out some of the common code, and immunizes the various `DynFlags` utilities in the `GHC` module from this particular bug. We should probably be checking other general invariants too. This fixes #10052, and adds some notes about the behavior in `GHC` and `FloatOut` As a bonus, expose `warningMsg` from `ErrUtils` as a helper since it didn't exist (somehow). Signed-off-by: Austin Seipp <austin@well-typed.com> Reviewed By: edsko Differential Revision: https://phabricator.haskell.org/D727 GHC Trac Issues: #10052
* Refactor the GlobalRdrEnv, fixing #7672Simon Peyton Jones2015-06-021-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch started innocently enough, by deleting a single call from rnImportDecl, namely let gbl_env = mkGlobalRdrEnv (filterOut from_this_mod gres) The 'filterOut' makes no sense, and was the cause of #7672. But that little loose end led to into a twisty maze of little passages, all alike, which has taken me an unreasonably long time to straighten out. Happily, I think the result is really much better. In particular: * INVARIANT 1 of the GlobalRdrEnv type was simply not true: we had multiple GlobalRdrElts in a list with the same gre_name field. This kludgily implmented one form of shadowing. * Meanwhile, extendGlobalRdrEnvRn implemented a second form of shadowing, by deleting stuff from the GlobalRdrEnv. * In turn, much of this shadowing stuff depended on the Names of the Ids bound in the GHCi InteractiveContext being Internal names, even though the TyCons and suchlike all had External Names. Very confusing. So I have made the following changes * I re-established INVARIANT 1 of GlobalRdrEnv. As a result some strange code in RdrName.pickGREs goes away. * RnNames.extendGlobalRdrEnvRn now makes one call to deal with shadowing, where necessary, and another to extend the environment. It deals separately with duplicate bindings. The very complicated RdrName.extendGlobalRdrEnv becomes much simpler; we need to export the shadowing function, now called RdrName.shadowNames; and we can nuke RdrName.findLocalDupsRdrEnv altogether. RdrName Note [GlobalRdrEnv shadowing] summarises the shadowing story * The Names of the Ids bound in the GHCi interactive context are now all External. See Note [Interactively-bound Ids in GHCi] in HscTypes. * Names for Ids created by the debugger are now made by IfaceEnv.newInteractiveBinder. This fixes a lurking bug which was that the debugger was using mkNewUniqueSupply 'I' to make uniques, which does NOT guarantee a fresh supply of uniques on successive calls. * Note [Template Haskell ambiguity] in RnEnv shows that one TH-related error is reported lazily (on occurrences) when it might be better reported when extending the environment. In some (but not all) cases this was done before; but now it's uniformly at occurrences. In some ways it'd be better to report when extending the environment, but it's a tiresome test and the error is rare, so I'm leaving it at the lookup site for now, with the above Note. * A small thing: RnNames.greAvail becomes RdrName.availFromGRE, where it joins the dual RdrName.gresFromAvail.
* Fix quadratic behaviour in tidyOccNameSimon Peyton Jones2015-05-221-3/+3
| | | | | | | | | | | | | | | | | | In the test program from comment:3 of Trac #10370, it turned out that 25% of all compile time was going in OccName.tidyOccName! It was all becuase the algorithm for finding an unused OccName had a quadratic case. This patch fixes it. THe effect is pretty big: Before: total time = 34.30 secs (34295 ticks @ 1000 us, 1 processor) total alloc = 15,496,011,168 bytes (excludes profiling overheads) After total time = 25.41 secs (25415 ticks @ 1000 us, 1 processor) total alloc = 11,812,744,816 bytes (excludes profiling overheads)
* Error msg wibbles from reduced module prefixesSimon Peyton Jones2015-04-074-63/+59
|
* Custom `Typeable` solver, that keeps track of kinds.Iavor S. Diatchki2015-03-071-8/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This implements the new `Typeable` solver: when GHC sees `Typeable` constraints it solves them on the spot. The current implementation creates `TyCon` representations on the spot. Pro: No overhead at all in code that does not use `Typeable` Cons: Code that uses `Typeable` may create multipe `TyCon` represntations. We have discussed an implementation where representations of `TyCons` are computed once, in the module, where a datatype is declared. This would lead to more code being generated: for a promotable datatype we need to generate `2 + number_of_data_cons` type-constructro representations, and we have to do that for all programs, even ones that do not intend to use typeable. I added code to emit warning whenevar `deriving Typeable` is encountered--- the idea being that this is not needed anymore, and shold be fixed. Also, we allow `instance Typeable T` in .hs-boot files, but they result in a warning, and are ignored. This last one was to avoid breaking exisitng code, and should become an error, eventually. Test Plan: 1. GHC can compile itself. 2. I compiled a number of large libraries, including `lens`. - I had to make some small changes: `unordered-containers` uses internals of `TypeReps`, so I had to do a 1 line fix - `lens` needed one instance changed, due to a poly-kinded `Typeble` instance 3. I also run some code that uses `syb` to traverse a largish datastrucutre. I didn't notice any signifiant performance difference between the 7.8.3 version, and this implementation. Reviewers: simonpj, simonmar, austin, hvr Reviewed By: austin, hvr Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D652 GHC Trac Issues: #9858
* Add various instances to newtypes in Data.MonoidOleg Grenrus2015-03-031-10/+12
| | | | | | | | | | | | | | | | | | | | | | | 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
* Modify a couple of error messages slightlySimon Peyton Jones2015-01-061-6/+6
| | | | | | | | | | | | In particular In the type signature for: f :: Int -> Int I added the colon Also reword the "maybe you haven't applied a function to enough arguments?" suggestion to make grammatical sense. These tiny changes affect a lot of error messages.
* Make the location in TcLclEnv and CtLoc into a RealSrcSpanSimon Peyton Jones2015-01-061-2/+2
| | | | | | | | | | | Previously it was a SrcSpan, which can be an UnhelpulSrcSpan, but actually for TcLclEnv and CtLoc we always know it is a real source location, and it's good to make the types reflect that fact. There is a continuing slight awkwardness (not new with this patch) about what "file name" to use for GHCi code. Current we say "<interactive>" which seems just about OK.
* For :info, return all matching Names, rather than complaining about ambiguitySimon Peyton Jones2014-12-221-1/+1
| | | | | This fixes Trac #9881, and gives more helpful output in the case of ambiguity. Certainly more helpful than the positively-misleading error we get right now.
* Filter instance visibility based on set of visible orphans, fixes #2182.ghc-instvisEdward Z. Yang2014-11-292-12/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* ghc generates more user-friendly error messagesMike Izbicki2014-11-191-1/+3
| | | | | | | | | | Test Plan: Compiled ghc fine. Opened ghci and fed it invalid code. It gave the improved error messages in response. Reviewers: austin Subscribers: thomie, simonpj, spacekitteh, rwbarton, simonmar, carter Differential Revision: https://phabricator.haskell.org/D201
* When outputting list of available instances, sort it.Edward Z. Yang2014-11-182-9/+9
| | | | | | | | | | | | | | | | | Summary: The intent of this commit is to make test suite cases more stable, so that it doesn't matter what order we load interface files in, the test output doesn't change. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonpj, austin Subscribers: thomie, carter Differential Revision: https://phabricator.haskell.org/D484
* Testsuite error message changesSimon Peyton Jones2014-11-041-58/+58
|
* Delete __GLASGOW_HASKELL__ ifdefs for stage0 < 7.6.Thomas Miedema2014-10-071-10/+0
| | | | | | | | | | | | | | | | Summary: My understanding is that ghc 7.10 should be buildable with the last 3 versions of ghc, i.e 7.6, 7.8 and 7.10 itself. Test Plan: x Reviewers: austin Reviewed By: austin Subscribers: hvr, simonmar, ezyang, carter, thomie Differential Revision: https://phabricator.haskell.org/D254
* Export `Monoid(..)`/`Foldable(..)`/`Traversable(..)` from PreludeHerbert Valerio Riedel2014-09-213-6/+7
| | | | | | | | | | | | | | | This finally exposes also the methods of these 3 classes in the Prelude in order to allow to define basic class instances w/o needing imports. This almost completes the primary goal of #9586 NOTE: `fold`, `foldl'`, `foldr'`, and `toList` are not exposed yet, as they require upstream fixes for at least `containers` and `bytestring`, and are not required for defining basic instances. Reviewed By: ekmett, austin Differential Revision: https://phabricator.haskell.org/D236
* Wibbles to "...plus N others" error message about instances in scopeSimon Peyton Jones2014-08-282-7/+5
| | | | I this this arises from my de-orphaning the Enum Word instance
* Add test case for #9046Vitaly Bragilevsky2014-08-193-0/+5
| | | | Signed-off-by: Austin Seipp <austin@well-typed.com>
* Complete work on new OVERLAPPABLE/OVERLAPPING pragmas (Trac #9242)Simon Peyton Jones2014-07-311-2/+2
| | | | | | | | | | | | | | | | | * 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-202-3/+3
| | | | | | | | 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-256-16/+16
| | | | | | | 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>
* In CoreSubst, optimize Coercible values aggressivelyJoachim Breitner2014-02-111-3/+3
| | | | just like boxed type equalities.
* Tidy up Outputable.printDoc, and add printDoc_Simon Peyton Jones2014-01-171-3/+0
| | | | | | The former adds a newline at the end (restoring the previous behaviour) while the latter does not (which previously happened by turning the thuing into a string and only then printing it).
* Test Trac #8557Simon Peyton Jones2013-11-284-0/+12
|
* Fixed Trac #8540Simon Peyton Jones2013-11-281-3/+3
|
* Error message wibblesSimon Peyton Jones2013-11-283-8/+8
|
* Mark break006 break003 print019 as broken by #8540Joachim Breitner2013-11-241-3/+3
| | | | ...when debugging is on, to keep builds reports clean.
* Update test output of print018Joachim Breitner2013-11-221-6/+6
| | | | | It seems that “Use bindLocalNamesFV in rn_inst_info” makes some names nicer in the debugger output.
* Fix fallout from making lazy unlifted bindings an errorAustin Seipp2013-09-292-35/+4
| | | | | | Issue #8022 Signed-off-by: Austin Seipp <austin@well-typed.com>
* Follow changes in comparison primops (see #6135)Jan Stolarek2013-09-181-3/+3
|
* Trailing whitespacesJan Stolarek2013-09-181-23/+23
|
* Fix remaining AMP fallout.Austin Seipp2013-09-112-3/+3
| | | | | | | | 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>
* Fix most AMP warnings.Austin Seipp2013-09-082-2/+12
| | | | | Authored-by: David Luposchainsky <dluposchainsky@gmail.com> Signed-off-by: Austin Seipp <aseipp@pobox.com>
* print035 now passes (see #7382)Austin Seipp2013-08-141-4/+2
| | | | Signed-off-by: Austin Seipp <aseipp@pobox.com>
* Update outputs following the unicode quote change in GHC's outputIan Lynagh2013-02-247-19/+19
|
* Add extra cleaning for print035Ian Lynagh2013-02-161-1/+2
|
* Remove uses of compose(s) in tests, and change how composition is handledIan Lynagh2013-02-141-3/+3
| | | | The driver now also supports nested lists of setup functions
* Error message wibbles when adding overloaded listsSimon Peyton Jones2013-02-147-26/+26
|
View Lorry Controller Status