GitLab

With TypeInType Richard combined ForAllTy and FunTy, but that was often
awkward, and yielded little benefit becuase in practice the two were
always treated separately.  This patch re-introduces FunTy.  Specfically

* New type
    data TyVarBinder = TvBndr TyVar VisibilityFlag
  This /always/ has a TyVar it.  In many places that's just what
  what we want, so there are /lots/ of TyBinder -> TyVarBinder changes

* TyBinder still exists:
    data TyBinder = Named TyVarBinder | Anon Type

* data Type = ForAllTy TyVarBinder Type
            | FunTy Type Type
            |  ....

There are a LOT of knock-on changes, but they are all routine.

The Haddock submodule needs to be updated too

..in typecheck/should_run/T7861

Was concealed behind the haddock perf noise

This reverts commit 0497ee50.

Reason: See Trac #12191.  I'm reverting pending Bartosz's
investigation of what went wrong.

`readProcessEnvWithExitCode` was added in
4d4d0770, to start an external process
after making some modifications to the environment.

Since then, the `process` library has exposed
`readCreateProcessWithExitCode`, which allows for the refactoring we do
here.

Also change "en" to "C", as suggested in ticket:8825#comment:11.

Reviewed by: trofi

Differential Revision: https://phabricator.haskell.org/D2332

GHC Trac Issues: #8825

This makes it obvious that it's nondeterministic and hopefully
will prevent someone from using it accidentally.

GHC Trac: #4012

We can't tell whether the CAF is actually garbage or not.

This test didn't have a `.T` file, so the testsuite driver never ran it.
Luckily the features it tested for didn't break in the past 8 years.

This is a follow up to a74a3846
, which made the same change but for the toplevel configure.ac.

Reviewed by: erikd

Differential Revision: https://phabricator.haskell.org/D2330

GHC Trac Issues: #11659

Update submodule to accompany this commit:

    commit 15b9bf4b
    Author: Simon Peyton Jones <simonpj@microsoft.com>
    Date:   Sat Jun 11 23:49:27 2016 +0100

        Improve typechecking of let-bindings

Sorry it's late!

The `Ord Module` instance currently uses `Unique`s for comparison.
We don't want to use the `Unique` order because it can introduce nondeterminism.
This switches `Ord ModuleName` and `Ord UnitId` to use lexicographic ordering
making `Ord Module` deterministic transitively.

I've run `nofib` and it doesn't make a measurable difference.

See also Note [ModuleEnv determinism and performance].

Test Plan:
./validate
run nofib: P112

Reviewers: simonpj, simonmar, austin, bgamari

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D2030

GHC Trac Issues: #4012

Summary:
The Ord instance for ModuleName is currently implemented in
terms of Uniques causing potential determinism problems.
I plan to change it to use the actual FastStrings and in
preparation for that I'm switching to UniqFM where it's
possible (you need *one* Unique per key, and you can't get
the keys back), so that the performance doesn't suffer.

Test Plan: ./validate

Reviewers: simonmar, austin, ezyang, bgamari

Reviewed By: bgamari

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D2320

GHC Trac Issues: #4012

With the current implementation, it's nondeterministic
because Ord Module is nondeterministic.

Summary:
Code already existed in the RTS to add thin library support for non-Windows
operating systems. This adds it to Windows as well.

ar thin libraries have the exact same format as normal archives except they
have a different magic string and they don't copy the object files into the
archive.

Instead each header entry points to the location of the object file on disk.
This is useful when a library is only created to satisfy a compile time dependency
instead of to be distributed. This saves the time required for copying.

Test Plan: ./validate and new test T11788

Reviewers: austin, bgamari, simonmar, erikd

Reviewed By: bgamari, simonmar

Subscribers: thomie, #ghc_windows_task_force

Differential Revision: https://phabricator.haskell.org/D2323

GHC Trac Issues: #11788

This one omits the extension, thereby making GHC 8.0 produce
"GHC internal error".

