| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
Add GHC.Hs module hierarchy replacing hsSyn.
Metric Increase:
haddock.compiler
|
| |
|
|
|
| |
This patch removes 'userHsLTyVarBndrs' and 'userHsTyVarBndrs' from HsUtils.
These helper functions were not used anywhere.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
These kinds of imports are necessary in some cases such as
importing instances of typeclasses or intentionally creating
dependencies in the build system, but '-Wunused-imports' can't
detect when they are no longer needed. This commit removes the
unused ones currently in the code base (not including test files
or submodules), with the hope that doing so may increase
parallelism in the build system by removing unnecessary
dependencies.
|
| |
|
|
|
| |
Previously it was awkwardly in TyCoFVs (and before that in TyCoRep).
Type seems like a sensible place for it to live.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This breaks up the monstrous TyCoReps module into several new modules by
topic:
* TyCoRep: Contains the `Coercion`, `Type`, and related type
definitions and a few simple predicates but nothing further
* TyCoPpr: Contains the the pretty-printer logic
* TyCoFVs: Contains the free variable computations (and
`tyConAppNeedsKindSig`, although I suspect this should change)
* TyCoSubst: Contains the substitution logic for types and coercions
* TyCoTidy: Contains the tidying logic for types
While we are able to eliminate a good number of `SOURCE` imports (and
make a few others smaller) with this change, we must introduce one new
`hs-boot` file for `TyCoPpr` so that `TyCoRep` can define `Outputable`
instances for the types it defines.
Metric Increase:
haddock.Cabal
haddock.compiler
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GHC used to reject programs of this form:
```
newtype Age = MkAge Int
deriving Eq via Const Int a
```
That's because an earlier implementation of `DerivingVia` would
generate the following instance:
```
instance Eq Age where
(==) = coerce @(Const Int a -> Const Int a -> Bool)
@(Age -> Age -> Bool)
(==)
```
Note that the `a` in `Const Int a` is not bound anywhere, which
causes all sorts of issues. I figured that no one would ever want to
write code like this anyway, so I simply banned "floating" `via` type
variables like `a`, checking for their presence in the aptly named
`reportFloatingViaTvs` function.
`reportFloatingViaTvs` ended up being implemented in a subtly
incorrect way, as #15831 demonstrates. Following counsel with the
sage of gold fire, I decided to abandon `reportFloatingViaTvs`
entirely and opt for a different approach that would _accept_
the instance above. This is because GHC now generates this instance
instead:
```
instance forall a. Eq Age where
(==) = coerce @(Const Int a -> Const Int a -> Bool)
@(Age -> Age -> Bool)
(==)
```
Notice that we now explicitly quantify the `a` in
`instance forall a. Eq Age`, so everything is peachy scoping-wise.
See `Note [Floating `via` type variables]` in `TcDeriv` for the full
scoop.
A pleasant benefit of this refactoring is that it made it much easier
to catch the problem observed in #16181, so this patch fixes that
issue too.
Fixes #15831. Fixes #16181.
|
| | |
|
| | |
|
| |
|
|
|
| |
This commit fixes #16874 by using `fsep` rather than `sep` when pretty
printing long patterns and expressions.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To avoid having to `panic` any time a TTG extension constructor is
consumed, this MR introduces an uninhabited 'NoExtCon' type and uses
that in every extension constructor's type family instance where it
is appropriate. This also introduces a 'noExtCon' function which
eliminates a 'NoExtCon', much like 'Data.Void.absurd' eliminates
a 'Void'.
I also renamed the existing `NoExt` type to `NoExtField` to better
distinguish it from `NoExtCon`. Unsurprisingly, there is a lot of
code churn resulting from this.
Bumps the Haddock submodule. Fixes #15247.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GHC Proposal: 0013-unlifted-newtypes.rst
Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/98
Issues: #15219, #1311, #13595, #15883
Implementation Details:
Note [Implementation of UnliftedNewtypes]
Note [Unifying data family kinds]
Note [Compulsory newtype unfolding]
This patch introduces the -XUnliftedNewtypes extension. When this
extension is enabled, GHC drops the restriction that the field in
a newtype must be of kind (TYPE 'LiftedRep). This allows types
like Int# and ByteArray# to be used in a newtype. Additionally,
coerce is made levity-polymorphic so that it can be used with
newtypes over unlifted types.
The bulk of the changes are in TcTyClsDecls.hs. With -XUnliftedNewtypes,
getInitialKind is more liberal, introducing a unification variable to
return the kind (TYPE r0) rather than just returning (TYPE 'LiftedRep).
When kind-checking a data constructor with kcConDecl, we attempt to
unify the kind of a newtype with the kind of its field's type. When
typechecking a data declaration with tcTyClDecl, we again perform a
unification. See the implementation note for more on this.
Co-authored-by: Richard Eisenberg <rae@richarde.dev>
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Associated type family default declarations behave strangely in a
couple of ways:
1. If one tries to bind the type variables with an explicit `forall`,
the `forall`'d part will simply be ignored. (#16110)
2. One cannot use visible kind application syntax on the left-hand
sides of associated default equations, unlike every other form
of type family equation. (#16356)
Both of these issues have a common solution. Instead of using
`LHsQTyVars` to represent the left-hand side arguments of an
associated default equation, we instead use `HsTyPats`, which is what
other forms of type family equations use. In particular, here are
some highlights of this patch:
* `FamEqn` is no longer parameterized by a `pats` type variable, as
the `feqn_pats` field is now always `HsTyPats`.
* The new design for `FamEqn` in chronicled in
`Note [Type family instance declarations in HsSyn]`.
* `TyFamDefltEqn` now becomes the same thing as `TyFamInstEqn`. This
means that many of `TyFamDefltEqn`'s code paths can now reuse the
code paths for `TyFamInstEqn`, resulting in substantial
simplifications to various parts of the code dealing with
associated type family defaults.
Fixes #16110 and #16356.
|
| |
|
|
|
|
|
|
|
|
| |
Most places where we convert contexts in `Convert` are actually in
positions that are to the left of some `=>`, such as in superclasses
and instance contexts. Accordingly, these contexts need to be
parenthesized at `funPrec`. To accomplish this, this patch changes
`cvtContext` to require a precedence argument for the purposes of
calling `parenthesizeHsContext` and adjusts all `cvtContext` call
sites accordingly.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
GHC Proposal #36 describes a transition plan away from CUSKs and to
top-level kind signatures:
1. Introduce a new extension, -XCUSKs, on by default, that detects CUSKs
as they currently exist.
2. We turn off the -XCUSKs extension in a few releases and remove it
sometime thereafter.
This patch implements phase 1 of this plan, introducing a new language
extension to control whether CUSKs are enabled. When top-level kind
signatures are implemented, we can transition to phase 2.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch removes 'EWildPat', 'EAsPat', 'EViewPat', and 'ELazyPat'
from 'HsExpr' by using the ambiguity resolution system introduced
earlier for the command/expression ambiguity.
Problem: there are places in the grammar where we do not know whether we
are parsing an expression or a pattern, for example:
do { Con a b <- x } -- 'Con a b' is a pattern
do { Con a b } -- 'Con a b' is an expression
Until we encounter binding syntax (<-) we don't know whether to parse
'Con a b' as an expression or a pattern.
The old solution was to parse as HsExpr always, and rejig later:
checkPattern :: LHsExpr GhcPs -> P (LPat GhcPs)
This meant polluting 'HsExpr' with pattern-related constructors. In
other words, limitations of the parser were affecting the AST, and all
other code (the renamer, the typechecker) had to deal with these extra
constructors.
We fix this abstraction leak by parsing into an overloaded
representation:
class DisambECP b where ...
newtype ECP = ECP { runECP_PV :: forall b. DisambECP b => PV (Located b) }
See Note [Ambiguous syntactic categories] for details.
Now the intricacies of parsing have no effect on the hsSyn AST when it
comes to the expression/pattern ambiguity.
|
| |
|
|
|
|
|
|
|
| |
Rather than massaging the output of the parser to re-arrange docs and
bangs, it is simpler to patch the two places in which the strictness
info is needed (to accept that the `HsBangTy` may be inside an
`HsDocTy`).
Fixes #16585.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This moves all URL references to Trac Wiki to their corresponding
GitLab counterparts.
This substitution is classified as follows:
1. Automated substitution using sed with Ben's mapping rule [1]
Old: ghc.haskell.org/trac/ghc/wiki/XxxYyy...
New: gitlab.haskell.org/ghc/ghc/wikis/xxx-yyy...
2. Manual substitution for URLs containing `#` index
Old: ghc.haskell.org/trac/ghc/wiki/XxxYyy...#Zzz
New: gitlab.haskell.org/ghc/ghc/wikis/xxx-yyy...#zzz
3. Manual substitution for strings starting with `Commentary`
Old: Commentary/XxxYyy...
New: commentary/xxx-yyy...
See also !539
[1]: https://gitlab.haskell.org/bgamari/gitlab-migration/blob/master/wiki-mapping.json
|
| |
|
|
|
|
| |
!301 removed the `HsArrApp` and `HsArrForm` constructors, which
renders the corresponding extension points `XArrApp` and `XArrForm`
useless. This patch finally rips them out.
|
| | |
|
| |
|
|
|
| |
This moves all URL references to Trac tickets to their corresponding
GitLab counterparts.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this patch GHC was trying to be too clever
(Trac #16344); it succeeded in kind-checking this
polymorphic-recursive declaration
data T ka (a::ka) b
= MkT (T Type Int Bool)
(T (Type -> Type) Maybe Bool)
As Note [No polymorphic recursion] discusses, the "solution" was
horribly fragile. So this patch deletes the key lines in
TcHsType, and a wodge of supporting stuff in the renamer.
There were two regressions, both the same: a closed type family
decl like this (T12785b) does not have a CUSK:
type family Payload (n :: Peano) (s :: HTree n x) where
Payload Z (Point a) = a
Payload (S n) (a `Branch` stru) = a
To kind-check the equations we need a dependent kind for
Payload, and we don't get that any more. Solution: make it
a CUSK by giving the result kind -- probably a good thing anyway.
The other case (T12442) was very similar: a close type family
declaration without a CUSK.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GHC represents String literals as ByteString internally for efficiency
reasons. However, until now it wasn't possible to efficiently create
large string literals with TH (e.g. to embed a file in a binary, cf #14741):
TH code had to unpack the bytes into a [Word8] that GHC then had to re-pack
into a ByteString.
This patch adds the possibility to efficiently create a "string" literal
from raw bytes. We get the following compile times for different sizes
of TH created literals:
|| Size || Before || After || Gain ||
|| 30K || 2.307s || 2.299 || 0% ||
|| 3M || 3.073s || 2.400s || 21% ||
|| 30M || 8.517s || 3.390s || 60% ||
Ticket #14741 can be fixed if the original code uses this new TH feature.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes two rather gnarly test cases:
* Trac #16342 (mutual recursion)
See Note [Tricky scoping in generaliseTcTyCon]
* Trac #16221 (shadowing)
See Note [Unification variables need fresh Names]
The main changes are:
* Substantial reworking of TcTyClsDecls.generaliseTcTyCon
This is the big change, and involves the rather tricky
function TcHsSyn.zonkRecTyVarBndrs.
See Note [Inferring kinds for type declarations] and
Note [Tricky scoping in generaliseTcTyCon] for the details.
* bindExplicitTKBndrs_Tv and bindImplicitTKBndrs_Tv both now
allocate /freshly-named/ unification variables. Indeed, more
generally, unification variables are always fresh; see
Note [Unification variables need fresh Names] in TcMType
* Clarify the role of tcTyConScopedTyVars.
See Note [Scoped tyvars in a TcTyCon] in TyCon
As usual, this dragged in some more refactoring:
* Renamed TcMType.zonkTyCoVarBndr to zonkAndSkolemise
* I renamed checkValidTelescope to checkTyConTelescope;
it's only used on TyCons, and indeed takes a TyCon as argument.
* I folded the slightly-mysterious reportFloatingKvs into
checkTyConTelescope. (Previously all its calls immediately
followed a call to checkTyConTelescope.) It makes much more
sense there.
* I inlined some called-once functions to simplify
checkValidTyFamEqn. It's less spaghetti-like now.
* This patch also fixes Trac #16251. I'm not quite sure why #16251
went wrong in the first place, nor how this patch fixes it, but
hey, it's good, and life is short.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This implements GHC proposal 35
(https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0035-forall-arrow.rst)
by adding the ability to write kinds with
visible dependent quantification (VDQ).
Most of the work for supporting VDQ was actually done _before_ this
patch. That is, GHC has been able to reason about kinds with VDQ for
some time, but it lacked the ability to let programmers directly
write these kinds in the source syntax. This patch is primarly about
exposing this ability, by:
* Changing `HsForAllTy` to add an additional field of type
`ForallVisFlag` to distinguish between invisible `forall`s (i.e,
with dots) and visible `forall`s (i.e., with arrows)
* Changing `Parser.y` accordingly
The rest of the patch mostly concerns adding validity checking to
ensure that VDQ is never used in the type of a term (as permitting
this would require full-spectrum dependent types). This is
accomplished by:
* Adding a `vdqAllowed` predicate to `TcValidity`.
* Introducing `splitLHsSigmaTyInvis`, a variant of `splitLHsSigmaTy`
that only splits invisible `forall`s. This function is used in
certain places (e.g., in instance declarations) to ensure that GHC
doesn't try to split visible `forall`s (e.g., if it tried splitting
`instance forall a -> Show (Blah a)`, then GHC would mistakenly
allow that declaration!)
This also updates Template Haskell by introducing a new `ForallVisT`
constructor to `Type`.
Fixes #16326. Also fixes #15658 by documenting this feature in the
users' guide.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch removes 'HsArrApp' and 'HsArrForm' from 'HsExpr' by
introducing a new ambiguity resolution system in the parser.
Problem: there are places in the grammar where we do not know whether we
are parsing an expression or a command:
proc x -> do { (stuff) -< x } -- 'stuff' is an expression
proc x -> do { (stuff) } -- 'stuff' is a command
Until we encounter arrow syntax (-<) we don't know whether to parse
'stuff' as an expression or a command.
The old solution was to parse as HsExpr always, and rejig later:
checkCommand :: LHsExpr GhcPs -> P (LHsCmd GhcPs)
This meant polluting 'HsExpr' with command-related constructors. In
other words, limitations of the parser were affecting the AST, and
all other code (the renamer, the typechecker) had to deal with these
extra constructors by panicking.
We fix this abstraction leak by parsing into an intermediate
representation, 'ExpCmd':
data ExpCmdG b where
ExpG :: ExpCmdG HsExpr
CmdG :: ExpCmdG HsCmd
type ExpCmd = forall b. ExpCmdG b -> PV (Located (b GhcPs))
checkExp :: ExpCmd -> PV (LHsExpr GhcPs)
checkCmd :: ExpCmd -> PV (LHsCmd GhcPs)
checkExp f = f ExpG -- interpret as an expression
checkCmd f = f CmdG -- interpret as a command
See Note [Ambiguous syntactic categories] for details.
Now the intricacies of parsing have no effect on the hsSyn AST when it
comes to the expression/command ambiguity.
Future work: apply the same principles to the expression/pattern
ambiguity.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The big payload of this patch is:
Add an AnonArgFlag to the FunTy constructor
of Type, so that
(FunTy VisArg t1 t2) means (t1 -> t2)
(FunTy InvisArg t1 t2) means (t1 => t2)
The big payoff is that we have a simple, local test to make
when decomposing a type, leading to many fewer calls to
isPredTy. To me the code seems a lot tidier, and probably
more efficient (isPredTy has to take the kind of the type).
See Note [Function types] in TyCoRep.
There are lots of consequences
* I made FunTy into a record, so that it'll be easier
when we add a linearity field, something that is coming
down the road.
* Lots of code gets touched in a routine way, simply because it
pattern matches on FunTy.
* I wanted to make a pattern synonym for (FunTy2 arg res), which
picks out just the argument and result type from the record. But
alas the pattern-match overlap checker has a heart attack, and
either reports false positives, or takes too long. In the end
I gave up on pattern synonyms.
There's some commented-out code in TyCoRep that shows what I
wanted to do.
* Much more clarity about predicate types, constraint types
and (in particular) equality constraints in kinds. See TyCoRep
Note [Types for coercions, predicates, and evidence]
and Note [Constraints in kinds].
This made me realise that we need an AnonArgFlag on
AnonTCB in a TyConBinder, something that was really plain
wrong before. See TyCon Note [AnonTCB InivsArg]
* When building function types we must know whether we
need VisArg (mkVisFunTy) or InvisArg (mkInvisFunTy).
This turned out to be pretty easy in practice.
* Pretty-printing of types, esp in IfaceType, gets
tidier, because we were already recording the (->)
vs (=>) distinction in an ad-hoc way. Death to
IfaceFunTy.
* mkLamType needs to keep track of whether it is building
(t1 -> t2) or (t1 => t2). See Type
Note [mkLamType: dictionary arguments]
Other minor stuff
* Some tidy-up in validity checking involving constraints;
Trac #16263
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch finally delivers on Trac #15952. Specifically
* Completely remove Note [The tcType invariant], along with
its complicated consequences (IT1-IT6).
* Replace Note [The well-kinded type invariant] with:
Note [The Purely Kinded Type Invariant (PKTI)]
* Instead, establish the (PKTI) in TcHsType.tcInferApps,
by using a new function mkAppTyM when building a type
application. See Note [mkAppTyM].
* As a result we can remove the delicate mkNakedXX functions
entirely. Specifically, mkNakedCastTy retained lots of
extremly delicate Refl coercions which just cluttered
everything up, and(worse) were very vulnerable to being
silently eliminated by (say) substTy. This led to a
succession of bug reports.
The result is noticeably simpler to explain, simpler
to code, and Richard and I are much more confident that
it is correct.
It does not actually fix any bugs, but it brings us closer.
E.g. I hoped it'd fix #15918 and #15799, but it doesn't quite
do so. However, it makes it much easier to fix.
I also did a raft of other minor refactorings:
* Use tcTypeKind consistently in the type checker
* Rename tcInstTyBinders to tcInvisibleTyBinders,
and refactor it a bit
* Refactor tcEqType, pickyEqType, tcEqTypeVis
Simpler, probably more efficient.
* Make zonkTcType zonk TcTyCons, at least if they have
any free unification variables -- see zonk_tc_tycon
in TcMType.zonkTcTypeMapper.
Not zonking these TcTyCons was actually a bug before.
* Simplify try_to_reduce_no_cache in TcFlatten (a lot)
* Combine checkExpectedKind and checkExpectedKindX.
And then combine the invisible-binder instantation code
Much simpler now.
* Fix a little bug in TcMType.skolemiseQuantifiedTyVar.
I'm not sure how I came across this originally.
* Fix a little bug in TyCoRep.isUnliftedRuntimeRep
(the ASSERT was over-zealous). Again I'm not certain
how I encountered this.
* Add a missing solveLocalEqualities in
TcHsType.tcHsPartialSigType.
I came across this when trying to get level numbers
right.
|
| |
|
|
|
|
|
|
|
| |
-Wredundant-record-wildcards warns when a .. pattern binds no variables.
-Wunused-record-wildcards warns when none of the variables bound by a ..
pattern are used.
These flags are enabled by `-Wall`.
|
| |
|
|
|
|
|
|
|
| |
Previously, in getFamDeclInitialKind, we were figuring
out whether the enclosing class decl had a CUSK very
indirectly, via tcTyConIsPoly. This patch just makes
the computation much more direct and easy to grok.
No change in behaviour.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The patch from https://phabricator.haskell.org/D4865 introduces
go _ (HsParTy _ (dL->L l (HsStarTy _ isUni))) acc ann fix
= do { warnStarBndr l
; let name = mkOccName tcClsName (if isUni then "★" else "*")
; return (cL l (Unqual name), acc, fix, ann) }
which discards the parens annotations belonging to the HsParTy.
Updates haddock submodule
Closes #16265
|
| |
|
|
|
|
|
|
|
|
|
|
| |
For the code
type family F1 (a :: k) (f :: k -> Type) :: Type where
F1 @Peano a f = T @Peano f a
the API annotation for the first @ is not attached to a SourceSpan in
the ParsedSource
Closes #16236
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Also used ByteString in some other relevant places
|
| |
|
|
|
|
|
|
|
| |
Trac #16183 was caused by TH conversion (in `Convert`) not properly
inserting parentheses around occurrences of explicit signatures where
appropriate, such as in applications, function types, and type family
equations. Solution: use `parenthesizeHsType sigPrec` in these
places. While I was in town, I also updated `nlHsFunTy` to do the
same thing.
|
| | |
|
| |
|
|
| |
It is correct to be `GhcTc` as the data type is for expressions which are inside splices
so they can be delayed until desugaring.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This fixes #15471
In the typechecker we check that the splice has the right type but we
crucially don't zonk the generated expression. This is because we might
end up unifying type variables from outer scopes later on.
Reviewers: simonpj, goldfire, bgamari
Subscribers: rwbarton, carter
GHC Trac Issues: #15471
Differential Revision: https://phabricator.haskell.org/D5286
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch implements visible kind application (GHC Proposal 15/#12045), as well as #15360 and #15362.
It also refactors unnamed wildcard handling, and requires that type equations in type families in Template Haskell be
written with full type on lhs. PartialTypeSignatures are on and warnings are off automatically with visible kind
application, just like in term-level.
There are a few remaining issues with this patch, as documented in
ticket #16082.
Includes a submodule update for Haddock.
Test Plan: Tests T12045a/b/c/TH1/TH2, T15362, T15592a
Reviewers: simonpj, goldfire, bgamari, alanz, RyanGlScott, Iceland_jack
Subscribers: ningning, Iceland_jack, RyanGlScott, int-index, rwbarton, mpickering, carter
GHC Trac Issues: `#12045`, `#15362`, `#15592`, `#15788`, `#15793`, `#15795`, `#15797`, `#15799`, `#15801`, `#15807`, `#15816`
Differential Revision: https://phabricator.haskell.org/D5229
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
See #8959, this is one more place where we
can pretty-print Unicode syntax.
Test Plan: validate
Reviewers: nomeata, bgamari
Reviewed By: bgamari
Subscribers: rwbarton, carter
GHC Trac Issues: #8959
Differential Revision: https://phabricator.haskell.org/D5439
|
