GitLab

Should make `member` queries faster and avoid messing up with missing
`nubSort`.

Metric Increase:
    hie002

* `interpreterDynamic` and `interpreterProfiled` now take `Interp`
  parameters instead of DynFlags

* slight refactoring of `ExternalInterp` so that we can read the iserv
  configuration (which is pure) without reading an MVar.

* extract flags and ways into their own modules (with some renaming)

* remove one SOURCE import of GHC.Driver.Session from GHC.Driver.Phases

* when GHC uses dynamic linking (WayDyn), `interpWays` was only
  reporting WayDyn even if the host was profiled (WayProf).  Now it
  returns both as expected (might fix #16803).

* `mkBuildTag :: [Way] -> String` wasn't reporting a canonical tag for
  differently ordered lists. Now we sort and nub the list to fix this.

In copying GC, with the relevant debug flags enabled, we release the old
blocks after a GC, and the block allocator zeroes the space before
releasing a block. This effectively zeros the old heap.

In compacting GC we reuse the blocks and previously we didn't zero the
unused space in a compacting generation after compaction. With this
patch we zero the slop between the free pointer and the end of the block
when we're done with compaction and when switching to a new block
(because the current block doesn't have enough space for the next object
we're shifting).

I see quite a few warnings like:

  WARNING: file compiler/utils/Util.hs, line 593
    Over-long elem in unionLists

But the call stack is uninformative.   Better to add HasDebugCallStack
to isIn.  Ditto isn'tIn.

As noted in #17018.

Also fix fragile declaration of T13786, which only runs in the normal
way.

Previously, `tcRules` would check for naughty quantification
candidates (see `Note [Naughty quantification candidates]` in
`TcMType`) when generalising over the type of a rewrite rule. This
caused sensible-looking rewrite rules (like those in #17710) to be
rejected. A more permissing (and easier-to-implement) approach is to
do what is described in `Note [Generalising in tcTyFamInstEqnGuts]`
in `TcTyClsDecls`: just re-quantify all the type variable binders,
regardless of the order in which the user specified them. After all,
the notion of type variable specificity has no real meaning in
rewrite rules, since one cannot "visibly apply" a rewrite rule.
I have written up this wisdom in
`Note [Re-quantify type variables in rules]` in `TcRules`.

As a result of this patch, compiling the `ExplicitForAllRules1` test
case now generates one fewer warning than it used to. As far as I can
tell, this is benign, since the thing that the disappearing warning
talked about was also mentioned in an entirely separate warning.

Fixes #17710.

* GHC.Iface.Recomp: recompilation avoidance stuff
* GHC.Iface.Make: mkIface*

Moved `writeIfaceFile` into GHC.Iface.Load alongside `readIface` and
renamed it `writeIface` for consistency.

macOS Catalina now supports a non-POSIX-compliant version of clock_gettime
which cannot use the clock_gettime codepath.

Fixes #17906.

- Remove Note [Existentials in shift_con_pat].
  The function shift_con_pat has been removed 15 years ago in 23f40f0e.
- Remove kcLookupTcTyCon - it's the same as tcLookupTcTyCon
- Remove ASSERT in tyConAppArgN. It's already done by getNth,
  and it's the only reason getNth exists.
- Remove unused function nextRole

Clarify code added in #17852 and MR !2724

When developing a plugin I had a shadowing problem, where I generated
code
  app = \f{v r7B} x{v r7B} -> f{v r7B} x{v r7B}
This is obviously wrong, since the occurrence of `f` to the right of the
arrow refers to the `x` binder (they share a Unique). However, it is
rather confusing when Lint reports
  Mismatch in type between binder and occurrence
  Var: x{v rB7}
since it is printing the binder, rather than the occurrence.
It is rather easy to read this as claiming there is something wrong with
the `x` occurrence!

We change the report to explicitly print both the binder and the
occurrence variables.

Previously, anyRewritableTyVar looked only at the arg and res
of `arg -> res`, but their RuntimeReps are also subject to
rewriting. Easy to fix.

Test case: typecheck/should_compile/T17024

Fixes #17024.

Closes #17904

This isn't pretty but it's perhaps better than nothing.

This fixes #17786, where the error parser fails to correctly handle the
drive name in absolute Windows paths.

Unfortunately I couldn't find a satisfactory way to test this.

Aside from making the generated code easier to read when
`-ddump-deriv` is enabled, this makes the error message in `T15073`
substantially simpler (see the updated `T15073` expected stderr).

Fixes #17899.

Previously sparks living in the non-moving heap would be promptly GC'd
by the minor collector since pruneSparkQueue uses the BF_EVACUATED flag,
which non-moving heap blocks do not have set.

Fix this by implementing proper support in pruneSparkQueue for
determining reachability in the non-moving heap. The story is told in
Note [Spark management in the nonmoving heap].

This fixes #17893

[skip-ci]

If ImpredicativeTypes is not enabled, then `:print <term>` will fail if the
type of <term> has nested `forall`s or `=>`s.
This is because the GHCi debugger's internals will attempt to unify a
metavariable with the type of <term> and then display the result, but if the
type has nested `forall`s or `=>`s, then unification will fail.
As a result, `:print` will bail out and the unhelpful result will be
`<term> = (_t1::t1)` (where `t1` is a metavariable).

Beware: <term> can have nested `forall`s even if its definition doesn't use
RankNTypes! Here is an example from #14828:

  class Functor f where
    fmap :: (a -> b) -> f a -> f b

Somewhat surprisingly, `:print fmap` considers the type of fmap to have
nested foralls. This is because the GHCi debugger sees the type
`fmap :: forall f. Functor f => forall a b. (a -> b) -> f a -> f b`.
We could envision deeply instantiating this type to get the type
`forall f a b. Functor f => (a -> b) -> f a -> f b`,
but this trick wouldn't work for higher-rank types.

Instead, we adopt a simpler fix: enable `ImpredicativeTypes` when using
`:print` and friends in the GHCi debugger. This is allows metavariables
to unify with types that have nested (or higher-rank) `forall`s/`=>`s,
which makes `:print fmap` display as
`fmap = (_t1::forall a b. Functor f => (a -> b) -> f a -> f b)`, as expected.

Although ImpredicativeTypes is a somewhat unpredictable from a type inference
perspective, there is no danger in using it in the GHCi debugger, since all
of the terms that the GHCi debugger deals with have already been typechecked.

Do not define hs_atomicread64() and hs_atomicwrite64() on machines where
WORD_SIZE_IN_BITS is less than 64, just like we do with the rest of the atomic
functions which work on 64-bit values.

Without this, compilation fails on MIPSel and PowerPC with the following error:

/usr/bin/ld: /<<PKGBUILDDIR>>/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.5.3_p.a(atomic.p_o): in function `hs_atomicread64':
atomic.c:(.text.hs_atomicread64+0x8): undefined reference to `__sync_add_and_fetch_8'
/usr/bin/ld: /<<PKGBUILDDIR>>/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.5.3_p.a(atomic.p_o): in function `hs_atomicwrite64':
atomic.c:(.text.hs_atomicwrite64+0x38): undefined reference to `__sync_bool_compare_and_swap_8'

Fixes #17886.

* The names in PrelName and THNames are no longer used
  since TH merged types and kinds, Typeable is kind-polymorphic,
  .net support was removed
* unqualQuasiQuote no longer used since 6f8ff0bb

GHCi is split up into 2 major parts: The user-interface (UI)
and the byte-code interpreter. With `-fexternal-interpreter`
they even run in different processes. Communication between
the UI and the Interpreter (called `iserv`) is done using
messages over a pipe. This is called `Remote GHCI` and
explained in the Note [Remote GHCi] in `compiler/ghci/GHCi.hs`.

To process a `:force` command the UI sends a `Seq` message
to the `iserv` process. Then `iserv` does the effective
evaluation of the value. When during this process a breakpoint
is hit, the `iserv` process has no additional information to
enhance the `Ignoring breakpoint` output with the breakpoint
location.

To be able to print additional breakpoint information,
there are 2 possible implementation choices:
1. Store the needed information in the `iserv` process.
2. Print the `Ignoring breakpoint` from the UI process.

For option 1 we need to store the breakpoint info redundantely
in 2 places and this is bad. Therfore option 2 was implemented
in this MR:
- The user enters a `force` command
- The UI sends  a `Seq` message to the `iserv` process.
- If processing of the `Seq` message hits a breakpoint,
  the `iserv` process returns control to the UI process.
- The UI looks up the source location of the breakpoint,
  and prints the enhanced `Ignoring breakpoint` output.
- The UI sends a `ResumeSeq` message to the `iserv` process,
  to continue forcing.

IfaceIdInfo type is confusing: there's practically no difference between
`NoInfo` and `HasInfo []`. The comments say NoInfo is used when
-fomit-interface-pragmas is enabled, but we don't need to distinguish
`NoInfo` from `HasInfo []` in when reading the interface so the
distinction is not important.

This patch simplifies the type by removing NoInfo. When we have no info
we use an empty list.

With this change we no longer read the info list lazily when reading an
IfaceInfoItem, but when reading an IfaceId the ifIdInfo field is
read lazily, so I doubt this is going to be a problem.