summaryrefslogtreecommitdiff
path: root/ghc/compiler/utils
Commit message (Collapse)AuthorAgeFilesLines
* Reorganisation of the source treeSimon Marlow2006-04-0721-8188/+0
| | | | | | | | | | | | | | | 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.
* improve panic messages a bit, with the GHC version and platformSimon Marlow2006-03-141-4/+3
|
* Parse OPTIONS properly and cache the result.Lemmih2006-03-101-1/+30
| | | | | | | | | | | | | | | | | Use the lexer to parse OPTIONS, LANGUAGE and INCLUDE pragmas. This gives us greater flexibility and far better error messages. However, I had to make a few quirks: * The token parser is written manually since Happy doesn't like lexer errors (we need to extract options before the buffer is passed through 'cpp'). Still better than manually parsing a String, though. * The StringBuffer API has been extended so files can be read in blocks. I also made a new field in ModSummary called ms_hspp_opts which stores the updated DynFlags. Oh, and I took the liberty of moving 'getImports' into HeaderInfo together with 'getOptions'.
* Fix CPP failure by adding space before hASH_TBL_SIZEsimonpj@microsoft.com2006-02-091-1/+1
|
* add -dfaststring-stats to dump some stats about the FastString hash tableSimon Marlow2006-02-081-0/+25
|
* Add Bag.anyBag (analogous to List.any)simonpj@microsoft.com2006-02-031-1/+7
|
* Simon's big boxy-type commitsimonpj@microsoft.com2006-01-252-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This very large commit adds impredicativity to GHC, plus numerous other small things. *** WARNING: I have compiled all the libraries, and *** a stage-2 compiler, and everything seems *** fine. But don't grab this patch if you *** can't tolerate a hiccup if something is *** broken. The big picture is this: a) GHC handles impredicative polymorphism, as described in the "Boxy types: type inference for higher-rank types and impredicativity" paper b) GHC handles GADTs in the new simplified (and very sligtly less epxrssive) way described in the "Simple unification-based type inference for GADTs" paper But there are lots of smaller changes, and since it was pre-Darcs they are not individually recorded. Some things to watch out for: c) The story on lexically-scoped type variables has changed, as per my email. I append the story below for completeness, but I am still not happy with it, and it may change again. In particular, the new story does not allow a pattern-bound scoped type variable to be wobbly, so (\(x::[a]) -> ...) is usually rejected. This is more restrictive than before, and we might loosen up again. d) A consequence of adding impredicativity is that GHC is a bit less gung ho about converting automatically between (ty1 -> forall a. ty2) and (forall a. ty1 -> ty2) In particular, you may need to eta-expand some functions to make typechecking work again. Furthermore, functions are now invariant in their argument types, rather than being contravariant. Again, the main consequence is that you may occasionally need to eta-expand function arguments when using higher-rank polymorphism. Please test, and let me know of any hiccups Scoped type variables in GHC ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ January 2006 0) Terminology. A *pattern binding* is of the form pat = rhs A *function binding* is of the form f pat1 .. patn = rhs A binding of the formm var = rhs is treated as a (degenerate) *function binding*. A *declaration type signature* is a separate type signature for a let-bound or where-bound variable: f :: Int -> Int A *pattern type signature* is a signature in a pattern: \(x::a) -> x f (x::a) = x A *result type signature* is a signature on the result of a function definition: f :: forall a. [a] -> a head (x:xs) :: a = x The form x :: a = rhs is treated as a (degnerate) function binding with a result type signature, not as a pattern binding. 1) The main invariants: A) A lexically-scoped type variable always names a (rigid) type variable (not an arbitrary type). THIS IS A CHANGE. Previously, a scoped type variable named an arbitrary *type*. B) A type signature always describes a rigid type (since its free (scoped) type variables name rigid type variables). This is also a change, a consequence of (A). C) Distinct lexically-scoped type variables name distinct rigid type variables. This choice is open; 2) Scoping 2(a) If a declaration type signature has an explicit forall, those type variables are brought into scope in the right hand side of the corresponding binding (plus, for function bindings, the patterns on the LHS). f :: forall a. a -> [a] f (x::a) = [x :: a, x] Both occurences of 'a' in the second line are bound by the 'forall a' in the first line A declaration type signature *without* an explicit top-level forall is implicitly quantified over all the type variables that are mentioned in the type but not already in scope. GHC's current rule is that this implicit quantification does *not* bring into scope any new scoped type variables. f :: a -> a f x = ...('a' is not in scope here)... This gives compatibility with Haskell 98 2(b) A pattern type signature implicitly brings into scope any type variables mentioned in the type that are not already into scope. These are called *pattern-bound type variables*. g :: a -> a -> [a] g (x::a) (y::a) = [y :: a, x] The pattern type signature (x::a) brings 'a' into scope. The 'a' in the pattern (y::a) is bound, as is the occurrence on the RHS. A pattern type siganture is the only way you can bring existentials into scope. data T where MkT :: forall a. a -> (a->Int) -> T f x = case x of MkT (x::a) f -> f (x::a) 2a) QUESTION class C a where op :: forall b. b->a->a instance C (T p q) where op = <rhs> Clearly p,q are in scope in <rhs>, but is 'b'? Not at the moment. Nor can you add a type signature for op in the instance decl. You'd have to say this: instance C (T p q) where op = let op' :: forall b. ... op' = <rhs> in op' 3) A pattern-bound type variable is allowed only if the pattern's expected type is rigid. Otherwise we don't know exactly *which* skolem the scoped type variable should be bound to, and that means we can't do GADT refinement. This is invariant (A), and it is a big change from the current situation. f (x::a) = x -- NO; pattern type is wobbly g1 :: b -> b g1 (x::b) = x -- YES, because the pattern type is rigid g2 :: b -> b g2 (x::c) = x -- YES, same reason h :: forall b. b -> b h (x::b) = x -- YES, but the inner b is bound k :: forall b. b -> b k (x::c) = x -- NO, it can't be both b and c 3a) You cannot give different names for the same type variable in the same scope (Invariant (C)): f1 :: p -> p -> p -- NO; because 'a' and 'b' would be f1 (x::a) (y::b) = (x::a) -- bound to the same type variable f2 :: p -> p -> p -- OK; 'a' is bound to the type variable f2 (x::a) (y::a) = (x::a) -- over which f2 is quantified -- NB: 'p' is not lexically scoped f3 :: forall p. p -> p -> p -- NO: 'p' is now scoped, and is bound to f3 (x::a) (y::a) = (x::a) -- to the same type varialble as 'a' f4 :: forall p. p -> p -> p -- OK: 'p' is now scoped, and its occurences f4 (x::p) (y::p) = (x::p) -- in the patterns are bound by the forall 3b) You can give a different name to the same type variable in different disjoint scopes, just as you can (if you want) give diferent names to the same value parameter g :: a -> Bool -> Maybe a g (x::p) True = Just x :: Maybe p g (y::q) False = Nothing :: Maybe q 3c) Scoped type variables respect alpha renaming. For example, function f2 from (3a) above could also be written: f2' :: p -> p -> p f2' (x::b) (y::b) = x::b where the scoped type variable is called 'b' instead of 'a'. 4) Result type signatures obey the same rules as pattern types signatures. In particular, they can bind a type variable only if the result type is rigid f x :: a = x -- NO g :: b -> b g x :: b = x -- YES; binds b in rhs 5) A *pattern type signature* in a *pattern binding* cannot bind a scoped type variable (x::a, y) = ... -- Legal only if 'a' is already in scope Reason: in type checking, the "expected type" of the LHS pattern is always wobbly, so we can't bind a rigid type variable. (The exception would be for an existential type variable, but existentials are not allowed in pattern bindings either.) Even this is illegal f :: forall a. a -> a f x = let ((y::b)::a, z) = ... in Here it looks as if 'b' might get a rigid binding; but you can't bind it to the same skolem as a. 6) Explicitly-forall'd type variables in the *declaration type signature(s)* for a *pattern binding* do not scope AT ALL. x :: forall a. a->a -- NO; the forall a does Just (x::a->a) = Just id -- not scope at all y :: forall a. a->a Just y = Just (id :: a->a) -- NO; same reason THIS IS A CHANGE, but one I bet that very few people will notice. Here's why: strange :: forall b. (b->b,b->b) strange = (id,id) x1 :: forall a. a->a y1 :: forall b. b->b (x1,y1) = strange This is legal Haskell 98 (modulo the forall). If both 'a' and 'b' both scoped over the RHS, they'd get unified and so cannot stand for distinct type variables. One could *imagine* allowing this: x2 :: forall a. a->a y2 :: forall a. a->a (x2,y2) = strange using the very same type variable 'a' in both signatures, so that a single 'a' scopes over the RHS. That seems defensible, but odd, because though there are two type signatures, they introduce just *one* scoped type variable, a. 7) Possible extension. We might consider allowing \(x :: [ _ ]) -> <expr> where "_" is a wild card, to mean "x has type list of something", without naming the something.
* [project @ 2006-01-18 10:59:54 by simonmar]simonmar2006-01-181-1/+0
| | | | Remove dead panic
* [project @ 2006-01-18 10:58:15 by simonmar]simonmar2006-01-181-1/+0
| | | | | | Remove dead error (darcs patch from Ian Lynagh)
* [project @ 2006-01-12 16:16:28 by simonmar]simonmar2006-01-121-6/+15
| | | | | | | | | | | | | GHC.runStmt: run the statement in a new thread to insulate the environment from bad things that the user code might do, such as fork a thread to send an exception back at a later time. In order to do this, we had to keep track of which thread the ^C exception should go to in a global variable. Also, bullet-proof the top-level exception handler in GHCi a bit; there was a small window where an exception could get through, so if you lean on ^C for a while then press enter you could cause GHCi to exit.
* [project @ 2006-01-10 14:39:38 by simonmar]simonmar2006-01-101-1/+1
| | | | prevChar: don't back up over decoding errors
* [project @ 2006-01-10 09:47:51 by simonmar]simonmar2006-01-101-0/+6
| | | | Fix compilation with GHC 6.2.x, hopefully
* [project @ 2006-01-09 13:29:02 by simonmar]simonmar2006-01-091-2/+2
| | | | Avoid desugaring bug in HEAD (see test ds057).
* [project @ 2006-01-09 13:25:50 by simonmar]simonmar2006-01-094-39/+54
| | | | | | | | Fix up to compile with GHC 5.04.x again. Also includes a fix for a memory error I discovered along the way: should fix the "scavenge_one" crash in the stage2 build of recent HEADs.
* [project @ 2006-01-06 16:30:17 by simonmar]simonmar2006-01-069-888/+886
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for UTF-8 source files GHC finally has support for full Unicode in source files. Source files are now assumed to be UTF-8 encoded, and the full range of Unicode characters can be used, with classifications recognised using the implementation from Data.Char. This incedentally means that only the stage2 compiler will recognise Unicode in source files, because I was too lazy to port the unicode classifier code into libcompat. Additionally, the following synonyms for keywords are now recognised: forall symbol (U+2200) forall right arrow (U+2192) -> left arrow (U+2190) <- horizontal ellipsis (U+22EF) .. there are probably more things we could add here. This will break some source files if Latin-1 characters are being used. In most cases this should result in a UTF-8 decoding error. Later on if we want to support more encodings (perhaps with a pragma to specify the encoding), I plan to do it by recoding into UTF-8 before parsing. Internally, there were some pretty big changes: - FastStrings are now stored in UTF-8 - Z-encoding has been moved right to the back end. Previously we used to Z-encode every identifier on the way in for simplicity, and only decode when we needed to show something to the user. Instead, we now keep every string in its UTF-8 encoding, and Z-encode right before printing it out. To avoid Z-encoding the same string multiple times, the Z-encoding is cached inside the FastString the first time it is requested. This speeds up the compiler - I've measured some definite improvement in parsing at least, and I expect compilations overall to be faster too. It also cleans up a lot of cruft from the OccName interface. Z-encoding is nicely hidden inside the Outputable instance for Names & OccNames now. - StringBuffers are UTF-8 too, and are now represented as ForeignPtrs. - I've put together some test cases, not by any means exhaustive, but there are some interesting UTF-8 decoding error cases that aren't obvious. Also, take a look at unicode001.hs for a demo.
* [project @ 2005-12-13 12:18:51 by simonmar]simonmar2005-12-131-1/+1
| | | | | | | | | Update the bug reporting instructions, I've now installed a redirect from http://www.haskel.org/ghc/reportabug to the bug reporting instructions, just in case we want to move that page in the future.
* [project @ 2005-12-13 12:09:42 by simonmar]simonmar2005-12-131-3/+2
| | | | | | | In the panic message, point to the bug reporting page in the User's Guide rather than directly to the bug reporting page. That way people will see the bug reporting instructions as well as the direct link (which has now changed).
* [project @ 2005-11-16 12:55:58 by simonpj]simonpj2005-11-161-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Two significant changes to the representation of types 1. Change the representation of type synonyms Up to now, type synonym applications have been held in *both* expanded *and* un-expanded form. Unfortunately, this has exponential (!) behaviour when type synonyms are deeply nested. E.g. type P a b = (a,b) f :: P a (P b (P c (P d e))) This showed up in a program of Joel Reymont, now immortalised as typecheck/should_compile/syn-perf.hs So now synonyms are held as ordinary TyConApps, and expanded only on demand. SynNote has disappeared altogether, so the only remaining TyNote is a FTVNote. I'm not sure if it's even useful. 2. Eta-reduce newtypes See the Note [Newtype eta] in TyCon.lhs If we have newtype T a b = MkT (S a b) then, in Core land, we would like S = T, even though the application of T is then not saturated. This commit eta-reduces T's RHS, and keeps that inside the TyCon (in nt_etad_rhs). Result is that coreEqType can be simpler, and has less need of expanding newtypes.
* [project @ 2005-11-04 15:48:25 by simonmar]simonmar2005-11-041-0/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | - Add support for the GHC_PACKAGE_PATH environment variable, which specifies a :-separated (;-separated on Windows) list of package database files. If the list ends in : (; on Windows), then the normal user and global databases are added. GHC_PACKAGE_PATH is searched left-to-right for packages, like $PATH, but unlike -package-conf flags, which are searched right-to-left. This isn't ideal, but it seemed the least worst to me (command line flags always override right-to-left (except -i), whereas the PATH environment variable overrides left-to-right, I chose to follow the environment variable convention). I can always change it if there's an outcry. - Rationalise the interpretation of --user, --global, and -f on the ghc-pkg command line. The story is now this: --user and --global say which package database to *act upon*, they do not change the shape of the database stack. -f pushes a database on the stack, and also requests that the specified database be the one to act upon, for commands that modify the database. If a database is already on the stack, then -f just selects it as the one to act upon. This means you can have a bunch of databases in GHC_PACKAGE_PATH, and use -f to select the one to modify.
* [project @ 2005-10-25 12:48:35 by simonmar]simonmar2005-10-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Two changes from Krasimir Angelov, which were required for Visual Haskell: - messaging cleanup throughout the compiler. DynFlags has a new field: log_action :: Severity -> SrcSpan -> PprStyle -> Message -> IO () this action is invoked for every message generated by the compiler. This means a client of the GHC API can direct messages to any destination, or collect them up in an IORef for later perusal. This replaces previous hacks to redirect messages in the GHC API (hence some changes to function types in GHC.hs). - The JustTypecheck mode of GHC now does what it says. It doesn't run any of the compiler passes beyond the typechecker for each module, but does generate the ModIface in order that further modules can be typechecked. And one change from me: - implement the LANGUAGE pragma, finally
* [project @ 2005-08-12 14:43:04 by simonpj]simonpj2005-08-121-1/+1
| | | | Fix typos
* [project @ 2005-08-12 12:36:59 by simonmar]simonmar2005-08-121-44/+20
| | | | | | | | | | | | | | Use a better string hash: the previous one only took into account 3 characters from the string (0, N/2, N), leading to some bad collisions with lots of similar strings (eg. local names generated by the compiler). Worse, it had a bug in the N==2 case, which meant that it ignored one of the characters in the string completely. We now traverse the whole string, using the algorithm from Data.Hash which seems to work reasonably well. For good measure, I quadrupled the size of the hash table too, from 1000 to 4000 entries.
* [project @ 2005-08-12 10:47:48 by simonmar]simonmar2005-08-121-4/+10
| | | | | | inline unsafePerformIO for eqStrPrefix/eqStrPrefixBA. These functions are fairly time-critical pieces of the FastString system, and using unsafePerformIO here was causing unnecessary allocation.
* [project @ 2005-08-09 13:21:13 by simonmar]simonmar2005-08-091-2/+2
| | | | | | | | | | | | | mapUFM was strict in the structure of the tree, perhaps accidentally. In any case, this interacted badly with the use of mapVarEnv in SimplEnv.mkCoreSubst, which assumed that the map was lazy. mapUFM is now lazy in the structure of the tree, which matches the behaviour of FiniteMap.mapFM. This fixes some long compilation times, in particular HTMLMonad98.hs from WASH used to take 2 mins to compile without optimisation, now takes less than 20 seconds.
* [project @ 2005-08-02 14:56:50 by simonmar]simonmar2005-08-022-5/+5
| | | | | - move instance Show FastString into FastString module - instance Outputable FastString should use ftext instead of unpackFS
* [project @ 2005-07-28 12:57:13 by simonmar]simonmar2005-07-281-8/+14
| | | | | | | optimise instance for lists: now we record the length first followed by the elements. HEADS UP: changes interface file representation, rebuild your libraries.
* [project @ 2005-07-26 12:14:03 by simonmar]simonmar2005-07-263-27/+190
| | | | | | | | | | Add a layer of write buffering over Handle when dumping the output: this saves a lot of time because we're doing a lot of small writes, and Handle operations have a non-trivial constant overhead due to the thread-safety, exception-safety etc. This improvement results in about a 10% reduction in compile time for non-optimised, somewhat less for optimised compilation.
* [project @ 2005-07-19 16:44:50 by simonpj]simonpj2005-07-194-17/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | WARNING: this is a big commit. You might want to wait a few days before updating, in case I've broken something. However, if any of the changes are what you wanted, please check it out and test! This commit does three main things: 1. A re-organisation of the way that GHC handles bindings in HsSyn. This has been a bit of a mess for quite a while. The key new types are -- Bindings for a let or where clause data HsLocalBinds id = HsValBinds (HsValBinds id) | HsIPBinds (HsIPBinds id) | EmptyLocalBinds -- Value bindings (not implicit parameters) data HsValBinds id = ValBindsIn -- Before typechecking (LHsBinds id) [LSig id] -- Not dependency analysed -- Recursive by default | ValBindsOut -- After typechecking [(RecFlag, LHsBinds id)]-- Dependency analysed 2. Implement Mark Jones's idea of increasing polymoprhism by using type signatures to cut the strongly-connected components of a recursive group. As a consequence, GHC no longer insists on the contexts of the type signatures of a recursive group being identical. This drove a significant change: the renamer no longer does dependency analysis. Instead, it attaches a free-variable set to each binding, so that the type checker can do the dep anal. Reason: the typechecker needs to do *two* analyses: one to find the true mutually-recursive groups (which we need so we can build the right CoreSyn) one to find the groups in which to typecheck, taking account of type signatures 3. Implement non-ground SPECIALISE pragmas, as promised, and as requested by Remi and Ross. Certainly, this should fix the current problem with GHC, namely that if you have g :: Eq a => a -> b -> b then you can now specialise thus SPECIALISE g :: Int -> b -> b (This didn't use to work.) However, it goes further than that. For example: f :: (Eq a, Ix b) => a -> b -> b then you can make a partial specialisation SPECIALISE f :: (Eq a) => a -> Int -> Int In principle, you can specialise f to *any* type that is "less polymorphic" (in the sense of subsumption) than f's actual type. Such as SPECIALISE f :: Eq a => [a] -> Int -> Int But I haven't tested that. I implemented this by doing the specialisation in the typechecker and desugarer, rather than leaving around the strange SpecPragmaIds, for the specialiser to find. Indeed, SpecPragmaIds have vanished altogether (hooray). Pragmas in general are handled more tidily. There's a new data type HsBinds.Prag, which lives in an AbsBinds, and carries pragma info from the typechecker to the desugarer. Smaller things - The loop in the renamer goes via RnExpr, instead of RnSource. (That makes it more like the type checker.) - I fixed the thing that was causing 'check_tc' warnings to be emitted.
* [project @ 2005-07-11 10:46:42 by simonpj]simonpj2005-07-111-3/+12
| | | | Improvements to speakN, define speakNOf, move plural from TcSimplify
* [project @ 2005-07-11 09:48:19 by simonpj]simonpj2005-07-111-5/+15
| | | | Add speakN, and the ability to set printing depth
* [project @ 2005-05-23 09:50:26 by simonpj]simonpj2005-05-231-5/+6
| | | | Clarify code for splitLongestPrefix; no effect on behaviour
* [project @ 2005-05-21 15:12:00 by panne]panne2005-05-211-1/+1
| | | | Warning police: Use non-deprecated form of "foreign import"
* [project @ 2005-05-19 07:58:35 by simonpj]simonpj2005-05-192-27/+45
| | | | | | | | | | | | | | | | Catch an exception in Template Haskell code Merge to STABLE If the code run by a Template Haskell splice fails with, say, a pattern-match failure, we should not report it as a GHC panic. It's a bug in the user's program. This commit fixes up the exception handling to do the right thing. Fixes SourceForge item #1201666 TH_fail tests it.
* [project @ 2005-05-17 13:06:15 by simonmar]simonmar2005-05-171-1/+1
| | | | remove duplicate export
* [project @ 2005-05-17 13:05:45 by simonmar]simonmar2005-05-171-4/+4
| | | | Add showSDocDump
* [project @ 2005-05-17 11:01:59 by simonmar]simonmar2005-05-171-20/+9
| | | | Further tweaks to the filename handling.
* [project @ 2005-05-17 10:51:04 by simonmar]simonmar2005-05-171-10/+23
| | | | | | Rationalise the filename handling in a few places, taking some bits from the defunct System.FilePath library. Also fixes a bug I recently introduced in replaceFilenameDirectory.
* [project @ 2005-05-17 09:46:22 by simonmar]simonmar2005-05-171-1/+1
| | | | replaceFilenameSuffix: fix
* [project @ 2005-05-16 13:47:57 by simonmar]simonmar2005-05-161-18/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | Implement -x <suffix> flag to override the suffix of a filename for the purposes of determinig how it should be compiled. The usage is similar to gcc, except that we just use a suffix rather than a name for the language. eg. ghc -c -x hs hello.blah will pretend hello.blah is a .hs file. Another possible use is -x hspp, which skips preprocessing. This works for one-shot compilation, --make, GHCi, and ghc -e. The original idea was to make it possible to use runghc on a file that doesn't end in .hs, so changes to runghc will follow. Also, I made it possible to specify .c files and other kinds of files on the --make command line; these will be compiled to objects as normal and linked into the final executable. GHC API change: I had to extend the Target type to include an optional start phase, and also GHC.guessTarget now takes a (Maybe Phase) argument. I thought this would be half an hour, in fact it took half a day, and I still haven't documented it. Sigh.
* [project @ 2005-05-03 11:10:08 by simonpj]simonpj2005-05-031-1/+6
| | | | | | | | | Improve generation of 'duplicate import' warnings. This involved changing (actually simplifying) the definition of RdrName.ImportSpec. I'm not sure whether this one merits merging or not. Perhaps worth a try.
* [project @ 2005-04-04 11:55:11 by simonpj]simonpj2005-04-042-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit combines three overlapping things: 1. Make rebindable syntax work for do-notation. The idea here is that, in particular, (>>=) can have a type that has class constraints on its argument types, e.g. (>>=) :: (Foo m, Baz a) => m a -> (a -> m b) -> m b The consequence is that a BindStmt and ExprStmt must have individual evidence attached -- previously it was one batch of evidence for the entire Do Sadly, we can't do this for MDo, because we use bind at a polymorphic type (to tie the knot), so we still use one blob of evidence (now in the HsStmtContext) for MDo. For arrow syntax, the evidence is in the HsCmd. For list comprehensions, it's all built-in anyway. So the evidence on a BindStmt is only used for ordinary do-notation. 2. Tidy up HsSyn. In particular: - Eliminate a few "Out" forms, which we can manage without (e.g. - It ought to be the case that the type checker only decorates the syntax tree, but doesn't change one construct into another. That wasn't true for NPat, LitPat, NPlusKPat, so I've fixed that. - Eliminate ResultStmts from Stmt. They always had to be the last Stmt, which led to awkward pattern matching in some places; and the benefits didn't seem to outweigh the costs. Now each construct that uses [Stmt] has a result expression too (e.g. GRHS). 3. Make 'deriving( Ix )' generate a binding for unsafeIndex, rather than for index. This is loads more efficient. (This item only affects TcGenDeriv, but some of point (2) also affects TcGenDeriv, so it has to be in one commit.)
* [project @ 2005-03-31 10:16:33 by simonmar]simonmar2005-03-315-10/+12
| | | | | | | Tweaks to get the GHC sources through Haddock. Doesn't quite work yet, because Haddock complains about the recursive modules. Haddock needs to understand SOURCE imports (it can probably just ignore them as a first attempt).
* [project @ 2005-03-30 16:24:04 by simonmar]simonmar2005-03-301-4/+12
| | | | | | | | | | | | | | Add support for partial reloads in the GHC API. This is mainly for VS: when editing a file you don't want to continually reload the entire project whenever the current file changes, you want to reload up to and including the current file only. However, you also want to retain any other modules in the session that are still stable. I added a variant of :reload in GHCi to test this. You can say ':reload M' to reload up to module M only. This will bring M up to date, and throw away any invalidated modules from the session.
* [project @ 2005-03-30 01:12:51 by sof]sof2005-03-301-6/+6
| | | | canonicalize ffi decls
* [project @ 2005-03-24 16:14:00 by simonmar]simonmar2005-03-241-1/+14
| | | | | | | | | | | | | | Cleanup the upsweep strategy in GHC.load. Now it's hopefully clearer how we decide what modules to recompile, and which are "stable" (not even looked at) during a reload. See the comments for details. Also, I've taken some trouble to explicitly prune out things that aren't required before a reload, which should reduce the memory requirements for :reload in GHCi. Currently I believe it keeps most of the old program until the reload is complete, now it shouldn't require any extra memory.
* [project @ 2005-03-21 10:50:22 by simonmar]simonmar2005-03-211-0/+36
| | | | | | | | | | | | Complete the transition of -split-objs into a dynamic flag (looks like I half-finished it in the last commit). Also: complete the transition of -tmpdir into a dynamic flag, which involves some rearrangement of code from SysTools into DynFlags. Someday, initSysTools should move wholesale into initDynFlags, because most of the state that it initialises is now part of the DynFlags structure, and the rest could be moved in easily.
* [project @ 2005-03-18 13:37:27 by simonmar]simonmar2005-03-182-6/+161
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Flags cleanup. Basically the purpose of this commit is to move more of the compiler's global state into DynFlags, which is moving in the direction we need to go for the GHC API which can have multiple active sessions supported by a single GHC instance. Before: $ grep 'global_var' */*hs | wc -l 78 After: $ grep 'global_var' */*hs | wc -l 27 Well, it's an improvement. Most of what's left won't really affect our ability to host multiple sessions. Lots of static flags have become dynamic flags (yay!). Notably lots of flags that we used to think of as "driver" flags, like -I and -L, are now dynamic. The most notable static flags left behind are the "way" flags, eg. -prof. It would be nice to fix this, but it isn't urgent. On the way, lots of cleanup has happened. Everything related to static and dynamic flags lives in StaticFlags and DynFlags respectively, and they share a common command-line parser library in CmdLineParser. The flags related to modes (--makde, --interactive etc.) are now private to the front end: in fact private to Main itself, for now.
* [project @ 2005-03-09 10:38:17 by simonmar]simonmar2005-03-091-0/+5
| | | | | | Use a different magic number (0x1face64) for 64-bit interface files. This will prevent us trying to read the dictionary out of a 32-bit interface file on a 64-bit machine.
* [project @ 2005-03-08 17:12:51 by simonmar]simonmar2005-03-081-8/+22
| | | | | | | | | | Fix something that's been bugging me for a while: by default, -ddump-* output doesn't include uniques when it outputs internal names, but in most cases you need them because the output hasn't been tidied, so you end up doing -dppr-debug which is overkill. Now, -ddump-* prints uniques for internal names by default. This shouldn't affect anything else.
* [project @ 2005-01-28 12:55:17 by simonmar]simonmar2005-01-282-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rationalise the BUILD,HOST,TARGET defines. Recall that: - build is the platform we're building on - host is the platform we're running on - target is the platform we're generating code for The change is that now we take these definitions as applying from the point of view of the particular source code being built, rather than the point of view of the whole build tree. For example, in RTS and library code, we were previously testing the TARGET platform. But under the new rule, the platform on which this code is going to run is the HOST platform. TARGET only makes sense in the compiler sources. In practical terms, this means that the values of BUILD, HOST & TARGET may vary depending on which part of the build tree we are in. Actual changes: - new file: includes/ghcplatform.h contains platform defines for the RTS and library code. - new file: includes/ghcautoconf.h contains the autoconf settings only (HAVE_BLAH). This is so that we can get hold of these settings independently of the platform defines when necessary (eg. in GHC). - ghcconfig.h now #includes both ghcplatform.h and ghcautoconf.h. - MachRegs.h, which is included into both the compiler and the RTS, now has to cope with the fact that it might need to test either _TARGET_ or _HOST_ depending on the context. - the compiler's Makefile now generates stage{1,2,3}/ghc_boot_platform.h which contains platform defines for the compiler. These differ depending on the stage, of course: in stage2, the HOST is the TARGET of stage1. This was wrong before. - The compiler doesn't get platform info from Config.hs any more. Previously it did (sometimes), but unless we want to generate a new Config.hs for each stage we can't do this. - GHC now helpfully defines *_{BUILD,HOST}_{OS,ARCH} automatically in CPP'd Haskell source. - ghcplatform.h defines *_TARGET_* for backwards compatibility (ghcplatform.h is included by ghcconfig.h, which is included by config.h, so code which still #includes config.h will get the TARGET settings as before). - The Users's Guide is updated to mention *_HOST_* rather than *_TARGET_*. - coding-style.html in the commentary now contains a section on platform defines. There are further doc updates to come. Thanks to Wolfgang Thaller for pointing me in the right direction.
View Lorry Controller Status