This adds
  *.patch
  *.stackdump    (Windows)
  foo*           (simonpj uses foo* for junk files)

During the kind-checking "knot" we have to be careful not
to print too eagerly.

isPredTy can be called on ill-kinded types, especially (of course) if
there is a kind error.  We don't wnat it to crash, but it was, in
piResultTy.

This patch introduces piResultTy_maybe, and uses it in isPredTy.

Ugh.  I dislike this code.  It's mainly used to know when we should
print types with '=>', and we should probably have a better way to
signal that.

We'd forgotten the variables free in the kind.

Ditto extendCvSubstWithClone

By spotting Refl coercions we can avoid building an awful
lot of CastTys.  Simple and effective.

For type synonyms, we need to check that if the RHS has
kind Constraint, then we have -XConstraintKinds.  For
some reason this was done in checkValidType, but it makes
more sense to do it in checkValidTyCon.

I can't remember quite why I made this change; maybe it fixes
a Trac ticket, but if so I forget which.  But it's a modest
improvement anyway.

...thereby being able to replace substThetaUnchecked
with substTheta

I managed to eliminate the strange zonkQuantifiedTyVarOrType,
which is no longer used.

This major commit was initially triggered by #11339, but it spiraled
into a major review of the way in which type signatures for bindings
are handled, especially partial type signatures.  On the way I fixed a
number of other bugs, namely
   #12069
   #12033
   #11700
   #11339
   #11670

The main change is that I completely reorganised the way in which type
signatures in bindings are handled. The new story is in TcSigs
Note [Overview of type signatures].  Some specific:

* Changes in the data types for signatures in TcRnTypes:
  TcIdSigInfo and new TcIdSigInst

* New module TcSigs deals with typechecking type signatures
  and pragmas. It contains code mostly moved from TcBinds,
  which is already too big

* HsTypes: I swapped the nesting of HsWildCardBndrs
  and HsImplicitBndsrs, so that the wildcards are on the
  oustide not the insidde in a LHsSigWcType.  This is just
  a matter of convenient, nothing deep.

There are a host of other changes as knock-on effects, and
it all took FAR longer than I anticipated :-).  But it is
a significant improvement, I think.

Lots of error messages changed slightly, some just variants but
some modest improvements.

New tests

* typecheck/should_compile
    * SigTyVars: a scoped-tyvar test
    * ExPat, ExPatFail: existential pattern bindings
    * T12069
    * T11700
    * T11339

* partial-sigs/should_compile
    * T12033
    * T11339a
    * T11670

One thing to check:

* Small change to output from ghc-api/landmines.
  Need to check with Alan Zimmerman

This patch simply deletes code, the SigTv check in
occurCheckExpand.  As the new comment says

In the past we also rejected a SigTv matched with a non-tyvar
But it is wrong to reject that for Givens;
and SigTv is in any case handled separately by
   - TcUnify.checkTauTvUpdate (on-the-fly unifier)
   - TcInteract.canSolveByUnification (main constraint solver)

The NUMA code was enabled whenever numa.h and numaif.h are detected.
Unfortunately, the hosts' header files were being detected even then
cross compiling in the absence of a target libnuma.

Fix that by relying on the the presence of libnuma instead of the
presence of the header files. The test for libnuma does `AC_TRY_LINK`
which will fail if the test program (compiled for the target) can't
be linked against libnuma.

Test Plan:
Build on x86_64/linux and make sure NUMA works and cross compile to
armhf/linux.

Reviewers: austin, bgamari, hvr, simonmar

Reviewed By: simonmar

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D2329

Summary:
See #12031 for analysis, but essentially what happens is:

To sum up the issue, the reason this seems to go wrong is because
of how we initialize the `.bss` section for Windows in the runtime linker.

The first issue is where we calculate the zero space for the section:

```
zspace = stgCallocBytes(1, bss_sz, "ocGetNames_PEi386(anonymous bss)");
sectab_i->PointerToRawData = ((UChar*)zspace) - ((UChar*)(oc->image));
```

Where
```
UInt32 PointerToRawData;
```

