GitLab

This moves all URL references to Trac tickets to their corresponding
GitLab counterparts.

[skip ci]

Issue #12770

The GHCi debugger has never been that robust in the face of
higher-rank types, or even types that are _interally_ higher-rank,
such as the types of many class methods (e.g., `fmap`). In GHC 8.2,
however, things became even worse, as the debugger would start to
_panic_ when a user tries passing the name of a higher-rank thing
to `:print`. This all ties back to a strange `isUnliftedType` check
in `Debugger` that was mysteriously added 11 years ago
(in commit 4d71f5ee) with no
explanation whatsoever.

After some experimentation, no one is quite sure what this
`isUnliftedType` check is actually accomplishing. The test suite
still passes if it's removed, and I am unable to observe any
differences in debugger before even with data types that _do_ have
fields of unlifted types (e.g., `data T = MkT Int#`). Given that
this is actively causing problems (see #14828), the prudent thing
to do seems to be just removing this `isUnliftedType` check, and
waiting to see if anyone shouts about it. This patch accomplishes
just that.

Note that this patch fix the underlying issues behind #14828, as the
debugger will still print unhelpful info if you try this:

```
λ> f :: (forall a. a -> a) -> b -> b; f g x = g x
λ> :print f
f = (_t1::t1)
```

But fixing this will require much more work, so let's start with the
simple stuff for now.

The `dataConCannotMatch` function (which powers the
`-Wpartial-fields` warning, among other things) had special reasoning
for explicit equality constraints of the form `a ~ b`, but it did
not extend that reasoning to `a ~~ b` constraints, leading to #16411.
Easily fixed.

With all the recent fixes to the binary-dist rule in Hadrian, we can now run
that rule in CI and keep the bindists around in gitlab as artifacts, just like
we do for the make CI jobs.

To get 'autoreconf' to work in the Windows CI, we have to run it through the
shell interpreter, so this commit does that along the way.

See #15382.

Commit 1f5cc9dc ended up
fixing #16347. Let's add a regression test to ensure that it stays
fixed.

Also remove unused arg from get_Regtable_addr_from_offset

Code in TcErrors was recursively using immSuperClasses,
which loops in the presence of UndecidableSuperClasses.

Better to use transSuperClasses instead, which has a loop-breaker
mechanism built in.

Fixes issue #16414.

This is a separate build job to the other hadrian jobs as it only takes
about 2-3 minutes to run from cold. The CI tests that the
`./hadrian/ghci` script loads `ghc/Main.hs` successfully.

Running the `./hadrian/ghci` target will load the main compiler into
a ghci session. This is intended for fast development feedback, modules are only
typechecked so it isn't possible to run any functions in the repl.

You can also use this target with `ghcid`.

The first time this command is run hadrian will need to compile a few dependencies
which will take 1-2 minutes. Loading GHC into GHCi itself takes about 30 seconds.

Internally this works by calling a new hadrian target called `tool-args`.
This target prints out the package and include flags which are necessary
to load files into ghci. The same target is intended to be used by other
tooling which uses the GHC API in order to set up the correct GHC API
session. For example, using this target it is also possible to use HIE
when developing on GHC.

After being copied all the shared objects end up in the same directory.
Therefore the correct rpath is `$ORIGIN` rather than the computed
path which is relative to the directory where it is built.

makeRelativeNoSysLink would previously crash for no reason if the first
argument as `./` due to the call to `head`. This refactoring keeps the
behaviour the same but doesn't crash in this corner case.

The version suffix needs to be the version of the stage 0 compiler
when building shared libraries with the stage 0 compiler.

Setting `CABFLAGS=args` will pass the additional arguments to cabal
when it is invoked.

It no longer gives a warning.

We'd like to enforce the substitution invariant (Trac #11371).
In a492af06 the assertion was downgraded to a warning;
I'm restoring the assertion and making the calls that
don't maintain the invariant as unchecked.

Prevents some tests from failing just due to mismatched version numbers.

These version numbers shouldn't cause tests to fail, especially since
we *expect* them to be regularly incremented. The motivation for this
particular set of changes came from the changes that came along with
the `base` version bump in 8f19ecc9.

This doesn't appear to be used anywhere in the build system and it
relies on perl. Drop it.

The object splitter was the last major user of perl. There remain a few
uses in nofib but we can just rely on the system's perl for this since
it's not critical to the build.

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
-------------------------