GitLab

There are quite a few keywords which are allowed to be used as
variables. Such as "as", "dependency" etc. These weren't accepted by
OverloadedDotSyntax.

The fix is pretty simple, use the varid production rather than raw
VARID.

Fixes #20723

Previously, when a plugin could not be loaded because it was incorrectly typed, the error message only printed the expected but not the actual type. 
This commit augments the error message such that both types are printed and the corresponding module is printed as well.

This significantly improves Haddock documentation generated by nix.

  There are two different ways of declaring a class in an hs-boot file:

    - a full declaration, where everything is written as it is
      in the .hs file,
    - an abstract declaration, where class methods and superclasses
      are left out.

  However, a declaration with no methods and a trivial superclass,
  such as:

    class () => C a

  was erroneously considered to be an abstract declaration, because
  the superclass is trivial.
  This is remedied by a one line fix in GHC.Tc.TyCl.tcClassDecl1.

  This patch also further clarifies the documentation around
  class declarations in hs-boot files.

  Fixes #20661, #20588.

When processing the heap, use also `APClosures` to create additional type
constraints. This adds more equations and therefore improves the unification
process to infer the correct type of values at breakpoints.
(Fix the `incr` part of #19559)

Instead, introduce plusInstalledModuleEnv

There is more than one possible Semigroup and it is not needed since plusModuleEnv can be used directly

It isn't much more complicated to be more precise when deriving Lift so
we now generate

```
data Foo = Foo Int Bool

instance Lift Foo where
  lift (Foo a b) = [| Foo $(lift a) $(lift b) |]
  liftTyped (Foo a b) = [|| Foo $$(lift a) $$(lift b) |]
```

This fixes #20688 which complained about using implicit lifting in the
derived code.

* Remove `getTag_RDR` (unused), `tidyKind` and `tidyOpenKind`
  (already available as `tidyType` and `tidyOpenType`)

* Remove Note [Explicit Case Statement for Specificity].
  Since 0a709dd9 we require GHC 8.10 for bootstrapping.

* Change the warning to `cmpAltCon` to a panic.
  This shouldn't happen.  If it ever does, the code was wrong anyway:
  it shouldn't always return `LT`, but rather `LT` in one case
  and `GT` in the other case.

* Rename `verifyLinearConstructors` to `verifyLinearFields`

* Fix `Note [Local record selectors]` which was not referenced

* Remove vestiges of `type +v`

* Minor fixes to StaticPointers documentation, part of #15603

This commit fixes #20641 by checking the types of recursive
let-bindings when performing alpha-equality.

The `Eq (DeBruijn CoreExpr)` instance now also compares
`BreakPoint`s similarly to `GHC.Core.Utils.eqTickish`, taking
bound variables into account.

In addition, the `Eq (DeBruijn Type)` instance now correctly
compares the kinds of the types when one of them contains a
Cast: the instance is modeled after `nonDetCmpTypeX`.

The `ctev_pred` field of a `CtEvidence` is a just a cache for the type
of the evidence.  More precisely:
* For Givens, `ctev_pred` = `varType ctev_evar`
* For Wanteds, `ctev_pred` = `evDestType ctev_dest`

This new invariant is needed because evidence can become part of a
type, via `Castty ty kco`.

This reverts commit df1d808f.

Note [Hydrating Modules]
~~~~~~~~~~~~~~~~~~~~~~~~

What is hydrating a module?

* There are two versions of a module, the ModIface is the on-disk version and the ModDetails is a fleshed-out in-memory version.
* We can **hydrate** a ModIface in order to obtain a ModDetails.

Hydration happens in three different places

* When an interface file is initially loaded from disk, it has to be hydrated.
* When a module is finished compiling, we hydrate the ModIface in order to generate
  the version of ModDetails which exists in memory (see Note)
* When dealing with boot files and module loops (see Note [Rehydrating Modules])

Note [Rehydrating Modules]
~~~~~~~~~~~~~~~~~~~~~~~~~~~

If a module has a boot file then it is critical to rehydrate the modules on
the path between the two.

Suppose we have ("R" for "recursive"):
```
R.hs-boot:   module R where
               data T
               g :: T -> T

A.hs:        module A( f, T, g ) where
                import {-# SOURCE #-} R
                data S = MkS T
                f :: T -> S = ...g...

R.hs:        module R where
                data T = T1 | T2 S
                g = ...f...
```

After compiling A.hs we'll have a TypeEnv in which the Id for `f` has a type
type uses the AbstractTyCon T; and a TyCon for `S` that also mentions that same
AbstractTyCon. (Abstract because it came from R.hs-boot; we know nothing about
it.)

When compiling R.hs, we build a TyCon for `T`.  But that TyCon mentions `S`, and
it currently has an AbstractTyCon for `T` inside it.  But we want to build a
fully cyclic structure, in which `S` refers to `T` and `T` refers to `S`.

Solution: **rehydration**.  *Before compiling `R.hs`*, rehydrate all the
ModIfaces below it that depend on R.hs-boot.  To rehydrate a ModIface, call
`typecheckIface` to convert it to a ModDetails.  It's just a de-serialisation
step, no type inference, just lookups.

Now `S` will be bound to a thunk that, when forced, will "see" the final binding
for `T`; see [Tying the knot](https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/compiler/tying-the-knot).
But note that this must be done *before* compiling R.hs.

When compiling R.hs, the knot-tying stuff above will ensure that `f`'s unfolding
mentions the `LocalId` for `g`.  But when we finish R, we carefully ensure that
all those `LocalIds` are turned into completed `GlobalIds`, replete with
unfoldings etc.   Alas, that will not apply to the occurrences of `g` in `f`'s
unfolding. And if we leave matters like that, they will stay that way, and *all*
subsequent modules that import A will see a crippled unfolding for `f`.

Solution: rehydrate both R and A's ModIface together, right after completing R.hs.

We only need rehydrate modules that are
* Below R.hs
* Above R.hs-boot

There might be many unrelated modules (in the home package) that don't need to be
rehydrated.

This dark corner is the subject of #14092.

Suppose we add to our example
```
X.hs     module X where
           import A
           data XT = MkX T
           fx = ...g...
```
If in `--make` we compile R.hs-boot, then A.hs, then X.hs, we'll get a `ModDetails` for `X` that has an AbstractTyCon for `T` in the the argument type of `MkX`.  So:

* Either we should delay compiling X until after R has beeen compiled.
* Or we should rehydrate X after compiling R -- because it transitively depends on R.hs-boot.

Ticket #20200 has exposed some issues to do with the knot-tying logic in GHC.Make, in `--make` mode.
this particular issue starts [here](#20200 (comment 385758)).

The wiki page [Tying the knot](https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/compiler/tying-the-knot) is helpful.
Also closely related are
    * #14092
    * #14103

Fixes tickets #20200 #20561

Previously we would traverse the STG AST twice looking for free variables.
 * Once in `annTopBindingsDeps` which considers top level and imported ids free.
   Its output is used to put bindings in dependency order. The pass happens
   in STG pipeline.
 * Once in `annTopBindingsFreeVars` which only considers non-top level ids free.
   Its output is used by the code generator to compute offsets into closures.
   This happens in Cmm (CodeGen) pipeline.

Now these two traversal operations are merged into one - `FVs.depSortWithAnnotStgPgm`.
The pass happens right at the end of STG pipeline. Some type signatures had to be
updated due to slight shifts of StgPass boundaries (for example, top-level CodeGen
handler now directly works with CodeGen flavoured Stg AST instead of Vanilla).

Due to changed order of bindings, a few debugger type reconstruction bugs
have resurfaced again (see tests break018, break021) - work item #18004 tracks this
investigation.

authors: simonpj, nineonine

Previously, it was an error to pattern match on a GADT
without GADTs or TypeFamilies.
This is now allowed. Instead, we check the flag MonoLocalBinds;
if it is not enabled, we issue a warning, controlled by -Wgadt-mono-local-binds.

Also fixes #20485: pattern synonyms are now checked too.

No-op assignments like R1 = R1 are not only wasteful. They can also
inhibit other optimizations like inlining assignments that read from
R1.

We now check for assignments being a no-op before and after we
simplify the RHS in Cmm sink which should eliminate most of these
no-ops.

As #20709 showed, GHC could prioritise a wrapper over a SPEC
rule, which is potentially very bad.  This patch fixes that
problem.

The fix is is described in Note [Wrapper activation], especially
item 4, 4a, and Conclusion.

For now, it has a temporary hack (replicating what was there before
to make sure that wrappers inline no earlier than phase 2.  But
it should be temporary; see #19001.

  When instances overlap, we now include additional information
  about why we weren't able to select an instance: perhaps
  one instance overlapped another but was not strictly more specific,
  so we aren't able to directly choose it.

Fixes #20542

T12545 is very inconsistently affected by this change for some reason.
There is a decrease in allocations on most configurations, but
an increase on validate-x86_64-linux-deb9-unreg-hadrian. Accepting it
as it seems unrelated to this patch.

Metric Decrease:
    T12545
Metric Increase:
    T12545

This is a preliminary refactoring for #14335 (supporting plugins in
cross-compilers). In many places the home-unit must be optional because
there won't be one available in the plugin environment (we won't be
compiling anything in this environment). Hence we replace "HomeUnit"
with "Maybe HomeUnit" in a few places and we avoid the use of
"hsc_home_unit" (which is partial) in some few others.

.bkp mode had this unused feature where you could write

  module A

and it would go looking for A.hs on the file system and use that rather
than provide the definition inline.

This isn't use anywhere in the testsuite and the code to find the module
A looks dubious. Therefore to reduce .bkp complexity I propose to remove
it.

Fixes #20701

Ticket #19815 suggested changing coToMCo to use
isReflexiveCo rather than isReflCo.  But perf results
weren't encouraging. This patch just adds a comment to
point to the data, such as it is.

Currently in GHCi, when given a line of user input we:

1. Attempt to parse and handle it as a statement
2. Otherwise, attempt to parse and handle a single import
3. Otherwise, check if there are imports present (and if so display an error message)
4. Otherwise, attempt to parse a module and only handle the declarations

This patch simplifies the process to:

Attempt to parse and handle it as a statement
Otherwise, attempt to parse a module and handle the imports and declarations

This means that multiple imports in a multiline are now accepted, and a multiline containing both imports and declarations is now accepted (as well as when separated by semicolons).

Since 8.10, when formatting a pattern match warning, we'd case split on a
wildcard match such as
```hs
foo :: [a] -> [a]
foo [] = []
foo xs = ys
  where
  (_, ys@(_:_)) = splitAt 0 xs
-- Pattern match(es) are non-exhaustive
-- In a pattern binding:
--     Patterns not matched:
--         ([], [])
--         ((_:_), [])
```
But that's quite verbose and distracts from which part of the pattern was
actually the inexhaustive one. We'd prefer a wildcard for the first pair
component here, like it used to be in GHC 8.8.

On the other hand, case splitting is pretty handy for `-XEmptyCase` to know the
different constructors we could've matched on:
```hs
f :: Bool -> ()
f x = case x of {}
-- Pattern match(es) are non-exhaustive
-- In a pattern binding:
--     Patterns not matched:
--         False
--         True
```
The solution is to communicate that we want a top-level case split to
`generateInhabitingPatterns` for `-XEmptyCase`, which is exactly what
this patch arranges. Details in `Note [Case split inhabiting patterns]`.

Fixes #20642.

Fixes #20541 by making mkTyConApp do more sharing of types.
In particular, replace

* BoxedRep Lifted    ==>  LiftedRep
* BoxedRep Unlifted  ==>  UnliftedRep
* TupleRep '[]       ==>  ZeroBitRep
* TYPE ZeroBitRep    ==>  ZeroBitType

In each case, the thing on the right is a type synonym
for the thing on the left, declared in ghc-prim:GHC.Types.
See Note [Using synonyms to compress types] in GHC.Core.Type.

The synonyms for ZeroBitRep and ZeroBitType are new, but absolutely
in the same spirit as the other ones.   (These synonyms are mainly
for internal use, though the programmer can use them too.)

I also renamed GHC.Core.Ty.Rep.isVoidTy to isZeroBitTy, to be
compatible with the "zero-bit" nomenclature above.  See discussion
on !6806.

There is a tricky wrinkle: see GHC.Core.Types
  Note [Care using synonyms to compress types]

Compiler allocation decreases by up to 0.8%.

I've already fixed this 7 months ago in the comments of #16780 but it
never got merged. Now we need this for #20657 too.

Previously, the `deriving` machinery was very loosey-goosey about how it used
the types of data constructor fields when generating code. It would usually
just consult `dataConOrigArgTys`, which returns the _uninstantiated_ field
types of each data constructor. Usually, you can get away with this, but
issues #20375 and #20387 revealed circumstances where this approach fails.

Instead, when generated code for a stock-derived instance
`C (T arg_1 ... arg_n)`, one must take care to instantiate the field types of
each data constructor with `arg_1 ... arg_n`. The particulars of how this is
accomplished is described in the new
`Note [Instantiating field types in stock deriving]` in
`GHC.Tc.Deriv.Generate`. Some highlights:

* `DerivInstTys` now has a new `dit_dc_inst_arg_env :: DataConEnv [Type]`
  field that caches the instantiated field types of each data constructor.
  Whenever we need to consult the field types somewhere in `GHC.Tc.Deriv.*`
  we avoid using `dataConOrigArgTys` and instead look it up in
  `dit_dc_inst_arg_env`.
* Because `DerivInstTys` now stores the instantiated field types of each
  constructor, some of the details of the `GHC.Tc.Deriv.Generics.mkBindsRep`
  function were able to be simplified. In particular, we no longer need to
  apply a substitution to instantiate the field types in a `Rep(1)` instance,
  as that is already done for us by `DerivInstTys`. We still need a
  substitution to implement the "wrinkle" section of
  `Note [Generating a correctly typed Rep instance]`, but the code is
  nevertheless much simpler than before.
* The `tyConInstArgTys` function has been removed in favor of the new
  `GHC.Core.DataCon.dataConInstUnivs` function, which is really the proper tool
  for the job. `dataConInstUnivs` is much like `tyConInstArgTys` except that it
  takes a data constructor, not a type constructor, as an argument, and it adds
  extra universal type variables from that data constructor at the end of the
  returned list if need be. `dataConInstUnivs` takes care to instantiate the
  kinds of the universal type variables at the end, thereby avoiding a bug in
  `tyConInstArgTys` discovered in
  #20387 (comment 377037).

Fixes #20375. Fixes #20387.

`DataConEnv` will prove to be useful in another place besides
`GHC.Core.Opt.SpecConstr` in a follow-up commit.

Various functions in GHC.Tc.Deriv.* were passing around `TyCon`s and
`[Type]`s that ultimately come from the same `DerivInstTys`. This patch
moves the definition of `DerivInstTys` to `GHC.Tc.Deriv.Generate` so that
all of these `TyCon` and `[Type]` arguments can be consolidated into a
single `DerivInstTys`. Not only does this make the code easier to read
(in my opinion), this will also be important in a subsequent commit where we
need to add another field to `DerivInstTys` that will also be used from
`GHC.Tc.Deriv.Generate` and friends.

This was a simple (but long standing) error in simplArg,
revealed by #20639