GitLab

GHC native code generator generates .incbin and .file directives. We
need to escape those strings correctly on Windows (see #16389).

Previously, our test did something like this:

1. Typecheck p
2. Typecheck q (which made use of an instantiated p)
3. Build instantiated p
4. Build instantiated q

Cabal previously permitted this, under the reasoning that during
typechecking there's no harm in using the instantiated p even if we
haven't build it yet; we'll just instantiate it on the fly with p.

However, this is not true!  If q makes use of a Template Haskell
splice from p, we absolutely must have built the instantiated p
before we typecheck q, since this typechecking will need to
run some splices.  Cabal now complains that you haven't done
it correctly, which we indeed have not!

Reordering so that we do this:

1. Typecheck p
3. Build instantiated p
2. Typecheck q (which made use of an instantiated p)
4. Build instantiated q

Fixes the problem.  If Cabal had managed the ordering itself, it would
have gotten it right.
Signed-off-by: Edward Z. Yang <ezyang@fb.com>

This will be needed by the mark phase of the non-moving collector
so let's factor it out.

This issue was reproduced with, and the fix confirmed with,
the `hatrace` tool for syscall-based fault injection:

    https://github.com/nh2/hatrace

The concrete test case for GHC is at

    https://github.com/nh2/hatrace/blob/e23d35a2d2c79e8bf49e9e2266b3ff7094267f29/test/HatraceSpec.hs#L185

A previous, nondeterministic reproducer for the issue was provided by
Alexey Kuleshevich in

    https://github.com/lehins/exec-kill-loopSigned-off-by: Niklas Hambüchen <niklas@fpcomplete.com>
Reviewed-by: Alexey Kuleshevich <alexey@fpcomplete.com>

Before this patch GHC was trying to be too clever
(Trac #16344); it succeeded in kind-checking this
polymorphic-recursive declaration

    data T ka (a::ka) b
      = MkT (T Type           Int   Bool)
            (T (Type -> Type) Maybe Bool)

As Note [No polymorphic recursion] discusses, the "solution" was
horribly fragile.  So this patch deletes the key lines in
TcHsType, and a wodge of supporting stuff in the renamer.

There were two regressions, both the same: a closed type family
decl like this (T12785b) does not have a CUSK:
  type family Payload (n :: Peano) (s :: HTree n x) where
    Payload Z (Point a) = a
    Payload (S n) (a `Branch` stru) = a

To kind-check the equations we need a dependent kind for
Payload, and we don't get that any more.  Solution: make it
a CUSK by giving the result kind -- probably a good thing anyway.

The other case (T12442) was very similar: a close type family
declaration without a CUSK.

GHC represents String literals as ByteString internally for efficiency
reasons. However, until now it wasn't possible to efficiently create
large string literals with TH (e.g. to embed a file in a binary, cf #14741):
TH code had to unpack the bytes into a [Word8] that GHC then had to re-pack
into a ByteString.

This patch adds the possibility to efficiently create a "string" literal
from raw bytes. We get the following compile times for different sizes
of TH created literals:

|| Size || Before || After  || Gain ||
|| 30K  || 2.307s || 2.299  || 0%   ||
|| 3M   || 3.073s || 2.400s || 21%  ||
|| 30M  || 8.517s || 3.390s || 60%  ||

Ticket #14741 can be fixed if the original code uses this new TH feature.

Trac #16376 showed the danger of failing to report an error
that exists only in the unsolved constraints, if an exception
is raised (via failM).

Well, the commit 5c1f268e (Fail fast in solveLocalEqualities)
did just that -- i.e. it found errors in the constraints, and
called failM to avoid a misleading cascade.

So we need to be sure to call captureTopConstraints to report
those insolubles.  This was wrong in TcRnDriver.tcRnExpr and
in TcRnDriver.tcRnType.

As a result the error messages from test T13466 improved slightly,
a happy outcome.

Also, replace some tabs with spaces to avoid a "mixed indent" warning that vim
gives me.

This partly resolves #16325 (https://ghc.haskell.org/trac/ghc/ticket/16325).

As previously discussed in https://github.com/snowleopard/hadrian/issues/667,
we do not need the symlink traversal code in build scripts. However, it
appears we forgot to delete this code from our Stack-based build scripts,
which led to placing all build artefacts in an unexpected location when
using Hadrian in combination with symlink trees. This commit fixes this.

- introduce a -k/--keep-test-files flag to prevent cleanup
- add -dstg-lint to the options that are always passed to tests
- infer library ways from the compiler to be tested instead of getting them
  from the flavour (like make)
- likewise for figuring out whether the compiler to be tested is "debugged"
- specify config.exeext
- correctly specify config.in_tree_compiler, instead of always passing True
- fix formatting of how we pass a few test options
- add (potential) extensions to check-* program names
- build check-* programs with the compiler to be tested
- set TEST_HC_OPTS_INTERACTIVE and PYTHON env vars when running tests

Trac #10069 revealed that small NOINLINE functions didn't get split
into worker and wrapper. This was due to `certainlyWillInline`
saying that any unfoldings with a guidance of `UnfWhen` inline
unconditionally. That isn't the case for NOINLINE functions, so we
catch this case earlier now.

Nofib results:

--------------------------------------------------------------------------------
        Program         Allocs    Instrs
--------------------------------------------------------------------------------
 fannkuch-redux          -0.3%      0.0%
             gg          +0.0%     +0.1%
       maillist          -0.2%     -0.2%
        minimax           0.0%     -0.8%
--------------------------------------------------------------------------------
            Min          -0.3%     -0.8%
            Max          +0.0%     +0.1%
 Geometric Mean          -0.0%     -0.0%

Fixes #10069.

-------------------------
Metric Increase:
    T9233
-------------------------

The type-variables-escaping-their-scope-via-kinds check in
`TcValidity` was failing to properly expand type synonyms, which led
to #16391. This is easily fixed by using `occCheckExpand` before
performing the validity check.

Along the way, I refactored this check out into its own function,
and sprinkled references to Notes to better explain all of the moving
parts. Many thanks to @simonpj for the suggestions.

Bumps the haddock submodule.

We revert CAFs when loading/adding modules in ghci (presumably to refresh
execution states and to allow for object code to be unloaded from the runtime).
However, with `-fexternal-interpreter` enabled, we are only doing it in the
ghci process instead of the external interpreter process where the cafs are
allocated and computed. This makes sure that revertCAFs is done in the
appropriate process no matter if that flag is present or not.

Also account for testsuite metric drift.

Metric Increase:
    haddock.Cabal
    haddock.base
    T14683

Now since we have been a bit more stringent in testsuite cleanliness we
have been marking a lot of tests as fragile using the `skip` modifier.
However, this unfortunately means that we lose the association with the
ticket number documenting the fragility.

Here we introduce `fragile` and `fragile_for` to retain this
information.

This was the suggested change in !176 but missed the batch merge (!263).

`instance forall c. c` claimed that `c` was out of scope because the
renamer was invoking `lookupGlobalOcc` on `c` (in
`RnNames.getLocalNonValBinders`) without binding `c` first. To avoid
this, this patch changes GHC to invoke `lookupGlobalOcc_maybe` on `c`
instead, and if that returns `Nothing`, then bail out, resulting
in a better error message.

In the concurrent nonmoving collector we will need the ability to call
`traverseWeakPtrList` concurrently with minor generation collections.
This global state stands in the way of this. However, refactoring it
away is straightforward since this list only persists the length of a
single GC.

Fixes #16187.

This patch fixes various path concatenation issues to allow functioning
builds with hadrian when the build root location is specified with an
absolute path.

Remarks:

- The path concatenation operator (-/-) now handles absolute second operands
  appropriately. Its behavior should match that of POSIX (</>) in this
  regard.

- The `getDirectoryFiles*` family of functions only searches for matches
  under the directory tree rooted by its first argument; all of the
  results are also relative to this root. If the first argument is the
  empty string, the current working directory is used.

  This patch passes the appropriate directory (almost always either `top`
  or `root`), and subsequently attaches that directory prefix so that
  the paths refer to the appropriate files.

- Windows `tar` does not like colons (':') in paths to archive files, it
  tries to resolve them as remote paths. The `--force-local` option
  remedies this, and is applied on windows builds.

The test case in #15918 no longer triggers an `ASSERT` failure on
GHC HEAD, likely due to commit
68278382 (`Make a smart mkAppTyM`).
This patch adds a regression test for #15918 to finally put it to
rest.

These include printLargeAndPinnedObjects, printWeakLists, and
printStaticObjects. These are generally useful things to have.

The splitter is an evil Perl script that processes assembler code.
Its job can be done better by the linker's --gc-sections flag. GHC
passes this flag to the linker whenever -split-sections is passed on
the command line.

This is based on @DemiMarie's D2768.

Fixes Trac #11315
Fixes Trac #9832
Fixes Trac #8964
Fixes Trac #8685
Fixes Trac #8629

This addresses Trac #16208 by marking newtype wrapper
unfoldings as compulsory.

Furthermore, we can remove the special case for newtypes
in exprIsConApp_maybe (introduced in 7833cf40).

Test Runner: don't show missing baseline warning for performance tests with expected changes on the current commit.

Trac #16359

This patch fixes two rather gnarly test cases:
  * Trac #16342 (mutual recursion)
    See Note [Tricky scoping in generaliseTcTyCon]

  * Trac #16221 (shadowing)
    See Note [Unification variables need fresh Names]

The main changes are:

* Substantial reworking of TcTyClsDecls.generaliseTcTyCon
  This is the big change, and involves the rather tricky
  function TcHsSyn.zonkRecTyVarBndrs.

  See Note [Inferring kinds for type declarations] and
  Note [Tricky scoping in generaliseTcTyCon] for the details.

* bindExplicitTKBndrs_Tv and bindImplicitTKBndrs_Tv both now
  allocate /freshly-named/ unification variables. Indeed, more
  generally, unification variables are always fresh; see
  Note [Unification variables need fresh Names] in TcMType

* Clarify the role of tcTyConScopedTyVars.
  See Note [Scoped tyvars in a TcTyCon] in TyCon

As usual, this dragged in some more refactoring:

* Renamed TcMType.zonkTyCoVarBndr to zonkAndSkolemise

* I renamed checkValidTelescope to checkTyConTelescope;
  it's only used on TyCons, and indeed takes a TyCon as argument.

* I folded the slightly-mysterious reportFloatingKvs into
  checkTyConTelescope. (Previously all its calls immediately
  followed a call to checkTyConTelescope.)  It makes much more
  sense there.

* I inlined some called-once functions to simplify
  checkValidTyFamEqn. It's less spaghetti-like now.

* This patch also fixes Trac #16251.  I'm not quite sure why #16251
  went wrong in the first place, nor how this patch fixes it, but
  hey, it's good, and life is short.

This reverts commit 0e2d300a.

This reverts commit e8a08f40.

RyanGlScott observed in https://github.com/haskell/haddock/issues/1030
that running Haddock tests in GHC's testsuite left some `.hi` files
around in `utils/haddock`. This should fix that problem.