| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
From the notes.ghc.drop list found using weeder in #17713
|
| |
|
|
|
|
| |
Update haddock submodule
|
|
|
|
| |
submodule updates: nofib, haddock
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The reasons for that can be found in the wiki:
https://gitlab.haskell.org/ghc/ghc/wikis/nested-cpr/split-off-cpr
We now run CPR after demand analysis (except for after the final demand
analysis run just before code gen). CPR got its own dump flags
(`-ddump-cpr-anal`, `-ddump-cpr-signatures`), but not its own flag to
activate/deactivate. It will run with `-fstrictness`/`-fworker-wrapper`.
As explained on the wiki page, this step is necessary for a sane Nested
CPR analysis. And it has quite positive impact on compiler performance:
Metric Decrease:
T9233
T9675
T9961
T15263
|
| |
|
|
|
|
|
|
| |
incomplete-uni-patterns and incomplete-record-updates will be in -Wall at a
future date, so prepare for that by disabling those warnings on files that
trigger them.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Add 'dumpAction' hook to DynFlags.
It allows GHC API users to catch dumped intermediate codes and
information. The format of the dump (Core, Stg, raw text, etc.) is now
reported allowing easier automatic handling.
* Add 'traceAction' hook to DynFlags.
Some dumps go through the trace mechanism (for instance unfoldings that
have been considered for inlining). This is problematic because:
1) dumps aren't written into files even with -ddump-to-file on
2) dumps are written on stdout even with GHC API
3) in this specific case, dumping depends on unsafe globally stored
DynFlags which is bad for GHC API users
We introduce 'traceAction' hook which allows GHC API to catch those
traces and to avoid using globally stored DynFlags.
* Avoid dumping empty logs via dumpAction/traceAction (but still write
empty files to keep the existing behavior)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This does two things:
* Eliminate all uses of Unique.deriveUnique, which was quite easy to
mis-use and extremely subtle.
* Rename the previous "derived unique" notion to "local unique". This
is possible because the only places where `uniqAway` can be safely
used are those where local uniqueness (with respect to some
InScopeSet) is sufficient.
* Rework the implementation of VarEnv.uniqAway, as discussed in #17462.
This should make the operation significantly more efficient than its
previous iterative implementation..
Metric Decrease:
T9872c
T12227
T9233
T14683
T5030
T12545
hie002
Metric Increase:
T9961
|
|
|
|
|
|
| |
This relied on deriveUnique, which was far too subtle to be safely
applied. Thankfully the instance doesn't appear to be used so let's just
drop it.
|
|
|
|
|
| |
Metric Decrease:
T14683
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
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 moves all URL references to Trac tickets to their corresponding
GitLab counterparts.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This removes the last direct import from simplCore/
to typechecker/.
Test Plan: validate
Reviewers: nomeata, simonpj, bgamari
Reviewed By: simonpj
Subscribers: rwbarton, carter
GHC Trac Issues: #14391
Differential Revision: https://phabricator.haskell.org/D5139
|
|
|
|
|
|
|
|
|
|
|
|
| |
I wondered if some transformations (ticks) might be "innocuous",
in the sense that they do not unlock a later transformation that
does not occur in the same pass. If so, we could refrain from
bumping the overall tick-count for such innocuous transformations,
and perhaps terminate the simplifier one pass earlier.
BUt alas I found that virtually nothing was innocuous! This
commit just adds a Note to record what I learned, in case
anyone wants to try again.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Poor DPH and its vectoriser have long been languishing; sadly it seems there is
little chance that the effort will be rekindled. Every few years we discuss
what to do with this mass of code and at least once we have agreed that it
should be archived on a branch and removed from `master`. Here we do just that,
eliminating heaps of dead code in the process.
Here we drop the ParallelArrays extension, the vectoriser, and the `vector` and
`primitive` submodules.
Test Plan: Validate
Reviewers: simonpj, simonmar, hvr, goldfire, alanz
Reviewed By: simonmar
Subscribers: goldfire, rwbarton, thomie, mpickering, carter
Differential Revision: https://phabricator.haskell.org/D4761
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch implements the API proposed as pull request #108 for plugin
authors to influence the recompilation checker.
It adds a new field to a plugin which computes a `FingerPrint`. This is
recorded in interface files and if it changes then we recompile the
module. There are also helper functions such as `purePlugin` and
`impurePlugin` for constructing plugins which have simple recompilation
semantics but in general, an author can compute a hash as they wish.
Fixes #12567 and #7414
https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/002
2-plugin-recompilation.rst
Reviewers: bgamari, ggreif
Reviewed By: bgamari
Subscribers: rwbarton, thomie, carter
GHC Trac Issues: #7414, #12567
Differential Revision: https://phabricator.haskell.org/D4366
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Simplifier depends on typechecker in two points: `thNameToGhcName`
(`lookupThName_maybe`, in particular) and `lookupGlobal`. We want to
cut the ties in two steps.
1. (Presented in this commit), reimplement both functions in a way that
doesn't use typechecker.
2. (Should follow), do code moving: a) `lookupGlobal` should go in some
typechecker-free place; b) `thNameToGhcName` should leave simplifier,
because it is not used there at all (probably, it should be placed
somewhere where `GhcPlugins` can see it -- this is suggested by Joachim
on Trac).
Details
=======
We redesigned lookup interface a bit so that it exposes some
`IO`-equivalents of `Tc`-features in use.
First, `CoreMonad.hs` still calls `lookupGlobal` which is no longer
bound to the typechecker monad, but still resides in `TcEnv.hs` — it
should be moved out of Tc-land at some point (“Phase 2”) in the
future in order to achieve its part of the #14391's goal.
Second, `lookupThName_maybe` is eliminated from `CoreMonad.hs`
completely; this already achieves its part of the goal of #14391. Its
client, though, `thNameToGhcName`, is better to be moved in the future
also, for it is not used in the `CoreMonad.hs` (or anywhere else)
anyway. Joachim suggested “any module reexported by GhcPlugins (or
maybe even that module itself)”.
As a side goal, we removed `initTcForLookup` which was instrumental for
the past version of `lookupGlobal`. This, in turn, called for pushing
some more parts of the lookup interface from the `Tc`-monad to `IO`,
most notably, adding `IO`-version of `lookupOrig` and pushing
`dataConInfoPtrToName` to `IO`. The `lookupOrig` part, in turn,
triggered a slight redesign of name cache updating interface: we now
have both, `updNameCacheIO` and `updNameCacheTc`, both accepting `mod`
and `occ` to force them inside, instead of more error-prone outside
before. But all these hardly have to do anything with #14391, mere
refactoring.
Reviewers: simonpj, nomeata, bgamari, hvr
Reviewed By: simonpj, bgamari
Subscribers: rwbarton, thomie, carter
GHC Trac Issues: #14391
Differential Revision: https://phabricator.haskell.org/D4503
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The idea is described in #14152, and can be summarized: Float the exit
path out of a joinrec, so that the simplifier can do more with it.
See the test case for a nice example.
The floating goes against what the simplifier usually does, hence we
need to be careful not inline them back.
The position of exitification in the pipeline was chosen after a small
amount of experimentation, but may need to be improved. For example,
exitification can allow rewrite rules to fire, but for that it would
have to happen before the `simpl_phases`.
Perf.haskell.org reports these nice performance wins:
Nofib allocations
fannkuch-redux 78446640 - 99.92% 64560
k-nucleotide 109466384 - 91.32% 9502040
simple 72424696 - 5.96% 68109560
Nofib instruction counts
fannkuch-redux 1744331636 - 3.86% 1676999519
k-nucleotide 2318221965 - 6.30% 2172067260
scs 1978470869 - 3.35% 1912263779
simple 669858104 - 3.38% 647206739
spectral-norm 186423292 - 5.37% 176411536
Differential Revision: https://phabricator.haskell.org/D3903
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This switches the compiler/ component to get compiled with
-XNoImplicitPrelude and a `import GhcPrelude` is inserted in all
modules.
This is motivated by the upcoming "Prelude" re-export of
`Semigroup((<>))` which would cause lots of name clashes in every
modulewhich imports also `Outputable`
Reviewers: austin, goldfire, bgamari, alanz, simonmar
Reviewed By: bgamari
Subscribers: goldfire, rwbarton, thomie, mpickering, bgamari
Differential Revision: https://phabricator.haskell.org/D3989
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We pretty-print a type by converting it to an IfaceType and
pretty-printing that. But
(a) that's a bit indirect, and
(b) delibrately loses information about (e.g.) the kind
on the /occurrences/ of a type variable
So this patch implements debugPprType, which pretty prints
the type directly, with no fancy formatting. It's just used
for debugging.
I took the opportunity to refactor the debug-pretty-printing
machinery a little. In particular, define these functions
and use them:
ifPprDeubug :: SDoc -> SDOc -> SDoc
-- Says what to do with and without -dppr-debug
whenPprDebug :: SDoc -> SDoc
-- Says what to do with -dppr-debug; without is empty
getPprDebug :: (Bool -> SDoc) -> SDoc
getPprDebug used to be called sdocPprDebugWith
whenPprDebug used to be called ifPprDebug
So a lot of files get touched in a very mechanical way
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Triggered by #12150, and the knock-on effects of join points, I did a
major refactoring of the Simplifier. This is a big patch that change
a lot of Simplify.hs: I did a lot of other re-organisation.
The main event
~~~~~~~~~~~~~~
Since the dawn of time we have had
simplExpr :: SimplEnv -> InExpr -> SimplCont
-> SimplM (SimplEnv, OutExpr)
What's that SimplEnv in the result? When simplifying an expression the
simplifier add floated let-bindings to the SimplEnv, extending the
in-scope set appropriately, and hence needs to resturn the SimplEnv at
the end. The mode, flags, substitution in the returned SimplEnv were
all irrelevant: it was just the floating bindings.
It's strange to accumulate part of the /result/ in the /environment/
argument! And indeed its leads to all manner of mysterious calls to
zapFloats and transferring of floats from one SimplEnv to another.
It got worse with join points, so I finally bit the bullet and refactored.
Now we have
simplExpr :: SimplEnv -> InExpr -> SimplCont
-> SimplM (SimplFloats, OutExpr)
-- See Note [The big picture]
and the SimplEnv no longer has floats in it. The code is no shorter,
but it /is/ easier to understand.
Main changes
* Remove seLetFloats field from SimplEnv
* Define new data type SimplFloats, and functions over it
* Change the types of simplExpr, simplBind, and their many variants,
to follow the above plan
Bottoming bindings
~~~~~~~~~~~~~~~~~~
I made one other significant change in SimplUtils (not just refactoring),
related to Trac #12150 comment:16. Given
x = <rhs>
where <rhs> turns out to be a bottoming expression, propagate that
information to x's IdInfo immediately. That's always good, because
it makes x be inlined less (we don't inline bottoming things), and
it allows (case x of ...) to drop the dead alterantives immediately.
Moreover, we are doing the analysis anyway, in tryEtaExpandRhs, which
calls CoreArity.findRhsArity, which already does simple bottom analysis.
So we are generating the information; all we need do is to atach the
bottoming info to the IdInfo.
See Note [Bottoming bindings]
Smaller refactoring
~~~~~~~~~~~~~~~~~~~
* Rename SimplifierMode to SimplMode
* Put DynFlags as a new field in SimplMode, to make fewer
monadic calls to getDynFlags.
* Move the code in addPolyBind into abstractFloats
* Move the "don't eta-expand join points" into tryEtaExpandRhs
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This factors out the repetition of (log_action dflags dflags) and will
hopefully allow us to someday better abstract log output.
Test Plan: Validate
Reviewers: austin, hvr, goldfire
Subscribers: rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D3334
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: austin, bgamari
Reviewed By: bgamari
Subscribers: rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D3320
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use strict `unionWith` where apparently appropriate, and use
strict `insertWith` rather than lookup followed by insertion.
Reviewers: austin, bgamari
Reviewed By: bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D3099
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch converts the 4 lasting static flags (read from the command
line and unsafely stored in immutable global variables) into dynamic
flags. Most use cases have been converted into reading them from a DynFlags.
In cases for which we don't have easy access to a DynFlags, we read from
'unsafeGlobalDynFlags' that is set at the beginning of each 'runGhc'.
It's not perfect (not thread-safe) but it is still better as we can
set/unset these 4 flags before each run when using GHC API.
Updates haddock submodule.
Rebased and finished by: bgamari
Test Plan: validate
Reviewers: goldfire, erikd, hvr, austin, simonmar, bgamari
Reviewed By: simonmar
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2839
GHC Trac Issues: #8440
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This major patch implements Join Points, as described in
https://ghc.haskell.org/trac/ghc/wiki/SequentCore. You have
to read that page, and especially the paper it links to, to
understand what's going on; but it is very cool.
It's Luke Maurer's work, but done in close collaboration with Simon PJ.
This Phab is a squash-merge of wip/join-points branch of
http://github.com/lukemaurer/ghc. There are many, many interdependent
changes.
Reviewers: goldfire, mpickering, bgamari, simonmar, dfeuer, austin
Subscribers: simonpj, dfeuer, mpickering, Mikolaj, thomie
Differential Revision: https://phabricator.haskell.org/D2853
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Now that we have -fexternal-interpreter, we can lose most of the GHCI ifdefs.
This was originally added in https://phabricator.haskell.org/D2826
but that led to a compatibility issue with ghc 7.10.x on Windows.
That's fixed here and the revert reverted.
Reviewers: goldfire, hvr, austin, bgamari, Phyx
Reviewed By: Phyx
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2884
GHC Trac Issues: #13008
|
|
|
|
| |
This reverts commit 52ba9470a7e85d025dc84a6789aa809cdd68b566.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that we have -fexternal-interpreter, we can lose most of the GHCI ifdefs.
Reviewers: simonmar, goldfire, austin, hvr, bgamari
Reviewed By: simonmar
Subscribers: RyanGlScott, mpickering, angerman, thomie
Differential Revision: https://phabricator.haskell.org/D2826
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The use of globals is quite painful when multiple rts are loaded, e.g.
when plugins are loaded, which bring in a second rts. The sharedCAF
appraoch was employed for the FastStringTable; I've taken the libery
to extend this to the other globals I could find.
This is a reboot of D2575, that should hopefully not exhibit the same
windows build issues.
Reviewers: Phyx, simonmar, goldfire, bgamari, austin, hvr, erikd
Reviewed By: Phyx, simonmar, bgamari
Subscribers: mpickering, thomie
Differential Revision: https://phabricator.haskell.org/D2773
|
|
|
|
|
| |
This reverts commit 6f7ed1e51bf360621a3c2a447045ab3012f68575 due to breakage of
the build on Windows.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The use of globals is quite painful when multiple rts are loaded, e.g.
when plugins are loaded, which bring in a second rts. The sharedCAF
appraoch was employed for the FastStringTable; I've taken the libery
to extend this to the other globals I could find.
Reviewers: rwbarton, simonmar, austin, hvr, erikd, bgamari
Reviewed By: simonmar, bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2575
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously BinIface had some dedicated logic for handling tuple names in
the symbol table. As it turns out, this logic was essentially dead code
as it was superceded by the special handling of known-key things. Here
we cull the tuple code-path and use the known-key codepath for all
tuple-ish things.
This had a surprising number of knock-on effects,
* constraint tuple datacons had to be made known-key (previously they
were not)
* IfaceTopBndr was changed from being a synonym of OccName to a
synonym of Name (since we now need to be able to deserialize Names
directly from interface files)
* the change to IfaceTopBndr complicated fingerprinting, since we need
to ensure that we don't go looking for the fingerprint of the thing
we are currently fingerprinting in the fingerprint environment (see
notes in MkIface). Handling this required distinguishing between
binding and non-binding Name occurrences in the Binary serializers.
* the original name cache logic which previously lived in IfaceEnv has
been moved to a new NameCache module
* I ripped tuples and sums out of knownKeyNames since they introduce a
very large number of entries. During interface file deserialization
we use static functions (defined in the new KnownUniques module) to
map from a Unique to a known-key Name (the Unique better correspond
to a known-key name!) When we need to do an original name cache
lookup we rely on the parser implemented in isBuiltInOcc_maybe.
* HscMain.allKnownKeyNames was folded into PrelInfo.knownKeyNames.
* Lots of comments were sprinkled about describing the new scheme.
Updates haddock submodule.
Test Plan: Validate
Reviewers: niteria, simonpj, austin, hvr
Reviewed By: simonpj
Subscribers: simonmar, niteria, thomie
Differential Revision: https://phabricator.haskell.org/D2467
GHC Trac Issues: #12532, #12415
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
With this patch closed variables are allowed regardless of whether
they are bound at the top level or not.
The FloatOut pass is always performed. When optimizations are
disabled, only expressions that go to the top level are floated.
Thus, the applications of the StaticPtr data constructor are always
floated.
The CoreTidy pass makes sure the floated applications appear in the
symbol table of object files. It also collects the floated bindings
and inserts them in the static pointer table.
The renamer does not check anymore if free variables appearing in the
static form are top-level. Instead, the typechecker looks at the
tct_closed flag to decide if the free variables are closed.
The linter checks that applications of StaticPtr only occur at the
top of top-level bindings after the FloatOut pass.
The field spInfoName of StaticPtrInfo has been removed. It used to
contain the name of the top-level binding that contains the StaticPtr
application. However, this information is no longer available when the
StaticPtr is constructed, as the binding name is determined now by the
FloatOut pass.
Test Plan: ./validate
Reviewers: goldfire, simonpj, austin, hvr, bgamari
Reviewed By: simonpj
Subscribers: thomie, mpickering, mboes
Differential Revision: https://phabricator.haskell.org/D2104
GHC Trac Issues: #11656
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Both gcc and clang tell which warning flag a reported warning can be
controlled with, this patch makes ghc do the same. More generally, this
allows for annotated compiler output, where an optional annotation is
displayed in brackets after the severity.
This also adds a new flag `-f(no-)show-warning-groups` to control
whether to show which warning-group (such as `-Wall` or `-Wcompat`)
a warning belongs to. This flag is on by default.
This implements #10752
Reviewed By: quchen, bgamari, hvr
Differential Revision: https://phabricator.haskell.org/D1943
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In the past the canonical way for constructing an SDoc string literal was the
composition `ptext . sLit`. But for some time now we have function `text` that
does the same. Plus it has some rules that optimize its runtime behaviour.
This patch takes all uses of `ptext . sLit` in the compiler and replaces them
with calls to `text`. The main benefits of this patch are clener (shorter) code
and less dependencies between module, because many modules now do not need to
import `FastString`. I don't expect any performance benefits - we mostly use
SDocs to report errors and it seems there is little to be gained here.
Test Plan: ./validate
Reviewers: bgamari, austin, goldfire, hvr, alanz
Subscribers: goldfire, thomie, mpickering
Differential Revision: https://phabricator.haskell.org/D1784
|
|
|
|
|
|
|
| |
This refactoring exploits the fact that since AMP, in most cases,
`instance MonadPlus` can be automatically derived from the respective
`Alternative` instance. This is because `MonadPlus`'s default method
implementations are fully defined in terms of `Alternative(empty, (<>))`.
|
|
|
|
|
|
| |
Starting with GHC 7.10 and base-4.8, `Monad` implies `Applicative`,
which allows to simplify some definitions to exploit the superclass
relationship. This a first refactoring to that end.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This implements the ideas originally put forward in
"System FC with Explicit Kind Equality" (ICFP'13).
There are several noteworthy changes with this patch:
* We now have casts in types. These change the kind
of a type. See new constructor `CastTy`.
* All types and all constructors can be promoted.
This includes GADT constructors. GADT pattern matches
take place in type family equations. In Core,
types can now be applied to coercions via the
`CoercionTy` constructor.
* Coercions can now be heterogeneous, relating types
of different kinds. A coercion proving `t1 :: k1 ~ t2 :: k2`
proves both that `t1` and `t2` are the same and also that
`k1` and `k2` are the same.
* The `Coercion` type has been significantly enhanced.
The documentation in `docs/core-spec/core-spec.pdf` reflects
the new reality.
* The type of `*` is now `*`. No more `BOX`.
* Users can write explicit kind variables in their code,
anywhere they can write type variables. For backward compatibility,
automatic inference of kind-variable binding is still permitted.
* The new extension `TypeInType` turns on the new user-facing
features.
* Type families and synonyms are now promoted to kinds. This causes
trouble with parsing `*`, leading to the somewhat awkward new
`HsAppsTy` constructor for `HsType`. This is dispatched with in
the renamer, where the kind `*` can be told apart from a
type-level multiplication operator. Without `-XTypeInType` the
old behavior persists. With `-XTypeInType`, you need to import
`Data.Kind` to get `*`, also known as `Type`.
* The kind-checking algorithms in TcHsType have been significantly
rewritten to allow for enhanced kinds.
* The new features are still quite experimental and may be in flux.
* TODO: Several open tickets: #11195, #11196, #11197, #11198, #11203.
* TODO: Update user manual.
Tickets addressed: #9017, #9173, #7961, #10524, #8566, #11142.
Updates Haddock submodule.
|