| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Basically, if the user has written:
class Foo a where
bar :: a -> a
{-# INLINE bar #-}
Then we should error out because there is no default method corresponding
to the `bar' INLINE pragma. This patch achieves this by splitting the
signatures for a class declaration apart into two sets: one that applies
to the defaults (INLINE, SPECIALISE), and one which defines the class itself
(fixity, type signatures). The two sets are then renamed in different contexts.
|
| |\ |
|
| | | |
|
| | |\ |
|
| | | | |
|
| | |/
|/|
| |
| |
| |
| |
| |
| |
| |
| | |
The bug here was that just using rnImports does not ensure that any dependent
orphan modules are loaded, so instances declared by such modules will not be
usable from the GHCi command line after an "import".
This did not affect the :m syntax because it takes a different code path and
uses getModuleExports directly, which contains its own calls to the orphan-module
loading stuff.
|
| |\ \
| |/ |
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Current precedence rules in GHCi are that:
* User macros are *always* preferred in command resolution
* User macros that are defined earlier are preferred to those that
are defined earlier on
* Builtin commands have lowest precedence
However this caused user confusion because e.g. defining a macro beginning
with "i" would override the standard :info command whenever the user typed
the abbreviated command :i.
The new precedence rules are based on the view that things defined earlier
are always preferred to things defined later. The builtin commands are logically
defined earliest of all (when GHCi starts) so they always take precedence.
|
| |\ |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The problem was that the codegen for foreign calls makes sure the stack
is 16-byte aligned on OS X by pushing some padding. In the case where the
foreign call is cdecl, that padding gets popped after the call, but if the
convention is stdcall then it doesn't generate any popping code at all.
However, this is incorrect because the stdcall only promises to pop the
arguments, not the padding. The fix is to generate code to pop the padding
(if any) on OS X.
|
| |/ |
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
./sync-all fetch
Fetches remote changes from the "origin" for each sub-repo. Useful
before "./sync-all new".
(Runs 'git fetch origin' on all sub-repos.)
./sync-all new
Lists the new patches relative to "origin" for each sub-repo.
You probably want to './sync-all fetch' first.
(Runs 'git log origin..' on all sub-repos)
|
| |\ \
| |/
|/| |
|
| | |
| |
| |
| |
| |
| | |
Converted from a darcs patch from Max Bolingbroke:
Fri Apr 1 11:39:49 BST 2011 Max Bolingbroke <batterseapower@hotmail.com>
* Really zap case-binder occurrence info: solves #5028
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Use it like this
./sync-all -r http://darcs.haskell.org/ghc-git set-origin
to set the origin branches of all sub-repos to point to the appropriate
repo within the http://darcs.haskell.org/ghc-git tree.
|
| | | |
|
| | | |
|
| |/ |
|
| |
|
|
|
|
|
|
|
| |
We were not prioritizing the interaction of equalities in the worklist, because
pre-canonicalization solved the constraints one by one, in their arrival order.
This patch fixes this, so it's a generally useful improvement, mainly for
efficiency. It makes #4981 go away, although it's not a definite answer to the
cause of the problem. See discussion on Trac.
|
| |
|
|
|
| |
This patch just puts a better SrcSpan on the AbsBinds
produced by the type checker
|
| | |
|
| |
|
|
| |
(See Trac #3011.)
|
| |
|
|
| |
This just disables the coercion optimiser, mainly for measurements in the paper
|
| |
|
|
|
| |
This dumps a (one-line) listing of the size of the Core program,
just after tidying
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This fixes a couple of duplicates that had crept in, and also
renumbers everything so that they are monotonically increasing
through the file.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
The .hsc files aren't currently safe for cross-compilation on Windows:
libraries\haskeline\.\System\Console\Haskeline\Backend\Win32.hsc:160
directive "let" is not safe for cross-compilation
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Here's a bit of erroneous code:
00000c5c <s1ad_info>:
c5c: 8b 45 08 mov 0x8(%ebp),%eax
c5f: d9 46 03 flds 0x3(%esi)
c62: dd d9 fstp %st(1)
c64: d9 55 08 fsts 0x8(%ebp)
c67: 89 c6 mov %eax,%esi
c69: c7 45 00 24 0c 00 00 movl $0xc24,0x0(%ebp)
c70: f7 c6 03 00 00 00 test $0x3,%esi
c76: 75 ac jne c24 <s1ac_info>
So we should be doing some ffrees before the jne. The code that
inserts the ffrees wasn't expecting to do it for a conditional jump,
because they are usually local, but we have a late optimisation that
shortcuts jumps-to-jumps, and that can result in a non-local
conditional jump.
This at least fixes an instance of the bug that I was able to
reproduce, let's hope there aren't any more.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, -ddump-cmmz was used to dump out the "Raw Cmm" right
before it gets passed to the backends, as well as all of the
intermediate phases in the new code generator. Unfortunately,
there are a lot of intermediate phases, which means -ddump-cmmz
takes a very long time with -fnew-codegen for large programs,
even if you're only interested in the final result.
Here we split up -ddump-cmmz into -ddump-cmmz (now exclusively for
the new code generator) and -ddump-raw-cmm (for both code generation
paths.) The old flag was not documented in the manual, so hopefully
not too many people will be surprised by this change.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When allocating new objects on the heap, we previously returned
a CmmExpr containing the heap pointer as well as the tag expression,
which would be added to the code graph upon first usage. Unfortunately,
this meant that untagged heap pointers living in registers might
be spilled to the stack, where they interacted poorly with garbage
collection (we saw this bug specifically with the compacting garbage
collector.)
This fix immediately tags the register containing the heap pointer,
so that unless we have extremely unfriendly spill code, the new pointer
will never be spilled to the stack untagged.
An alternate solution might have been to modify allocDynClosure to
tag the pointer upon the initial register allocation, but not all
invocations of allocDynClosure tag the resulting pointer, and
threading the consequent CgIdInfo for the cases that did would have
been annoying.
|
| |
|
|
|
|
| |
This fixes the Lint error, but still risks leaving stupid
let { x=y } bindings in the code. But no time to fix that
today. (Leave the ticket open for that reason.)
|