This means we're stuffing a `64-bit` value into a `32-bit` one. Also `zspace`
can be larger than `oc->image`. In which case it'll overflow and
then get truncated in the cast.

The address of a value in the `.bss` section is then calculated as:

```
addr = ((UChar*)(oc->image))
     + (sectabent->PointerToRawData
     + symtab_i->Value);
```

If it does truncate then this calculation won't be correct (which is what is happening).

We then later use the value of `addr` as the `S` (Symbol) value for the relocations

```
S = (size_t) lookupSymbol_( (char*)symbol );
```

Now the majority of the relocations are `R_X86_64_PC32` etc.
e.g. They are guaranteed to fit in a `32-bit` value.

The `R_X86_64_64` introduced for these pseudo-relocations so they can use
the full `48-bit` addressing space isn't as lucky.
As for why it sometimes work has to do on whether the value is truncated or not.

`PointerToRawData` can't be changed because it's size is fixed by the PE specification.

Instead just like with the other platforms, we now use `section` on Windows as well.
This gives us a `start` parameter of type `void*` which solves the issue.

This refactors the code to use `section.start` and to fix the issues.

Test Plan: ./validate and new test added T12031

Reviewers: RyanGlScott, erikd, bgamari, austin, simonmar

Reviewed By: simonmar

Subscribers: thomie, #ghc_windows_task_force

Differential Revision: https://phabricator.haskell.org/D2316

GHC Trac Issues: #12031, #11317

See #11204, this test sometimes fails and sometimes passes on OSX
which causes intermittent validate failures if it is run.

The recently added NUMA related functions were mistakenly defined
within a `#ifdef USE_LARGE_ADDRESS_SPACE` ... `#endif` block. Moving
them outside this block fixes the build on PowerPC and Arm Linux.

Test Plan: Build on PowerPC or Arm Linux

Reviewers: hvr, austin, bgamari, simonmar

Reviewed By: simonmar

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D2326

* Remove unused/old flags from the structs
* Update old comments
* Add missing flags to GHC.RTS
* Simplify GHC.RTS, remove C code and use hsc2hs instead
* Make ParFlags unconditional, and add support to GHC.RTS

Summary:
The aim here is to reduce the number of remote memory accesses on
systems with a NUMA memory architecture, typically multi-socket servers.

Linux provides a NUMA API for doing two things:
* Allocating memory local to a particular node
* Binding a thread to a particular node

When given the +RTS --numa flag, the runtime will
* Determine the number of NUMA nodes (N) by querying the OS
* Assign capabilities to nodes, so cap C is on node C%N
* Bind worker threads on a capability to the correct node
* Keep a separate free lists in the block layer for each node
* Allocate the nursery for a capability from node-local memory
* Allocate blocks in the GC from node-local memory

For example, using nofib/parallel/queens on a 24-core 2-socket machine:

```
$ ./Main 15 +RTS -N24 -s -A64m
  Total   time  173.960s  (  7.467s elapsed)

$ ./Main 15 +RTS -N24 -s -A64m --numa
  Total   time  150.836s  (  6.423s elapsed)
```

The biggest win here is expected to be allocating from node-local
memory, so that means programs using a large -A value (as here).

According to perf, on this program the number of remote memory accesses
were reduced by more than 50% by using `--numa`.

Test Plan:
* validate
* There's a new flag --debug-numa=<n> that pretends to do NUMA without
  actually making the OS calls, which is useful for testing the code
  on non-NUMA systems.
* TODO: I need to add some unit tests

Reviewers: erikd, austin, rwbarton, ezyang, bgamari, hvr, niteria

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D2199

Use tauifyExpType rather than something hand-rolled

...about unarisation and unboxed tuples

Remove -fwarn- and -fno-warn- from flagsForCompletion

Testcase: Fix linter error on T12099

For Issue #12099

Reviewers: austin, thomie, bgamari

Reviewed By: austin, thomie, bgamari

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D2281

GHC Trac Issues: #12099