GitLab

Intermediate STG does not contain free variables which can be useful
sometimes. So adding a flag to dump that info.

Point users to the right URL

Hadrian's "binary-dist" target must check that the "docs" directory
exists (it may not since we can disable docs generation).

* simplifies registers to have GPR, Float and Double, by removing the SSE2 and X87 Constructors
* makes -msse2 assumed/default for x86 platforms, fixing a long standing nondeterminism in rounding
behavior in 32bit haskell code
* removes the 80bit floating point representation from the supported float sizes
* theres still 1 tiny bit of x87 support needed,
for handling float and double return values in FFI calls  wrt the C ABI on x86_32,
but this one piece does not leak into the rest of NCG.
* Lots of code thats not been touched in a long time got deleted as a
consequence of all of this

all in all, this change paves the way towards a lot of future further
improvements in how GHC handles floating point computations, along with
making the native code gen more accessible to a larger pool of contributors.

Using `ghc-prim <= 0.6.1` is somewhat dodgy from a PVP point of view,
as it makes it awkward to support new minor releases of `ghc-prim`.
Let's instead use `< 0.7`, which is the idiomatic way of expressing
PVP-compliant upper version bounds.

It should be entirely the responsibility of make/Hadrian to ensure that
everything that needs this flag gets it. GHC shouldn't be hardcoded to
assist with bootstrapping since it builds other things besides itself.

Reviewers:

Subscribers: TerrorJack, rwbarton, carter

GHC Trac Issues: #15548 -- progress towards but not fix

Differential Revision: https://phabricator.haskell.org/D5082 -- extract
from that

Hopefully fixes Windows Hadrian build.

GHC now works out-of-the-box (i.e. without any wrapper script) by
assuming that @bin@ and @lib@ directories sit next to each other. In
particular, its RUNPATH uses $ORIGIN-based relative path to find the
libraries.

However, to be good citizens we want to support the case where @bin@ and
@lib@ directories (respectively BINDIR and LIBDIR) don't sit next to
each other or are renamed. To do that the install script simply creates
GHC specific @bin@ and @lib@ siblings directories into:

   LIBDIR/ghc-VERSION/{bin,lib}

Then it installs wrapper scripts into BINDIR that call the appropriate
programs into LIBDIR/ghc-VERSION/bin/.

The issue fixed by this patch is that libraries were not installed into
LIBDIR/ghc-VERSION/lib but directly into LIBDIR.

Fixes #16052

When the offset in `setByteArray#` is statically known, we can provide
better alignment guarantees then just 1 byte.

Also, memset can now do 64-bit wide sets.

The current memset intrinsic is not optimal however and can be
improved for the case when we know that we deal with

(baseAddress at known alignment) + offset

For instance, on 64-bit

`setByteArray# s 1# 23# 0#`

given that bytearray is 8 bytes aligned could be unrolled into
`movb, movw, movl, movq, movq`; but currently it is
`movb x23` since alignment of 1 is all we can embed into MO_Memset op.

As noted in #16309 this somehow went undocumented.

Currently, the `hpc` submodule is pinned against the `wip/final-mfp`
branch, not against `master`. This pins it back against `master`.

We're might be about to switch to generating it in Hadrian/Make. This
reformat makes it easier to programmingmatically generate and end up
with the exact same thing, which is good for diffing to ensure no
regressions.

I had this as part of !712, but given the difficulty of satisfying CI, I
figured I should break things up even further.

These tests use unboxed tuples, which GHCi doesn't support

Previously, `singleConstructor` didn't handle singleton `COMPLETE` sets
of a single pattern synonym, resulting in incomplete pattern warnings
in #15753.

This is fixed by making `singleConstructor` (now named
`singleMatchConstructor`) query `allCompleteMatches`, necessarily making
it effectful. As a result, most of this patch is concerned with
threading the side-effect through to `singleMatchConstructor`.

Unfortunately, this is not enough to completely fix the original
reproduction from #15753 and #15884, which are related to function
applications in pattern guards being translated too conservatively.

Was broken via #16389 yet strangely it has started passing despite the
fact that the suggested root cause has not changed.

We are currently ignoring options set in the hiDir field of hsc_dflags
when looking for interface files while compiling in OneShot mode. This
is inconsistent with the behaviour of other directory redirecting fields
(such as objectDir or hieDir). It is also inconsistent with the
behaviour of compilation in CompManager mode (a.k.a `ghc --make`) which
looks for interface files in the directory set in hidir flag. This
changes Finder.hs so that we use the value of hiDir while looking for
interface in OneShot mode.

GHC has an optimization for allocating arrays when the size is
statically known -- it'll generate the code allocating and initializing
the array inline (instead of a call to a procedure from
`rts/PrimOps.cmm`).

