It seems like currently the runner doesn't delete the working tree after
finishing a job. At least we can delete the binary artifacts for now.

I have seen several instances of inexplicable "Access denied" errors on Windows.
Using per-build temporary directories avoids any chance of interference between
builds and eliminates the possibility of temporary files leaking beyond the life
of the build.

This reverts commit 442be690.

 * Mark arith011 as broken with integer-simple

   As noted in #16091, arith011 fails when run against integer-simple with a
   "divide by zero" exception. This suggests that integer-gmp and integer-simple
   are handling division by zero differently.

 * This also fixes broken_without_gmp; the lack of types made the previous
   failure silent, sadly. Improves situation of #16043.

 * Mark several tests implicitly depending upon integer-gmp as broken
   with integer-simple. These expect to see Core coming from integer-gmp,
   which breaks with integer-simple.

 * Increase runtime timeout multiplier of T11627a with integer-simple

   I previously saw that T11627a timed out in all profiling ways when run against
   integer-simple. I suspect this is due to integer-simple's rather verbose heap
   representation. Let's see whether increasing the runtime timeout helps.

   Fixes test for #11627.

This is all in service of fixing #16043.

The retainer profiler no longer uses the C stack for its mark stack (#14758).
Consequently even the small C stack provided on Darwin should be sufficient to
run this test. See #11627

The representation of Integer depends upon the choice of integer backend whereas
Char should be consistent.

Currently we duplicate top-level binder ids for no reason:

    $fEqHsExpr_$c/=
    $fEqHsExpr_$c/=
      = \ @ id_a27U $dEq_a27V eta_B2 eta1_B1 ->
          case $fEqHsExpr_$c== $dEq_a27V eta_B2 eta1_B1 of {
            False -> True;
            True -> False
          }

with this patch we drop the first line when type signatures are not
printed (-dsuppress-type-signatures, which is implied by -dsuppress-all)

Reviewers: simonpj, bgamari

Reviewed By: simonpj

Subscribers: rwbarton, carter

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

This is due to the failures documented in #16087. The condition here could be
improved as it matches on `BUILD_FLAVOUR` instead of looking at the compiler
flags. However, it's better than nothing and I hope we will be able to fix these
issues before long.

They aren't finishing correctly anyways.

This reverts commit e59439af.

This is causing unexpected failures in some test ways. Further proof
that no change is too trivial for CI.

The lack of types made the previous failure silent, sadly. Improves
situation of #16043.

As documented in #15382, this is known to fail in prof_hc_hb on i386.
Concerningly, I have also seen this test non-deterministically fail in
prof_hc_hb on amd64. We should really investigate this.

As noted in #15662, these used to be broken on Darwin due to a Clang toolchain
bug. However, this bug appears to be fixed in the Clang shipped with macOS
Mojave. Unfortunately, we don't really have any way to only mark it as broken on
certain operation system releases so I am just removing the expect_broken
entirely.

This is currently spuriously failing. Moreover, we have the Mac Mini builder
running again so this is much less necessary now.

Previously the toolchain directory was wiped away by git clean.

Previously the linters were tagged with x86_64-linux, meaning that linting jobs
would often get stuck behind builds in the queue. Given that linting jobs are
fairly low-cost they hold up later build stages it is important that we reduce
this latency.

Our CircleCI builds will fail anyways without large instances.

Test Plan: Observe CircleCI

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: rwbarton, carter

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

Due to #16073.

It turns out that the submodules hack is useful to ensure that
CI works in forks.

This reverts commit 90ceafa8.

Trac #16038 exposed the fact that TcRnDriver.checkHiBootIface
was creating a binding, in the module being compiled, for
   $fxBlah = $fBlah

 but $fxBlah was a /GlobalId/. But all bindings should be for
 /LocalIds/ else dependency analysis goes down the tubes.

* I added a CoreLint check that an occurrence of a GlobalId
  is not bound by an binding of a LocalId.  (There is already
  a binding-site check that no binding binds a GlobalId.)

* I refactored (and actually signficantly simplified) the
  tricky code for dfuns in checkHiBootIface to ensure that
  we get LocalIds for those boot-dfuns.

Alas, I then got "duplicate instance" messages when compiling
HsExpr. It turns out that this is a long-standing, but extremely
delicate, bug: even before this patch, if you compile HsExpr
with -ddump-tc-trace, you get "duplicate instance". Without
-ddump-tc-trace, it's OK.  What a mess!

The reason for the duplicate-instance is now explained in
Note [Loading your own hi-boot file] in LoadIface.  I fixed
it by a Gross Hack in LoadIface.loadInterface. This is at
least no worse than before.

But there should be a better way. I have opened #16081 for this.

In tcExtendRecEnv, there is no need to us setGlobalTypeEnv
(which side-effects the tcg_type_env_var).  tcExtendRecEnv
is used only when kind-checking a group of type/class decls
and no knot-tying via tcg_type_env_var is needed.

There is no change in functionality.

candidateQTyVars was failing to return fully-zonked
tyvars, and that made things fall over chaotically
when we try to sort them into a well-scoped telescope.
Result: Trac #15795

So I made candidateQTvs guarantee to have fully-zonked
tyvars (i.e. with zonked kinds).  That's a bit annoying
but not really difficult.