- 10 Aug, 2006 7 commits
-
-
simonpj@microsoft.com authored
I'm being more paranoid about repeatedly simplifying things (to avoid exponential behaviour.) postInlineUnconditionally looks as if it could repeated simplify the same expression; this patch stops it doing so. The extra lines are all comments!
-
Simon Marlow authored
-
Simon Marlow authored
-
Simon Marlow authored
-
Simon Marlow authored
-
simonpj@microsoft.com authored
This terrible bug in tcLHsConTy is pretty much guaranteed to show up on an program involving a GADT with more than one type parameter. This bug isn't present in the STABLE branch. Manuel: it is *not* necesary to merge this patch into the FC branch; just ignore it.
-
simonpj@microsoft.com authored
-
- 09 Aug, 2006 14 commits
-
-
ei@vuokko.info authored
-
ei@vuokko.info authored
-
Simon Marlow authored
This fixes building the compiler with -prof in $(GhcStage1HcOpts)
-
Simon Marlow authored
-
Simon Marlow authored
-
Simon Marlow authored
-
Simon Marlow authored
-
Simon Marlow authored
-
Simon Marlow authored
-
Ross Paterson authored
-
Ross Paterson authored
-
Simon Marlow authored
See #805. This was here to catch bugs that resulted in an infinite number of worker threads being created. However, we can't put a reasonable bound on the number of worker threads, because legitimate programs may need to create large numbers of (probably blocked) worker threads. Furthermore, the OS probably has a bound on the number of threads that a process can create in any case.
-
Simon Marlow authored
See #815
-
Simon Marlow authored
See #753
-
- 08 Aug, 2006 5 commits
-
-
simonpj@microsoft.com authored
Actually this patch fixes two errors. one was a trivial typo in tha last patch (b_ty should be b_tau), which led to an infinite loop when compiling Data.Generic.Twins. Fixing that revealed a more serious error in the same function. I was sloppy about dealing robsutly with name-capture for nested quantifiers in pre-subsumption and pre-matching; and sure enough I got bitten. Sigh. I think it is right now.
-
simonpj@microsoft.com authored
-
simonpj@microsoft.com authored
A lazy pattern match must be for a lifted type. This is illegal: f x = case g x of ~(# x,y #) -> ... This commit fixes the problem. Trac #845, test is tcfail159
-
simonpj@microsoft.com authored
-
simonpj@microsoft.com authored
srcSpanStartLine/srcSpanEndLine panic on UnhelpfulLoc. They should not really be exported by SrcLoc at all, but unfortunately they are used in Lexer.x, which knows enough to avoid the panic. However the call in RnEnv didn't know, and the panic was triggered by Template Haskell spliced code. This patch fixes it by exporting the predicate RnEnv wanted, namely isOneLineSpan.
-
- 06 Jul, 2006 3 commits
-
-
duncan.coutts@worc.ox.ac.uk authored
Just because we can and because every other compiler does, lets stick in an identifier directive: .ident "GHC x.y.z" into the assembly output of the NCG.
-
duncan.coutts@worc.ox.ac.uk authored
On recent GNU ELF systems one can mark an object file as not requiring an executable stack. If all objects- linked into a program have this note then the program will not use an executable stack, which is good for security (and some distros have it as a QA policy). GHC generated code does not need an executable stack so add the note to the assembly output of the native code generator (conditional on a configure test).
- 03 Jul, 2006 1 commit
-
-
duncan.coutts@worc.ox.ac.uk authored
previously hsc2hs just exits with a non-zero exit code, now if any of the compilation, linking or runing phases fail then we get a message saying so and the failing command is printed.
-
- 08 Aug, 2006 3 commits
-
-
Simon Marlow authored
Patch mostly from Lennart Augustsson in #803, with additions to Task.c by me.
-
simonpj@microsoft.com authored
The pre-subsuption and pre-matching functions should NEVER make bogus bindings of type variables, although they are free to bale out and make too few bindings. I hadn't been thiking carefully enough about this, and there were two separate bugs. - Firstly, in pre-subsumption we must ignore the 'theta' part of any overloaded type. - Second, in pre-matching, we must return the empty subustition on a mis-match, rather than returning the substitution so far. This bug showed up when compiling Data.Generics.Schemes.hs, and is imortalised in test tc206
-
simonpj@microsoft.com authored
Improve a little-used error message. Given f :: a -> a f x y = e the error says The equations for f have two arguments but its type `a -> a' has only one (Before, it said "its type `a' has only one" which is bogus.
-
- 10 Jul, 2006 2 commits
-
-
Ian Lynagh authored
-
Ian Lynagh authored
-
- 09 Jul, 2006 2 commits
-
-
Ian Lynagh authored
-
Ian Lynagh authored
-
- 08 Jul, 2006 1 commit
-
-
Ian Lynagh authored
prof_file was being fclose'd in both gen_XML_logfile and hs_exit, leading to glibc complaining of a double free.
-
- 07 Aug, 2006 2 commits
-
-
simonpj@microsoft.com authored
Add -fextended-deafult-rules (in response to Don Stewart's message below), and document them. Also doucument -fmono-pat-binds/-fno-mono-pat-binds, which has been in GHC a few weeks now. (The two are in one patch because the diffs were so close together that Darcs combined them.) Simon From: Donald Bruce Stewart [mailto:dons@cse.unsw.edu.au] Sent: 07 August 2006 10:52 While we're thinking about defaulting, I have a question.. ghci uses an extended defaulting system, to allow things like: Prelude> reverse [] [] to work, and to have the right instance of Show found. The manual says: "..it is tiresome for the user to have to specify the type, so GHCi extends Haskell's type-defaulting rules (Section 4.3.4 of the Haskell 98 Report (Revised)) as follows. If the expression yields a set of type constraints that are all from standard classes (Num, Eq etc.), and at least one is either a numeric class or the Show, Eq, or Ord class, GHCi will try to use one of the default types, just as described in the Report. The standard defaulting rules require that one of the classes is numeric; the difference here is that defaulting is also triggered at least one is Show, Eq, or Ord." Currently, there is no way to get at this "extended" defaulting for compiled modules. However, I have a use case for in fact doing this. With runtime evaluated Haskell, embedding 'interpreters' (over hs-plugins) is easy. lambdabot, for example, implements a sandboxed haskell eval system. But it doesn't have access to the defaulting mechanism of ghci, so we have: dons:: > reverse [] lambdabot:: Add a type signature dons:: > reverse [] :: [()] lambdabot:: [] Which is annoying -- newbies wonder why they have to add these extra constraints to get a Show instance. I'm wondering, since the extended defaulting mechanisms are already implemented, could they be made available to compiled modules as well, perhaps using a flag, -fextended-defaulting?
-
Simon Marlow authored
-