GitLab

This commit implements a few Windows-specific fixes which get us from a CI
job that can't even get as far as starting the testsuite driver, to a state
where we can run the entire testssuite (but have test failures to fix).

- Don't forget about a potential extension for the haddock program, when
  preparing the bindist.
- Build the timeout program, used by the testsuite driver on Windows in place
  of the Python script used elsewhere, using the boot compiler. We could
  alternatively build it with the compiler that we're going to test but this
  would be a lot more tedious to write.
- Implement a wrapper-script less installation procedure for Windows, in
  `hadrian/bindist/Makefile.
- Make dependencies a bit more accurate in the aforementioned Makefile.
- Update Windows/Hadrian CI job accordingly.

This patch fixes #17486.

This link appears to have been forgotten in
0dad81ca .

This appears to be a cut-and-paste error.

Allowing the test metric output to be captured to a file, a la
the METRIC_FILE environment variable of the make build system.

When requesting more than BLOCKS_PER_MBLOCK blocks allocGroup can return a
different number of blocks than requested. Here we use the number of
requested blocks, however arenaFree will subtract the actual number of
blocks we got from arena_blocks (possibly) resulting in a negative value
and triggering ASSERT(arena_blocks >= 0).

The comment in GHC.Base claimed that ($) couldn't be used in that module
as it was wired-in. However, this is no longer true; ($) is merely known
key and is defined in Haskell (with a RuntimeRep-polymorphic type) in
GHC.Base.

The one piece of magic that ($) retains is that it a special typing
rule to allow type inference with higher-rank types
(e.g. `runST $ blah`; see Note [Typing rule for ($)] in TcExpr).

The bug seems to be fixed in the meantime, make sure it stays fixed.

Closes #12760

This is in preparation of backwards-incompatible changes in happy.
See https://github.com/simonmar/happy/issues/166

While single-line comments are supported by C99, dtrace on SmartOS
apparently doesn't support them yet.

This fixes #17763

cc/ @pepeiborra

This alternative is redundant and triggers no warning when building with 8.6.5

Closes #17094.

This is the full testcase for T15316.

This will hopefully fix #17631.

This adopts a patch from NetBSD's packaging fixing the `GhcThreaded`
option of the make build system. In addition we introduce a `ghcThreaded`
option in hadrian's `Flavour` type.

Also fix Hadrian's treatment of the `Use Threaded` entry in `settings`.
Previously it would incorrectly claim `Use Threaded = True` if we were
building the `threaded` runtime way. However, this is inconsistent with
the `make` build system, which defines it to be whether the `ghc`
executable is linked against the threaded runtime.

Fixes #17692.

unpackCString# is a recursive function which for each iteration
returns a Cons cell containing the current Char, and a thunk for
unpacking the rest of the string.

In this patch we change from storing addr + offset inside this thunk
to storing only the addr, simply incrementing the address on each
iteration.

This saves one word of allocation per unpacked character.
For a program like "main = print "<largishString>" this amounts
to 2-3% fewer % in bytes allocated.

I also removed the now redundant local unpack definitions.
This removes one call per unpack operation.

Fixes #17612 by adding a `cabal.configure.opts` key for
`hadrian.settings`.

This implements the warning proposed in option (B) of the
Data.List.singleton CLC [discussion][].
This warning, which is included in `-Wcompat` is intended to help users
identify imports of modules that will change incompatibly in future GHC
releases. This currently only includes `Data.List` due to the expected
specialisation and addition of `Data.List.singleton`.

Fixes #17244.

[discussion]: https://groups.google.com/d/msg/haskell-core-libraries/q3zHLmzBa5E/PmlAs_kYAQAJ

If hs_try_putmvar was called through an unsafe import, it would lose track of the running cap causing a deadlock

There are two main payloads of this patch:

1. This introduces IsPass, which allows e.g. printing
   code to ask what pass it is running in (Renamed vs
   Typechecked) and thus print extension fields. See
   Note [IsPass] in Hs.Extension

2. This moves the HsWrap constructor into an extension
   field, where it rightly belongs. This is done for
   HsExpr and HsCmd, but not for HsPat, which is left
   as an exercise for the reader.

There is also some refactoring around SyntaxExprs, but this
is really just incidental.

This patch subsumes !1721 (sorry @chreekat).

Along the way, there is a bit of refactoring in GHC.Hs.Extension,
including the removal of NameOrRdrName in favor of NoGhcTc.
This meant that we had no real need for GHC.Hs.PlaceHolder, so
I got rid of it.

Updates haddock submodule.

-------------------------
Metric Decrease:
    haddock.compiler
-------------------------

```
main = do
  print $ g [1..100] a
  where g xs x   = map (`mod` x) xs
        a :: Int = 324
```

The above program previously attributed the cost of computing 324 to a cost
centre named `(...)`, with this change the cost is attributed to `a` instead.

This change only affects simple pattern bindings (decorated variables: type
signatures, parens, ~ annotations and ! annotations).

This entailed

* Adding a tcf_view field to TyCoFolder

* Moving exactTyCoVarsOtType to TcType.  It properly belongs
  there, since only the typechecker calls this function. But
  it also means that we can "see" and inline tcView.

Metric Decrease:
  T14683

This patch delivers on (much of) #17509.

* Introduces the shallow vs deep free variable distinction

* Introduce TyCoRep.foldType,
    foldType :: Monoid a => TyCoFolder env a
                         -> env -> Type -> a
  and use it in the free variable finders.

* Substitution in TyCoSubst
   * ASSERTs are on for checkValidSubst
   * checkValidSubst uses shallowTyCoVarsOfTypes etc

Quite a few things still to do

* We could use foldType in lots of other places

* We could use mapType for substitution.  (Check that we get
  good code!)

* Some (but not yet all) clients of substitution can now
  save time by using shallowTyCoVarsOfTypes

* All calls to tyCoVarsOfTypes should be inspected; most of
  them should be shallow.  Maybe.

* Currently shallowTyCoVarsOfTypes still returns
  unification variables, but not CoVarHoles.
  Reason: we need to return unification variables
  in some of the calls in TcSimplify, eg when promoting.

* We should do the same thing for tyCoFVsOfTypes, which is
  currently unchanged.

* tyCoFVsOfTypes returns CoVarHoles, because of the
  use in TcSimplify.mkResidualConstraints.  See
  Note [Emitting the residual implication in simplifyInfer]

* #17509 talks about "relevant" variables too.

Due to T7702 and the process issues described in #17777.