Tue Jun 19 23:49:43 PDT 2007 [EMAIL PROTECTED]
* Turning off case liberation when using the hpc option, for now
Consider the following code
f = g (case v of
V a b -> a : t f)
where g is expensive. Liberate case will turn this into
f = g (case v of
On Wed, Jun 20, 2007 at 04:38:36PM +1000, Roman Leshchinskiy wrote:
> The parse error is because ndp uses some ghc extensions which Haddock
> doesn't understand. But why is Haddock run at all here? IMO, a separate
> make doc step is preferable to running it automatically. In any case, I
> assume
Hi all,
today, I tried to build the ghc-ndp branch from a fresh tree after two
weeks off. Ultimately, it sort of worked, but not without some pain.
I'll describe what I did and the problems I've encountered in the hope
that it will be helpful.
darcs get http://darcs.haskell.org/ghc-ndp --p
Build description = HEAD on i386-unknown-linux
(cam-02-unx.europe.corp.microsoft.com)
Build location= /playpen/ghc/nightly/HEAD-cam-02-unx
Build config file = /home/simonmar/nightly/site/msrc/conf-HEAD-cam-02-unx
Nightly build started on cam-02-unx at Tue Jun 19 19:30:00 BST 2007.
checki
Tue Jun 19 13:05:46 PDT 2007 Ian Lynagh <[EMAIL PROTECTED]>
* Add --core-only flag to push-all
M ./push-all -1 +9
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
Tue Jun 19 12:28:20 PDT 2007 Ian Lynagh <[EMAIL PROTECTED]>
* Add a push-all script
M ./boot +1
A ./push-all
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
Tue Jun 19 09:53:54 PDT 2007 [EMAIL PROTECTED]
* Improve misleading warning (Trac #1422)
M ./compiler/rename/RnNames.lhs -2 +2
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
Tue Jun 19 09:31:27 PDT 2007 [EMAIL PROTECTED]
* Test for Trac #1430
M ./tests/ghc-regress/typecheck/should_compile/all.T +1
A ./tests/ghc-regress/typecheck/should_compile/tc228.hs
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haske
Tue Jun 19 09:26:13 PDT 2007 [EMAIL PROTECTED]
* Fix a bug in the handling of implication constraints (Trac #1430)
Trac #1430 showed up quite a nasty bug in the handling of implication
constraints when we are *inferring* the type of a function.
See Note [Inference and implication cons
Tue Jun 19 09:26:03 PDT 2007 [EMAIL PROTECTED]
* Comments only
M ./compiler/typecheck/TcUnify.lhs +4
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
Tue Jun 19 01:46:34 PDT 2007 [EMAIL PROTECTED]
* Remove erroneous requirement to import Control.Monad.Fix when using mdo
See Trac #1426
M ./docs/users_guide/glasgow_exts.xml -7
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haske
Build results:
x86-64 Linux head:lost
x86 Windows head: pass
x86 Windows head fast:pass pass pass fail (failed stage1) pass pass
mnemosyne x86-64 Gentoo head: fail (failed stage1)
tnaur PPC OSX head: pass
x86-64 Linux head unreg: lost
Old unexpected t
12 matches
Mail list logo