Signed-off-by: Austin Seipp <austin@well-typed.com>

This patch implements Pattern Synonyms (enabled by -XPatternSynonyms),
allowing y ou to assign names to a pattern and abstract over it.

The rundown is this:

  * Named patterns are introduced by the new 'pattern' keyword, and can
    be either *unidirectional* or *bidirectional*. A unidirectional
    pattern is, in the simplest sense, simply an 'alias' for a pattern,
    where the LHS may mention variables to occur in the RHS. A
    bidirectional pattern synonym occurs when a pattern may also be used
    in expression context.

  * Unidirectional patterns are declared like thus:

        pattern P x <- x:_

    The synonym 'P' may only occur in a pattern context:

        foo :: [Int] -> Maybe Int
        foo (P x) = Just x
        foo _     = Nothing

  * Bidirectional patterns are declared like thus:

        pattern P x y = [x, y]

    Here, P may not only occur as a pattern, but also as an expression
    when given values for 'x' and 'y', i.e.

        bar :: Int -> [Int]
        bar x = P x 10

  * Patterns can't yet have their own type signatures; signatures are inferred.

  * Pattern synonyms may not be recursive, c.f. type synonyms.

  * Pattern synonyms are also exported/imported using the 'pattern'
    keyword in an import/export decl, i.e.

        module Foo (pattern Bar) where ...

    Note that pattern synonyms share the namespace of constructors, so
    this disambiguation is required as a there may also be a 'Bar'
    type in scope as well as the 'Bar' pattern.

  * The semantics of a pattern synonym differ slightly from a typical
    pattern: when using a synonym, the pattern itself is matched,
    followed by all the arguments. This means that the strictness
    differs slightly:

        pattern P x y <- [x, y]

        f (P True True) = True
        f _             = False

        g [True, True] = True
        g _            = False

    In the example, while `g (False:undefined)` evaluates to False,
    `f (False:undefined)` results in undefined as both `x` and `y`
    arguments are matched to `True`.

For more information, see the wiki:

    https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms
    https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms/Implementation



Reviewed-by: Simon Peyton Jones <simonpj@microsoft.com>
Signed-off-by: Austin Seipp <austin@well-typed.com>

Signed-off-by: Austin Seipp <austin@well-typed.com>

The main change is to add a case to `reduceTyFamApp_maybe` to evaluate
built-in type constructors (e.g., (+), (*), and friends).

To avoid problems with recursive modules, I moved the definition of
TcBuiltInSynFamily from `FamInst` to `FamInstEnv`.  I am still not sure if
this is the right place.

There is also a wibble that it'd be nice to fix:

when we evaluate a built-in type function, using`sfMatchFam`, we get
a `TcCoercion`.  However, `reduceTyFamApp_maybe` needs a `Corecion`.
I couldn't find a nice way to convert between the two, so I resorted to
a bit of hack (marked with `XXX`).

The hack is that we happen to know that the built-in constructors for
the type-nat functions always return coercions of shape `TcAxiomRuleCo`,
with no assumptions, so it easy to convert `TcCoercion` to `Coercion`
in this one case.  This is enough to make things work, but it is clearly
a cludge.

width and element type.

SIMD primops are now polymorphic in vector size and element type, but
only internally to the compiler. More specifically, utils/genprimopcode
has been extended so that it "knows" about SIMD vectors. This allows us
to, for example, write a single definition for the "add two vectors"
primop in primops.txt.pp and have it instantiated at many vector types.
This generates a primop in GHC.Prim for each vector type at which "add
two vectors" is instantiated, but only one data constructor for the
PrimOp data type, so the code generator is much, much simpler.

This commit exposes GHC's internal compiler pipeline through a `Hooks`
module in the GHC API. It currently allows you to hook:

 * Foreign import/exports declarations
 * The frontend up to type checking
 * The one shot compilation mode
 * Core compilation, and the module iface
 * Linking and the phases in DriverPhases.hs
 * Quasiquotation

Authored-by: Luite Stegeman <stegeman@gmail.com>
Authored-by: Edsko de Vries <edsko@well-typed.com>
Signed-off-by: Austin Seipp <austin@well-typed.com>

In 6579a6c7 we removed existing comparison primops and introduced new ones
returning Int# instead of Bool. This commit (and associated commits in
array, base, dph, ghc-prim, integer-gmp, integer-simple, primitive, testsuite and
template-haskell) restores old names of primops. This allows us to keep
our API cleaner at the price of not having backwards compatibility.

This patch also temporalily disables fix for #8317 (optimization of
tagToEnum# at Core level). We need to fix #8326 first, otherwise
our primops code will be very slow.

twanvl authored Sep 11, 2013 and Herbert Valerio Riedel committed Sep 18, 2013

This commit adds a `{-# MINIMAL #-}` pragma, which defines the possible
minimal complete definitions for a class. The body of the pragma is a
boolean formula of names.

The old warning for missing methods is replaced with this new one.

