GitLab

This flag requires that there be no space
between the filename and the argument.

As noted in #9666, the mark-region GC is not compatible with heap
profiling. Also add documentation for this flag.

Closes #9666.

But only when profiling or DEBUG are enabled.

Fixes #17572.

This is necessary since the user may enable `+RTS -hT` at any time.

It turns out that this was fairly straightforward to implement since we
are now pretty careful about zeroing slop.

Move the logic for taking censuses of "normal" and pinned blocks to
their own functions.

Before this patch the compiler depended on the RTS way (threaded or not)
to use atomic incrementation or not. This is wrong because the RTS is
supposed to be switchable at link time, without recompilation.

Now we always use atomic incrementation of the unique counter.

I'm not sure how long the submodule dance is going to take, sadly, so
I'd like to chip away at things in the meantime / avoid conflicts.

The fix for 18919 was somewhat incomplete: while the MVars were
correctly added to the mut_list via dirty_MVAR(), their info table
remained "clean".

While this is mostly harmless in non-debug builds, but trips an
assertion in the debug build, and may result in the MVar being
needlessly being added to the mut_list multiple times.

Resolves: #19145

This patch fixes #19133 by using LitRubbish for strict constructor
fields, even if they are of lifted types.  Previously LitRubbish
worked only for unlifted (but boxed) types.

