GitLab

Fixed reading and generating VectInfo as well as naming of vectorised versions of imported identifiers

Functions and types can now be post-hoc vectorised; i.e., in modules where they are not declared, but only imported

- Types already gained this functionality already in a previous commit
- This commit adds the capability for functions

This is a crucial step towards being able to use the standard Prelude, instead of a special vectorised one.

This patch (and its TH counterpart) implements
   Trac #4429 (lookupTypeName, lookupValueName)
   Trac #5406 (reification of type/data family instances)

See detailed discussion in those tickets.

TH.ClassInstance is no more; instead reifyInstances returns a [Dec],
which requires fewer data types and natuarally accommodates family
instances.

'reify' on a type/data family now returns 'FamilyI', a new data
constructor in 'Info'

Mainly affecting how declarations are printed
Ie by default: laid out with no braces

The issue is that in
    instnace C T where
      data S = ...
      f = ...
neither S nor f is really a binder; they are *occurrences*.  Moreover
Haskell dictates that these particular occurrences are disambiguated
by looking at the class whose instance they occur in.

Some of this was not handled right for associated types.  And
RnNames.getLocalNonValBinders was a bit messhy; this patch tidies it
up.

(And thenM is finally gone from RnSource.)

Just as we want to display a data constructor as part of its
parent data type declaration, so with associated types.  This
was simply missing before.

Previously :browse M (without !) printed output relative to
a context that was neither the current one, nor the top-level
context of M, but rather that established
by
     import Prelude
     import M
This was pretty confusing, so Simon and I agreed to use
a simple, uniform rule: output in GHC is always relative
to the current context.

This patch is allowed by the 'on ARMv7 with VFPv3[D16] support pass
 appropriate -mattr value to LLVM llc' patch. The trick is that LLVM
by default (probably!) does not enable VFP, but GHC requires it
so LLVM's llc asserts on unavailable floating point register. i.e. GHC/LLVM
backend compiles into LLVM code which is using floats, but llc thinks
no float regs for this are available. Passing appropriate llc option
which is implemented in patch mentioned above fixes this issue.

This patch enhances ArchARM with ARM ISA and ISA extensions details
as is suggested in the comment in Platform.hs file. The patch is needed
by future patch which will use ARM ISA information in order to pass
appropriate command-line option to the LLVM llc tool.

Until the type checker can use vectorised signatures, we restrict the RHS of VECTORISE pragmas to be a single identifier only.

- This removes the need to be careful about the order of dictionaries during type inference. A property that is too fragile to try to maintain in the type checker.

Problem is with GADTs in new code gen and incomplete pattern
warnings. Just disabled the warning really and created #5424
to track an actual fix.

- Pragma to determine how a given type is vectorised
- At this stage only the VECTORISE SCALAR variant is used by the vectoriser.
- '{-# VECTORISE SCALAR type t #-}' implies that 't' cannot contain parallel arrays and may be used in vectorised code.  However, its constructors can only be used in scalar code.  We use this, e.g., for 'Int'.
- May be used on imported types

See also http://hackage.haskell.org/trac/ghc/wiki/DataParallel/VectPragma

This patch makes a number of related improvements

a) Implements the Haskell Prime semantics for pattern bindings
   (Trac #2357).  That is, a pattern binding p = e is typed
   just as if it had been written
        t = e
        f = case t of p -> f
        g = case t of p -> g
        ... etc ...
   where f,g are the variables bound by p. In paricular it's
   ok to say
      (f,g) = (\x -> x, \y -> True)
   and f and g will get propertly inferred types
      f :: a -> a
      g :: a -> Int

b) Eliminates the MonoPatBinds flag altogether.  (For the moment
   it is deprecated and has no effect.)  Pattern bindings are now
   generalised as per (a).  Fixes Trac #2187 and #4940, in the
   way the users wanted!

c) Improves the OutsideIn algorithm generalisation decision.
   Given a definition without a type signature (implying "infer
   the type"), the published algorithm rule is this:
      - generalise *top-level* functions, and
      - do not generalise *nested* functions
   The new rule is
      - generalise a binding whose free variables have
        Guaranteed Closed Types
      - do not generalise other bindings

   Generally, a top-level let-bound function has a Guaranteed
   Closed Type, and so does a nested function whose free vaiables
   are top-level functions, and so on. (However a top-level
   function that is bitten by the Monomorphism Restriction does
   not have a GCT.)

   Example:
     f x = let { foo y = y } in ...
   Here 'foo' has no free variables, so it is generalised despite
   being nested.

d) When inferring a type f :: ty for a definition f = e, check that
   the compiler would accept f :: ty as a type signature for that
   same definition.  The type is rejected precisely when the type
   is ambiguous.

   Example:
      class Wob a b where
        to :: a -> b
        from :: b -> a

      foo x = [x, to (from x)]
   GHC 7.0 would infer the ambiguous type
      foo :: forall a b. Wob a b => b -> [b]
   but that type would give an error whenever it is called; and
   GHC 7.0 would reject that signature if given by the
   programmer.  The new type checker rejects it up front.

   Similarly, with the advent of type families, ambiguous types are
   easy to write by mistake.  See Trac #1897 and linked tickets for
   many examples.  Eg
      type family F a :: *
      f ::: F a -> Int
      f x = 3
   This is rejected because (F a ~ F b) does not imply a~b.  Previously
   GHC would *infer* the above type for f, but was unable to check it.
   Now even the inferred type is rejected -- correctly.

The main implemenation mechanism is to generalise the abe_wrap
field of ABExport (in HsBinds), from [TyVar] to HsWrapper. This
beautiful generalisation turned out to make everything work nicely
with minimal programming effort.  All the work was fiddling around
the edges; the core change was easy!

See Note [Looking up Exact RdrNames] in RnEnv

A long standing bug. The patch fixes Trac #5410

safified array package is not in 7.2.1

discard all the sparks from each Capability, but we were forgetting to
account for the discarded sparks in the stats, leading to a failure of
the assertion that tests the spark invariant.

I've moved the discarding of sparks to just before the GC, to avoid
race conditions, and counted the discarded sparks as GC'd.