summaryrefslogtreecommitdiff
path: root/compiler/utils/Outputable.lhs
Commit message (Collapse)AuthorAgeFilesLines
...
* Add an (Outputable Word16) instanceIan Lynagh2009-07-281-1/+4
|
* Remove GHC's haskell98 dependencyIan Lynagh2009-07-241-2/+1
|
* Fix Trac #3012: allow more free-wheeling in standalone derivingsimonpj@microsoft.com2009-07-231-3/+3
| | | | | | | | | | | | | | | | | | In standalone deriving, we now do *not* check side conditions. We simply generate the code and typecheck it. If there's a type error, it's the programmer's problem. This means that you can do 'deriving instance Show (T a)', where T is a GADT, for example, provided of course that the boilerplate code does in fact typecheck. I put some work into getting a decent error message. In particular if there's a type error in a method, GHC will show the entire code for that method (since, after all, the user did not write it). Most of the changes are to achieve that goal. Still to come: changes in the documentation.
* Trim unused imports detected by new unused-import codesimonpj@microsoft.com2009-07-061-3/+3
|
* Improve printing of Orig RdrNamessimonpj@microsoft.com2009-05-281-0/+1
| | | | | | | | | | | In Tempate Haskell -ddump-splices, the "after" expression is populated with RdrNames, many of which are Orig things. We used to print these fully-qualified, but that's a bit heavy. This patch refactors the code a bit so that the same print-unqualified mechanism we use for Names also works for RdrNames. Lots of comments too, because it took me a while to figure out how it all worked again.
* Make some showSDoc's use OneLineMode rather than PageModeIan Lynagh2009-03-311-2/+13
|
* Make the showSDoc definition more explicitIan Lynagh2009-03-311-1/+1
|
* Add (a) CoreM monad, (b) new Annotations featuresimonpj@microsoft.com2008-10-301-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch, written by Max Bolingbroke, does two things 1. It adds a new CoreM monad (defined in simplCore/CoreMonad), which is used as the top-level monad for all the Core-to-Core transformations (starting at SimplCore). It supports * I/O (for debug printing) * Unique supply * Statistics gathering * Access to the HscEnv, RuleBase, Annotations, Module The patch therefore refactors the top "skin" of every Core-to-Core pass, but does not change their functionality. 2. It adds a completely new facility to GHC: Core "annotations". The idea is that you can say {#- ANN foo (Just "Hello") #-} which adds the annotation (Just "Hello") to the top level function foo. These annotations can be looked up in any Core-to-Core pass, and are persisted into interface files. (Hence a Core-to-Core pass can also query the annotations of imported things.) Furthermore, a Core-to-Core pass can add new annotations (eg strictness info) of its own, which can be queried by importing modules. The design of the annotation system is somewhat in flux. It's designed to work with the (upcoming) dynamic plug-ins mechanism, but is meanwhile independently useful. Do not merge to 6.10!
* Move pprFastFilePath from SrcLoc to OutputableIan Lynagh2008-08-261-0/+5
|
* Export Depth (needed for mkUserStyle); collapse identical PrintUnqualified, ↵simonpj@microsoft.com2008-08-111-5/+3
| | | | QueryQualifies
* Document OutputableMax Bolingbroke2008-08-071-47/+120
|
* Fix the bug part of Trac #1930simonpj@microsoft.com2008-08-041-6/+42
|
* New flag: -dno-debug-outputSimon Marlow2008-06-031-2/+5
| | | | | | | | | | From the docs: <para>Suppress any unsolicited debugging output. When GHC has been built with the <literal>DEBUG</literal> option it occasionally emits debug output of interest to developers. The extra output can confuse the testing framework and cause bogus test failures, so this flag is provided to turn it off.</para>
* (F)SLIT -> (f)sLit in OutputableIan Lynagh2008-04-121-29/+26
|
* Print some extra debugging info when doing --show-ifaceIan Lynagh2008-03-171-0/+3
|
* lots of portability changes (#1405)Isaac Dupree2008-01-171-6/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | re-recording to avoid new conflicts was too hard, so I just put it all in one big patch :-( (besides, some of the changes depended on each other.) Here are what the component patches were: Fri Dec 28 11:02:55 EST 2007 Isaac Dupree <id@isaac.cedarswampstudios.org> * document BreakArray better Fri Dec 28 11:39:22 EST 2007 Isaac Dupree <id@isaac.cedarswampstudios.org> * properly ifdef BreakArray for GHCI Fri Jan 4 13:50:41 EST 2008 Isaac Dupree <id@isaac.cedarswampstudios.org> * change ifs on __GLASGOW_HASKELL__ to account for... (#1405) for it not being defined. I assume it being undefined implies a compiler with relatively modern libraries but without most unportable glasgow extensions. Fri Jan 4 14:21:21 EST 2008 Isaac Dupree <id@isaac.cedarswampstudios.org> * MyEither-->EitherString to allow Haskell98 instance Fri Jan 4 16:13:29 EST 2008 Isaac Dupree <id@isaac.cedarswampstudios.org> * re-portabilize Pretty, and corresponding changes Fri Jan 4 17:19:55 EST 2008 Isaac Dupree <id@isaac.cedarswampstudios.org> * Augment FastTypes to be much more complete Fri Jan 4 20:14:19 EST 2008 Isaac Dupree <id@isaac.cedarswampstudios.org> * use FastFunctions, cleanup FastString slightly Fri Jan 4 21:00:22 EST 2008 Isaac Dupree <id@isaac.cedarswampstudios.org> * Massive de-"#", mostly Int# --> FastInt (#1405) Fri Jan 4 21:02:49 EST 2008 Isaac Dupree <id@isaac.cedarswampstudios.org> * miscellaneous unnecessary-extension-removal Sat Jan 5 19:30:13 EST 2008 Isaac Dupree <id@isaac.cedarswampstudios.org> * add FastFunctions
* Extra instance for Outputable on 5-tuplessimonpj@microsoft.com2008-01-161-5/+14
|
* Try to manage the size of the text rendered for ':show bindings'Pepe Iborra2007-11-141-2/+8
|
* refactoring only: use the parameterised InstalledPackageInfoSimon Marlow2007-10-031-6/+1
| | | | This required moving PackageId from PackageConfig to Module
* cleaned up all warnings (and added many type signatures) in OutputableNorman Ramsey2007-09-121-58/+87
|
* FIX #1465, error messages could sometimes say things like "A.T doesn't match ↵Simon Marlow2007-09-061-18/+28
| | | | | | | | | | | | | A.T" This turned out to be a black hole, however we believe we now have a plan that does the right thing and shouldn't need to change again. Error messages will only ever refer to a name in an unambiguous way, falling back to <package>:<module>.<name> if no unambiguous shorter variant can be found. See HscTypes.mkPrintUnqualified for the details. Earlier hacks to work around this problem have been removed (TcSimplify).
* Fix CodingStyle#Warnings URLsIan Lynagh2007-09-041-1/+1
|
* Use OPTIONS rather than OPTIONS_GHC for pragmasIan Lynagh2007-09-031-2/+2
| | | | | | | Older GHCs can't parse OPTIONS_GHC. This also changes the URL referenced for the -w options from WorkingConventions#Warnings to CodingStyle#Warnings for the compiler modules.
* Add {-# OPTIONS_GHC -w #-} and some blurb to all compiler modulesIan Lynagh2007-09-011-0/+6
|
* Allow redirection of -ddump-* to fileBen.Lippmeier@anu.edu.au2007-08-211-4/+7
| | | | | | Whilst compiling Main.hs with -ddump-stg, ddump-asm and friends you can how add -ddump-to-file and you'll get the dumps redirected to Main.dump-stg, Main.dump-asm etc.
* Tidy up the interface to lookupInstEnvsimonpj@microsoft.com2007-05-091-0/+4
| | | | | | | | | | | | | | This patch changes the interface to lookupInstEnv, so that it returns a pair (Instance, [Either TyVar Type]) rather than (Inst, TvSubst) There is no functionality change, but the interface is tidier, and closer to lookupFamInstEnv (when Manuel has changed that too). The [Either TyVar Type] gives the type(s) at which the dfun should be instantiated. We need an Either because it might be instantiated freely: see Note [InstTypes: instantiating types] in InstEnv. (This might be a pattern we want to use elsewhere too.)
* Improve depth-cutoff for printing HsSyn in error messagessimonpj@microsoft.com2007-04-221-1/+15
| | | | | | | | | | | | | | | | | | MERGE TO STABLE The "user style" in Outputable allows us to elide large expressions when printing HsSyn, printing "..." instead. This is done by calling Outputable.pprDeeper. But there was no mechanism for trimming very long lists, which occur when using do-notation or explicit lists. This patch fixes the problem, by adding Outputable.pprDeeperList. I also made some of the pretty-printing in HsExpr rather more vigorous about increasing the depth; in particular, pprParendExpr. This should make debug prints shorter.
* Outputable.cparenPepe Iborra2007-04-201-1/+3
|
* Module header tidyup #2Simon Marlow2006-10-111-7/+6
| | | | Push this further along, and fix build problems in the first patch.
* some bug-fixes, newtype deriving might work nowManuel M T Chakravarty2006-09-201-0/+1
| | | | | | | | Mon Sep 18 14:33:01 EDT 2006 Manuel M T Chakravarty <chak@cse.unsw.edu.au> * some bug-fixes, newtype deriving might work now Sat Aug 5 21:29:28 EDT 2006 Manuel M T Chakravarty <chak@cse.unsw.edu.au> * some bug-fixes, newtype deriving might work now Tue Jul 11 12:16:13 EDT 2006 kevind@bu.edu
* Generalise Package SupportSimon Marlow2006-07-251-22/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch pushes through one fundamental change: a module is now identified by the pair of its package and module name, whereas previously it was identified by its module name alone. This means that now a program can contain multiple modules with the same name, as long as they belong to different packages. This is a language change - the Haskell report says nothing about packages, but it is now necessary to understand packages in order to understand GHC's module system. For example, a type T from module M in package P is different from a type T from module M in package Q. Previously this wasn't an issue because there could only be a single module M in the program. The "module restriction" on combining packages has therefore been lifted, and a program can contain multiple versions of the same package. Note that none of the proposed syntax changes have yet been implemented, but the architecture is geared towards supporting import declarations qualified by package name, and that is probably the next step. It is now necessary to specify the package name when compiling a package, using the -package-name flag (which has been un-deprecated). Fortunately Cabal still uses -package-name. Certain packages are "wired in". Currently the wired-in packages are: base, haskell98, template-haskell and rts, and are always referred to by these versionless names. Other packages are referred to with full package IDs (eg. "network-1.0"). This is because the compiler needs to refer to entities in the wired-in packages, and we didn't want to bake the version of these packages into the comiler. It's conceivable that someone might want to upgrade the base package independently of GHC. Internal changes: - There are two module-related types: ModuleName just a FastString, the name of a module Module a pair of a PackageId and ModuleName A mapping from ModuleName can be a UniqFM, but a mapping from Module must be a FiniteMap (we provide it as ModuleEnv). - The "HomeModules" type that was passed around the compiler is now gone, replaced in most cases by the current package name which is contained in DynFlags. We can tell whether a Module comes from the current package by comparing its package name against the current package. - While I was here, I changed PrintUnqual to be a little more useful: it now returns the ModuleName that the identifier should be qualified with according to the current scope, rather than its original module. Also, PrintUnqual tells whether to qualify module names with package names (currently unused). Docs to follow.
* Reorganisation of the source treeSimon Marlow2006-04-071-0/+540
Most of the other users of the fptools build system have migrated to Cabal, and with the move to darcs we can now flatten the source tree without losing history, so here goes. The main change is that the ghc/ subdir is gone, and most of what it contained is now at the top level. The build system now makes no pretense at being multi-project, it is just the GHC build system. No doubt this will break many things, and there will be a period of instability while we fix the dependencies. A straightforward build should work, but I haven't yet fixed binary/source distributions. Changes to the Building Guide will follow, too.
View Lorry Controller Status