Note: The interface file format is changed to store the minimal complete
definition.

Authored-by: Twan van Laarhoven <twanvl@gmail.com>
Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>

This patch implements some simple evaluation of type-level expressions
featuring natural numbers.  We can evaluate *concrete* expressions that
use the built-in type families (+), (*), (^), and (<=?), declared in
GHC.TypeLits.   We can also do some type inference involving these
functions.  For example, if we encounter a constraint such as `(2 + x) ~ 5`
we can infer that `x` must be 3.  Note, however, this is used only to
resolve unification variables (i.e., as a form of a constraint improvement)
and not to generate new facts.  This is similar to how functional
dependencies work in GHC.

The patch adds a new form of coercion, `AxiomRuleCo`, which makes use
of a new form of axiom called `CoAxiomRule`.  This is the form of evidence
generate when we solve a constraint, such as `(1 + 2) ~ 3`.

The patch also adds support for built-in type-families, by adding a new
form of TyCon rhs: `BuiltInSynFamTyCon`.  such built-in type-family
constructors contain a...

In 9e133b, the build was modified to pass -fcmm-sink to Parser, but
unfortunately Parser specifies -O0 in its OPTIONS_GHC directive, meaning
the sinking pass was actually turned off.

HC_OPTS is the last thing passed to the compiler for that source file
however, so the correct fix is to also move -O0 out into the build
system as well.

This was uncovered thanks to a build report from Kazu Yamamoto. Thanks
to Jan Stolarek for eyeballing this bug and finding it.

Signed-off-by: Austin Seipp <aseipp@pobox.com>

Parser.hs needs to be compiled with -fcmm-sink on x86 platforms, so the
register allocator doesn't run out of stack slots. Previously, we had to
do some CPP hacks in order to emit an #ifdef into the file - this is
because we preprocess it once up front, and run the preprocessor again
when we compile it.

There's two cases: the boostrap compiler is > 7.8, and the stage1 parser
needs the flag, or the stage1 compiler is compiling the stage2
Parser.hs, and needs the flag..

The previous approach was super fragile with Clang. The more principled
fix is to instead do this through the build system.

This fixes #8182.

Signed-off-by: Austin Seipp <aseipp@pobox.com>

unsafeInterleaveIO is used instead of unsafeDupableInterleaveIO because
a mk_supply thunk that is simultaneously entered by two threads should
evaluate to the same UniqSupply.

The UniqSupply counter is now incremented atomically using the RTS's
atomic_inc().

To mitigate the extra overhead of unsafeInterleaveIO in the
single-threaded compiler, noDuplicate# is changed to exit early when
n_capabilities == 1.

The solution is to use a different notion of apartness. See
http://research.microsoft.com/en-us/um/people/simonpj/papers/ext-f/axioms-extended.pdf
for the gory details. Some comments are also in Notes [Compatibility]
and [Apartness] in FamInstEnv.

When GHCi makes temporary DLLs, those also need to be linked against
the right RTS, or we won't be able to load them.

We used to have to explicitly pass -lffi when linking the compiler,
but it's no longer necessary.

Fixes #7780.

In particular, this means that GHCi will use DLLs, rather than loading
object files itself.

We now put a handful of modules in a separate DLL.
For now the list is hand-written, but we could automate it in the
future.

and use them for split

This makes the build system a little simpler, and in particular
will make it easier to handle the changes needed for cross-compilation.

This removes the '.PHONY' rule, so means that "make" in a built tree
won't repeat the check.

We also now check the .cabal files for the executables as well as the
libraries.

We have two cases:
 1. building a cross-compiler
 2. compiling GHC to run on a foreign platform

These two are done with almost the same setup: (1) is the stage 1
compiler, and (2) is the stage 2 compiler, when CrossCompiling=YES.

The only difference between (1) and (2) is that you if you set up the
build for (1), then it stops before stage 2 and you can 'make install'
to install stage 1.

Unfortunately, (2) didn't work, and the build system code needed some
tidying up.

Change to the way the build is set up:

Before
------

To build a cross-compiler:
  ./configure --target=<..>

To compile a foreign GHC:
  ./configure --host=<..> --target=<..>

Now
---

To build a cross-compiler:
  ./configure --target=<..>
  And set "Stage1Only=YES" in mk/build.mk

To compile a foreign GHC:
  ./configure --target=<..>

We want to compile the sources only once, and to produce both vanilla
and dyn object files. This means that the sources can't differ for the
two ways.

This needed a bit of a kludge to get keepCAFsForGHCi included only in
the dynamic library.

DeriveConstants.hs works in a cross-compilation-friendly way. Rather
than running a C program that prints out the constants, we just compile
a C file which has the constants are encoded in symbol sizes. We then
parse the output of 'nm' to find out what the constants are.

Based on work by Gabor Greif <ggreif@gmail.com>.

gcc couldn't find ghc_boot_platform.h. I'm not sure why it worked on
Linux.

We shouldn't be generating files in the source directories