GitLab

Needed by #5357

Needed by #5357

Needed by #5357

We were mislabelling some foreign imports as IsData rather than
IsFunction, because the type was forall a. FunPtr (... a ...).

Eventually this gave rise to these obscure error when compiling
unregisterised:

libraries/base/Foreign/Marshal/Alloc.hc:473:0:
     warning: built-in function ‘free’ declared as non-function

libraries/base/Foreign/Marshal/Alloc.hc:1004:0:
     error: ‘free’ redeclared as different kind of symbol

Joachim Breitner authored Jan 01, 2012 and Simon Marlow committed Jan 04, 2012

Fixes: #5733

It doesn't hurt to map these to ArchUnknown since we don't need to
know anything specific about them, and adding them would be a pain
(there are a bunch of places where we have to case-match on all the
arches to avoid warnings).

Another portabilty regression: before Platform we used to use elf_OBJ_FORMAT:

 #if linux_TARGET_OS || freebsd_TARGET_OS || openbsd_TARGET_OS || solaris2_TARGET_OS
 #define elf_OBJ_FORMAT 1
 #endif

which defaults to undefined on unknown platforms.  Defaulting to
non-ELF is correct, it just means that we won't rely on ELF-specific
functionality.  I've added a comment to explain that.

Now target32bit works for all targets without any manual intervention,
as it should do.  #5735 was a portability regression.

Modified version of a patch by shelarcy <shelarcy@gmail.com>

We don't want

    ghc --make M -o <file>

to force recompilation of all modules when <file> changes.  The -o
value is already taken into account by the recompilation machinery
when we check the modification time on the object file or the
executable.

For some reason we were printing every occurrence with its type
and that is far too much.

This patch should have no user-visible effect.  It implements a
significant internal refactoring of the way that FC axioms are
handled.  The ultimate goal is to put us in a position to implement
"pattern-matching axioms".  But the changes here are only does
refactoring; there is no change in functionality.

Specifically:

 * We now treat data/type family instance declarations very,
   very similarly to types class instance declarations:

   - Renamed InstEnv.Instance as InstEnv.ClsInst, for symmetry with
     FamInstEnv.FamInst.  This change does affect the GHC API, but
     for the better I think.

   - Previously, each family type/data instance declaration gave rise
     to a *TyCon*; typechecking a type/data instance decl produced
     that TyCon.  Now, each type/data instance gives rise to
     a *FamInst*, by direct analogy with each class instance
     declaration giving rise to a ClsInst.

   - Just as each ClsInst contains its evidence, a DFunId, so each FamInst
     contains its evidence, a CoAxiom.  See Note [FamInsts and CoAxioms]
     in FamInstEnv.  The CoAxiom is a System-FC thing, and can relate any
     two types, whereas the FamInst relates directly to the Haskell source
     language construct, and always has a function (F tys) on the LHS.

   - Just as a DFunId has its own declaration in an interface file, so now
     do CoAxioms (see IfaceSyn.IfaceAxiom).

   These changes give rise to almost all the refactoring.

 * We used to have a hack whereby a type family instance produced a dummy
   type synonym, thus
      type instance F Int = Bool -> Bool
   translated to
      axiom FInt :: F Int ~ R:FInt
      type R:FInt = Bool -> Bool
   This was always a hack, and now it's gone.  Instead the type instance
   declaration produces a FamInst, whose axiom has kind
      axiom FInt :: F Int ~ Bool -> Bool
   just as you'd expect.

 * Newtypes are done just as before; they generate a CoAxiom. These
   CoAxioms are "implicit" (do not generate an IfaceAxiom declaration),
   unlike the ones coming from family instance declarations.  See
   Note [Implicit axioms] in TyCon

On the whole the code gets significantly nicer.  There were consequential
tidy-ups in the vectoriser, but I think I got them right.

sdist output was being redirected to $src_log, which presumably
evaluated to rc_log.

and add intWithCommas to Outputable for printing
large Int/Integers

Such names can come from Template Haskell; see Trac #5700
Easily fixed, happily.

I also renamed lookupSubBndr to lookupSubBndrOcc, which is
more descriptive.

This is a tiny feature improvement; see the ticket.
I have updated the user manual too.

This is just a tidy-up triggered by #5719.  We were parsing () as a
type constructor, rather than as a HsTupleTy, but it's better dealt
with uniformly as the former, I think.  Somewhat a matter of taste.

for associated types (fixes Trac #5719)

The bug was that we ended up quantifying the new AT instance
over the wrong set of type variables, and that led to confusing
chaos.

See Trac #5720: make the unit unboxed tuple (# #) behave uniformly
with the unit boxed tuple ()

This is actually a change in behaviour, but in a very dark corner,
so I don't think this is going to hurt anyone, and the current
behaviour is deeply strange.

bug in zonking: we must zonk the kinds of existential variables even if
the variables themselves will not be affected.