However, the generated code uses a loop to do the initialization. Since
we already check that the requested size is small (we check against
`maxInlineAllocSize`), we can generate faster straightline code instead.
This brings about 15% improvement for `newSmallArray#` in my testing and
slightly simplifies the code in GHC.
Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com>

Previously, -W(all-)missed-specs was created with 'NoReason',
so no information about the flag was printed along with the warning.
Now, -Wall-missed-specs is listed as the Reason if it was set,
otherwise -Wmissed-specs is listed as the reason.

This program, from #13971, currently has a rather confusing error
message:

```hs
class C a where
  type T a :: k
  type T a = Int
```
```
    • Kind mis-match on LHS of default declaration for ‘T’
    • In the default type instance declaration for ‘T’
      In the class declaration for ‘C’
```

It's not at all obvious why GHC is complaining about the LHS until
you realize that the default, when printed with
`-fprint-explicit-kinds`, is actually `type T @{k} @* a = Int`.
That is to say, the kind of `a` is being instantiated to `Type`,
whereas it ought to be a kind variable. The primary thrust of this
patch is to weak the error message to make this connection
more obvious:

```
    • Illegal argument ‘*’ in:
        ‘type T @{k} @* a = Int’
        The arguments to ‘T’ must all be type variables
    • In the default type instance declaration for ‘T’
      In the class declaration for ‘C’
```

Along the way, I performed some code cleanup suggested by @rae in
ghc/ghc#13971 (comment 191287). Before,
we were creating a substitution from the default declaration's type
variables to the type family tycon's type variables by way of
`tcMatchTys`. But this is overkill, since we already know (from the
aforementioned validity checking) that all the arguments in a default
declaration must be type variables anyway. Therefore, creating the
substitution is as simple as using `zipTvSubst`. I took the
opportunity to perform this refactoring while I was in town.

Fixes #13971.

This fixes #16514: Xmm6-15 was restored based off rax instead of rsp.
The code was introduced in the fix for #14619.

A simple oversight. Fixes #16527.

This patch corrects two simple oversights that led to #16518:

1. `HsUtils.typeToLHsType` was taking visibility into account in the
   `TyConApp` case, but not the `AppTy` case. I've factored out the
   visibility-related logic into its own `go_app` function and now
   invoke `go_app` from both the `TyConApp` and `AppTy` cases.
2. `Type.fun_kind_arg_flags` did not properly split kinds with
   nested `forall`s, such as
   `(forall k. k -> Type) -> (forall k. k -> Type)`. This was simply
   because `fun_kind_arg_flags`'s `FunTy` case always bailed out and
   assumed all subsequent arguments were `Required`, which clearly
   isn't the case for nested `forall`s. I tweaked the `FunTy` case
   to recur on the result kind.

Fixes #16445.

Issues #16289 and #15713 are proof that the pattern match checker did
an unsound job of estimating the value set abstraction corresponding to
the uncovered set.

The reason is that the fix from #11303 introducing `NLit` was
incomplete: The `LitCon` case desugared to `Var` rather than `LitVar`,
which would have done the necessary case splitting analogous to the
`ConVar` case.

This patch rectifies that by introducing the fresh unification variable
in `LitCon` in value abstraction position rather than pattern postition,
recording a constraint equating it to the constructor expression rather
than the literal. Fixes #16289 and #15713.

This fixes #16440, where the build system incorrectly concluded that the
`.subsections_via_symbols` assembler directive was supported on a Linux
system. This was caused by the fact that gcc was invoked with `-flto`;
when so-configured gcc does not call the assembler but rather simply
serialises its AST for compilation during the final link.

This is described in Note [autoconf assembler checks and -flto].

The law as it is currently written is meaningless, because nowhere have
we defined the implementation of 'ap'. The reader of the Control.Monad
documentation is provided with only a type signature,

> ap :: Monad m => m (a -> b) -> m a -> m b

an informal description,

> In many situations, the liftM operations can be replaced by uses of
> ap, which promotes function application.

and a relationship between 'ap' and the 'liftM' functions

> return f `ap` x1 `ap` ... `ap` xn
> is equivalent to
> liftMn f x1 x2 ... xn

Without knowing how 'ap' is defined, a law involving 'ap' cannot
provide any guidance for how to write a lawful Monad instance, nor can
we conclude anything from the law.

I suspect that a reader equipped with the understanding that 'ap' was
defined prior to the invention of the Applicative class could deduce
that 'ap' must be defined in terms of (>>=), but nowhere as far as I can
tell have we written this down explicitly for readers without the
benefit of historical context.

If the law is meant to express a relationship among (<*>), (>>=), and
'return', it seems that it is better off making this statement directly,
sidestepping 'ap' altogether.