GitLab

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.

After c846618a we don't have accurate CafInfos for Ids in the current
module and we're free to introduce new CAFFY or non-CAFFY bindings or
change CafInfos of existing binders; so no we no longer need to
maintain CafInfos in Core or STG passes.

Previously we'd override the existing {run,hc} opts in
extra_{run,hc}_opts, which caused flakiness in T1969, see #17712.

extra_{run,hc}_opts now extends {run,hc} opts, instead of overriding.

Also we shrank the allocation area for T1969 in order to increase
residency sampling frequency.

Fixes #17712

In #17703 (a follow-up of !2192), we established that contrary to my
belief, type constraints arising from existentials in code like

```hs
data Ex where Ex :: a -> Ex
f _ | let x = Ex @Int 15 = case x of Ex -> ...
```

are in fact useful.

This commit makes a number of refactorings and improvements to comments,
but fundamentally changes `addCoreCt.core_expr` to record the type
constraint `a ~ Int` in addition to `x ~ Ex @a y` and `y ~ 15`.

Fixes #17703.

The driver code is some of the nastiest in GHC, and I am worried about
being able to untangle all the tech debt. In `HscMain` we have a number
of helpers which are either not-used or little used. I delete them so we
can reduce cognative load, distilling the essential complexity away from
the cruft.

For unregisterised builds StgRun/StgReturn are implemented via a mini
interpreter in StgCRun.c and therefore would collide with the
implementations in StgCRunAsm.S.

I found the old control flow a bit hard to follow; I rewrote it to first
decide whether to desugar, and then use that choice when computing
whether to simplify / what sort of interface file to write.

I hope eventually we will always write post-tc interface files, which
will make the logic of this function even simpler, and continue the
thrust of this refactor.

Other variant was removed in ac1a3793
but docs were no changed.