GitLab

The primop stgFloatToWord32 was sign-extending the 32-bit word, resulting
in weird negative Word32s.  Zero-extend them instead.

Closes #16617.

`checkTyClHdr`'s case for `HsTyVar` was grabbing the wrong `SrcSpan`,
which lead to error messages pointing to the wrong location. Easily
fixed.

This addresses some glaring omissions from
`libraries/base/changelog.md` and
`docs/users_guide/8.8.1-notes.rst`, fixing #16603 in the process.

A follow-up to !696's, which attempted to clean up the error messages
for ill formed associated type family default equations. The previous
attempt, !696, forgot to account for the possibility of duplicate
kind variable arguments, as in the following example:

```hs
class C (a :: j) where
  type T (a :: j) (b :: k)
  type T (a :: k) (b :: k) = k
```

This patch addresses this shortcoming by adding an additional check
for this. Fixes #13971 (hopefully for good this time).

As of commit d37d91e9, the GHC build
now autogenerates a `includes/dist/build/settings` file. To avoid
dirtying the current `git` status, this adds `includes/dist` to
`.gitignore`.

[ci skip]

This required making the 'ghc-config-mk' variable overridable in
testsuite/mk/boilerplate.mk, and then making use of this in hadrian
to point to '<build root>/test/ghcconfig' instead, which is where we
always put the test config.

Previously, we would build ghc-config and run it against the
GHC to be tested, a second time, while we're running the tests, because some
include testsuite/mk/boilerplate.mk. This was causing unexpected output
failures.

Remove `$(TOP)/ANNOUNCE` because maintaining this file is expensive
for each release.

Currently, release announcements of ghc are made on ghc blogs and wikis.

[skip ci]

Get "Tables next to code" from the settings file instead.

[skip ci]

Probably due to a copy/paste gone wrong.

- fixes double mention of `traceBinaryEvent#` (the second one should be `traceEvent#`, I think)
- fixes note about `traceEvent#` taking a `String` - the docs say it takes a zero-terminated ByteString.

`stat_exit` always allocates a `RTSSummaryStats` but only sometimes
frees it, which casues leaks. With this patch we unconditionally free
the structure, fixing the leak.

Fixes #16584

Issues #12102 and #15872 revealed something strange about the way GHC
handles equality constraints in kinds: it treats them as _visible_
arguments! This causes a litany of strange effects, from strange
error messages
(#12102 (comment 169035))
to bizarre `Eq#`-related things leaking through to GHCi output, even
without any special flags enabled.

This patch is an attempt to contain some of this strangeness.
In particular:

* In `TcHsType.etaExpandAlgTyCon`, we propagate through the
  `AnonArgFlag`s of any `Anon` binders. Previously, we were always
  hard-coding them to `VisArg`, which meant that invisible binders
  (like those whose kinds were equality constraint) would mistakenly
  get flagged as visible.
* In `ToIface.toIfaceAppArgsX`, we previously assumed that the
  argument to a `FunTy` always corresponding to a `Required`
  argument. We now dispatch on the `FunTy`'s `AnonArgFlag` and map
  `VisArg` to `Required` and `InvisArg` to `Inferred`. As a
  consequence, the iface pretty-printer correctly recognizes that
  equality coercions are inferred arguments, and as a result,
  only displays them in `-fprint-explicit-kinds` is enabled.
* Speaking of iface pretty-printing, `Anon InvisArg` binders were
  previously being pretty-printed like `T (a :: b ~ c)`, as if they
  were required. This seemed inconsistent with other invisible
  arguments (that are printed like `T @{d}`), so I decided to switch
  this to `T @{a :: b ~ c}`.

Along the way, I also cleaned up a minor inaccuracy in the users'
guide section for constraints in kinds that was spotted in
#12102 (comment 136220).

Fixes #12102 and #15872.

Before

    Version: Wanted [8, 0, 9, 0, 2, 0, 1, 9, 0, 4, 2, 5],
             got    [8, 0, 9, 0, 2, 0, 1, 9, 0, 4, 2, 5]

After

    Version: Wanted 809020190425,
             got    809020190425

This patch removes 'EWildPat', 'EAsPat', 'EViewPat', and 'ELazyPat'
from 'HsExpr' by using the ambiguity resolution system introduced
earlier for the command/expression ambiguity.

Problem: there are places in the grammar where we do not know whether we
are parsing an expression or a pattern, for example:

	do { Con a b <- x } -- 'Con a b' is a pattern
	do { Con a b }      -- 'Con a b' is an expression

Until we encounter binding syntax (<-) we don't know whether to parse
'Con a b' as an expression or a pattern.

The old solution was to parse as HsExpr always, and rejig later:

	checkPattern :: LHsExpr GhcPs -> P (LPat GhcPs)

This meant polluting 'HsExpr' with pattern-related constructors. In
other words, limitations of the parser were affecting the AST, and all
other code (the renamer, the typechecker) had to deal with these extra
constructors.

We fix this abstraction leak by parsing into an overloaded
representation:

	class DisambECP b where ...
	newtype ECP = ECP { runECP_PV :: forall b. DisambECP b => PV (Located b) }

See Note [Ambiguous syntactic categories] for details.

Now the intricacies of parsing have no effect on the hsSyn AST when it
comes to the expression/pattern ambiguity.

We also keep it as an artifact, like we do for non-Hadrian jobs, and list it
as a junit report, so that the test results are reported in the GitLab UI for
merge requests.

Due to #16604.

Use `\min` instead of `min` to typeset it as an operator.

The bulk of the work was done in #712, making settings be make/Hadrian
controlled. This commit then just moves the unlit command rules in
make/Hadrian from the `Config.hs` generator to the `settings` generator
in each build system.

I think this is a good change because the crucial benefit is *settings*
don't affect the build: ghc gets one baby step closer to being a regular
cabal executable, and make/Hadrian just maintains settings as part of
bootstrapping.

It is no longer needed

This allows it to eventually become stage-specific

This does four things:

1. Look at `idArity` instead of manifest lambdas to decide whether to use LetUp
2. Compute the strictness signature in LetDown assuming at least `idArity`
   incoming arguments
3. Remove the special case for trivial RHSs, which is subsumed by 2
4. Don't perform the W/W split when doing so would eta expand a binding.
   Otherwise we would eta expand PAPs, causing unnecessary churn in the
   Simplifier.

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%
         pretty           0.0%     -0.1%
        reptile          -0.0%     -1.2%
--------------------------------------------------------------------------------
            Min          -0.0%     -1.2%
            Max          +0.3%     +0.8%
 Geometric Mean          +0.0%     -0.0%

Previously hsc2hs failed when building against a system FFI.

When encountering type signatures for unknown names, suggest similar
alternatives.

This fixes issue #16504