Many are improvements!

(#8961)

We now do role inference on stupid datatype contexts, allowing a
lightweight role annotation syntax.

I don't want to fall back to gettimeofday(), because that might have a
different absolute value.

This bumps the amount of default reserved and committed stack for GHC
executables to 8mb, to work around #8870. A proper fix should happen in
7.8.2

See note [Windows stack usage] in SysTools for the details.

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

This reverts commit a79613a7.

This fixes Trac #8954.

There were actually three places where tuple occ-names
were parsed:
  - IfaceEnv.lookupOrigNameCache
  - Convert.isBuiltInOcc
  - OccName.isTupleOcc_maybe

I combined all three into TysWiredIn.isBuiltInOcc_maybe
Much nicer.

This addresses #8950. However, the problem isn't completely solved,
because the Prelude types' Typeable instances are not created by
AutoDeriveTypeable.

This is just making the parser behave more sensibly, and return
the list [x,y,z] from the signature
   x,y,z :: Int
rathe than [x,z,y] as now.

Turns out that the other use of sig_vars *did* do the right
thing already.

A palpable bug, although one that will rarely bite

This is a patch from FB's internal build of GHC that I'm pushing
upstream.

Author: Andrew Gallagher <agallagher@fb.com>

This diff adds simple thin archive support to ghc's linker code, which
basically just entails finding the member data from disk rather than
from inside the archive (except for the case of the symbol index and
gnu filename index, where the member data is still inline).

Right now there's a bug with Clang that prevents 'cabal haddock' from
working nicely. But there's an easy fix for now.

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

If the number of elements being copied is known statically this might
lead to the copy loop being unrolled in the backend.

Harmonize the indentation amount. The file mixed 4, 2, and in some
cases 3 spaces for indentation.

The copy array family of primops were moved out-of-line.

These array types are smaller than Array# and MutableArray# and are
faster when the array size is small, as they don't have the overhead
of a card table. Having no card table reduces the closure size with 2
words in the typical small array case and leads to less work when
updating or GC:ing the array.

Reduces both the runtime and memory allocation by 8.8% on my insert
benchmark for the HashMap type in the unordered-containers package,
which makes use of lots of small arrays. With tuned GC settings
(i.e. `+RTS -A6M`) the runtime reduction is 15%.

Fixes #8923.

This should reduce code size when there's little to gain from inlining
these primops, while still retaining the inlining benefit when the
size of the copy is known statically.

After a toolchain update, Clang is no longer appreciative of the fact
these are unused, thanks to -Werror during validate.

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

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

Cabal compiles a program to check for the existence of foreign
libraries, so it needs to know our custom options, if any.

One problem was that we weren't including $1_$2_DIST_LD_OPTS when
linking a program, which looks to be accidental: it was being defined
but not used anywhere.  This meant that setting $1_$2_EXTRA_LD_OPTS,
for example, had no effect.

This commit straightens out the handling of LD_OPTS to be consistent
with the way we handle CC_OPTS and HC_OPTS.

The user explicitly requested this script on the command-line, so it's
unnecessary to require that the script is also owned by the user.
Also, it is currently impossible to make a GHCi wrapper that invokes a
custom script without first making a copy of the script to circumvent
the permissions check, which seems wrong.

This adds -fmax-inline-memcpy-insns and -fmax-inline-memset-insns.
These flags control when we inline calls to memcpy/memset with
statically known arguments. The flag naming style is taken from GCC
and the same limit is used by both GCC and LLVM.