The change is very easy, although I needed a boolean field in
LitRubbish to say whether or not it is lifted.  (That seemed easier
than giving it another type argument.

This is preparing for Andreas's work on establishing the invariant
that strict constructor fields are always tagged and evaluated
(see #16970).

Meanwhile, nothing was actually wrong before, so there are no tests.

Fixes #19124

It's simpler to assume that base is NoImplicitPrelude,
otherwise running doctest on `GHC.*` modules would be tricky.
OTOH, most `GHC.List` (where the most name clashes are) examples
could be changed to use `import qualified Data.List as L`.
(GHC.List examples won't show for Foldable methods...).

With these changes majority of doctest examples are GHCi-"faithful",
my WIP GHC-independent doctest runner reports nice summary:

Examples: 582; Tried: 546; Skipped: 34; Success: 515; Errors: 33; Property Failures 2

Most error cases are *Hangs forever*.
I have yet to figure out how to demonstrate that in GHCi.
Some of divergences are actually stack overflows, i.e. caught by
runtime.

Few errorful cases are examples of infinite output, e.g.

    >>> cycle [42]
    [42,42,42,42,42,42,42,42,42,42...

while correct, they confuse doctest.

Another erroneous cases are where expected output has line comment, like

    >>> fmap show (Just 1)  --  (a   -> b)      -> f a       -> f b
    Just "1"                --  (Int -> String) -> Maybe Int -> Maybe String

I think I just have to teach doctest to strip comments from expected
output.

This is a first patch in a series.
There is plenty of stuff already.

it is unclear why it is there, and it is _also_ linked from
`exts/types.rst`.

This patch establishes invariant (GivenInv) from GHC.Tc.Utils.TcType
Note [TcLevel invariants].  (GivenInv) says that unification variables
from level 'n' should not appear in the Givens for level 'n'.  See
Note [GivenInv] in teh same module.

This invariant was already very nearly true, but a dark corner of
partial type signatures made it false.  The patch re-jigs partial type
signatures a bit to avoid the problem, and documents the invariant
much more thorughly

Fixes #18646 along the way: see Note [Extra-constraints wildcards]
in GHC.Tc.Gen.Bind

I also simplified the interface to tcSimplifyInfer slightly, so that
it /emits/ the residual constraint, rather than /returning/ it.

In general we are less careful about locking closures when running with
only a single capability.

Fixes #19075.

(Progress towards #11953, #17377, #17375)

Besides being nicer to use, this also will allow for better constant
folding for the fixed-width types, on par with what `Int#` and `Word#`
have today.

Allow INLINE and NOINLINE pragmas to be used for patterns.
Those are applied to both the builder and matcher (where applicable).

Backpack instantiations need to be typechecked to make sure that the
arguments fit the parameters. `tcRnInstantiateSignature` checks
instantiations with concrete modules, while `tcRnCheckUnit` checks
instantiations with free holes (signatures in the current modules).

Before this change, it worked that `tcRnInstantiateSignature` was called
after typechecking the argument module, see `HscMain.hsc_typecheck`,
while `tcRnCheckUnit` was called in `unsweep'` where-bound in
`GhcMake.upsweep`. `tcRnCheckUnit` was called once per each
instantiation once all the argument sigs were processed. This was done
with simple "to do" and "already done" accumulators in the fold.
`parUpsweep` did not implement the change.

With this change, `tcRnCheckUnit` instead is associated with its own
node in the `ModuleGraph`. Nodes are now:
```haskell
data ModuleGraphNode
  -- | Instantiation nodes track the instantiation of other units
  -- (backpack dependencies) with the holes (signatures) of the current package.
  = InstantiationNode InstantiatedUnit
  -- | There is a module summary node for each module, signature, and boot module being built.
  | ModuleNode ExtendedModSummary
```
instead of just `ModSummary`; the `InstantiationNode` case is the
instantiation of a unit to be checked. The dependencies of such nodes
are the same "free holes" as was checked with the accumulator before.
Both versions of upsweep on such a node call `tcRnCheckUnit`.

There previously was an `implicitRequirements` function which would
crawl through every non-current-unit module dep to look for all free
holes (signatures) to add as dependencies in `GHC.Driver.Make`. But this
is no good: we shouldn't be looking for transitive anything when
building the graph: the graph should only have immediate edges and the
scheduler takes care that all transitive requirements are met.

So `GHC.Driver.Make` stopped using `implicitRequirements`, and instead
uses a new `implicitRequirementsShallow`, which just returns the
outermost instantiation node (or module name if the immediate dependency
is itself a signature). The signature dependencies are just treated like
any other imported module, but the module ones then go in a list stored
in the `ModuleNode` next to the `ModSummary` as the "extra backpack
dependencies". When `downsweep` creates the mod summaries, it adds this
information too.

------

There is one code quality, and possible correctness thing left: In
addition to `implicitRequirements` there is `findExtraSigImports`, which
says something like "if you are an instantiation argument (you are
substituted or a signature), you need to import its things too".  This
is a little non-local so I am not quite sure how to get rid of it in
`GHC.Driver.Make`, but we probably should eventually.

First though, let's try to make a test case that observes that we don't
do this, lest it actually be unneeded. Until then, I'm happy to leave it
as is.

------

Beside the ability to use `-j`, the other major user-visibile side
effect of this change is that that the --make progress log now includes
"Instantiating" messages for these new nodes. Those also are numbered
like module nodes and count towards the total.

------

Fixes #17188

Updates hackage submomdule

Metric Increase:
    T12425
    T13035

Previously, we let-bound an identifier to use to carry
the erroring evidence for an out-of-scope variable. But
this failed for levity-polymorphic out-of-scope variables,
leading to a panic (#17812). The new plan is to use
a mutable update to just write the erroring expression directly
where it needs to go.

Close #17812.

Test case: typecheck/should_compile/T17812

In eb629fab I accidentally got rid of it when inlining tons of helpers.

Closes #19004

This patch significantly refactors key renamer datastructures (primarily Avail
and GlobalRdrElt) in order to treat DuplicateRecordFields in a more robust way.
In particular it allows the extension to be used with pattern synonyms (fixes
where mangled record selector names could be printed instead of field labels
(e.g. with -Wpartial-fields or hole fits, see new tests).

The key idea is the introduction of a new type GreName for names that may
represent either normal entities or field labels.  This is then used in
GlobalRdrElt and AvailInfo, in place of the old way of representing fields
using FldParent (yuck) and an extra list in AvailTC.

Updates the haddock submodule.

Fixes #19109.

Given a kind signature

   type T :: forall k. k -> forall k. k -> blah
   data T a b = ...

where those k's have the same unique (which is possible;
see #19093) we were giving the tyConBinders in tycon T the same
unique, which caused chaos.

Fix is simple: ensure uniqueness when decomposing the kind signature.
See GHC.Tc.Gen.HsType.zipBinders

See `Note [Scoping of named wildcards]` in GHC.Hs.Type

This lack of documentation came up in #19051.

Fix #19082, #17045

Consider

```hs
data Ex where
  Ex :: e -> Int -> Ex

f :: Ex -> Int
f (Ex e n) = e `seq` n + 1
```

Worker/wrapper should build the following worker for `f`:

```hs
$wf :: forall e. e -> Int# -> Int#
$wf e n = e `seq` n +# 1#
```

But previously it didn't, because `Ex` binds an existential.
This patch lifts that condition. That entailed having to instantiate
existential binders in `GHC.Core.Opt.WorkWrap.Utils.mkWWstr` via
`GHC.Core.Utils.dataConRepFSInstPat`, requiring a bit of a refactoring
around what is now `DataConPatContext`.

CPR W/W still won't unbox DataCons with existentials.
See `Note [Which types are unboxed?]` for details.

I also refactored the various `tyCon*DataCon(s)_maybe` functions in
`GHC.Core.TyCon`, deleting some of them which are no longer needed
(`isDataProductType_maybe` and `isDataSumType_maybe`).
I cleaned up a couple of call sites, some of which weren't very explicit
about whether they cared for existentials or not.

The test output of `T18013` changed, because we now unbox the `Rule`
data type. Its constructor carries existential state and will be
w/w'd now. In the particular example, the worker functions inlines right
back into the wrapper, which then unnecessarily has a (quite big) stable
unfolding. I think this kind of fallout is inevitable;
see also Note [Don't w/w inline small non-loop-breaker things].

There's a new regression test case `T18982`.
Fixes #18982.

I also took the liberty to refactor the logic around `ruleFVs`.

This gives a small increase in performance under most circumstances.

For single threaded GC the improvement is on the order of 1-2%.

For multi threaded GC the results are quite noisy but seem to
fall into the same ballpark.

Fixes #16499

A workaround for #19099.

Semigroup too of course