[Git][ghc/ghc][wip/js-mkdir] 16 commits: Major refactor in the handling of equality constraints
Josh Meredith (@JoshMeredith)
gitlab at gitlab.haskell.org
Thu Apr 20 17:12:31 UTC 2023
Josh Meredith pushed to branch wip/js-mkdir at Glasgow Haskell Compiler / GHC
Commits:
2371d6b2 by Simon Peyton Jones at 2023-04-14T20:01:02+02:00
Major refactor in the handling of equality constraints
This MR substantially refactors the way in which the constraint
solver deals with equality constraints. The big thing is:
* Intead of a pipeline in which we /first/ canonicalise and /then/
interact (the latter including performing unification) the two steps
are more closely integreated into one. That avoids the current
rather indirect communication between the two steps.
The proximate cause for this refactoring is fixing #22194, which involve
solving [W] alpha[2] ~ Maybe (F beta[4])
by doing this:
alpha[2] := Maybe delta[2]
[W] delta[2] ~ F beta[4]
That is, we don't promote beta[4]! This is very like introducing a cycle
breaker, and was very awkward to do before, but now it is all nice.
See GHC.Tc.Utils.Unify Note [Promotion and level-checking] and
Note [Family applications in canonical constraints].
The big change is this:
* Several canonicalisation checks (occurs-check, cycle-breaking,
checking for concreteness) are combined into one new function:
GHC.Tc.Utils.Unify.checkTyEqRhs
This function is controlled by `TyEqFlags`, which says what to do
for foralls, type families etc.
* `canEqCanLHSFinish` now sees if unification is possible, and if so,
actually does it: see `canEqCanLHSFinish_try_unification`.
There are loads of smaller changes:
* The on-the-fly unifier `GHC.Tc.Utils.Unify.unifyType` has a
cheap-and-cheerful version of `checkTyEqRhs`, called
`simpleUnifyCheck`. If `simpleUnifyCheck` succeeds, it can unify,
otherwise it defers by emitting a constraint. This is simpler than
before.
* I simplified the swapping code in `GHC.Tc.Solver.Equality.canEqCanLHS`.
Especially the nasty stuff involving `swap_for_occurs` and
`canEqTyVarFunEq`. Much nicer now. See
Note [Orienting TyVarLHS/TyFamLHS]
Note [Orienting TyFamLHS/TyFamLHS]
* Added `cteSkolemOccurs`, `cteConcrete`, and `cteCoercionHole` to the
problems that can be discovered by `checkTyEqRhs`.
* I fixed #23199 `pickQuantifiablePreds`, which actually allows GHC to
to accept both cases in #22194 rather than rejecting both.
Yet smaller:
* Added a `synIsConcrete` flag to `SynonymTyCon` (alongside `synIsFamFree`)
to reduce the need for synonym expansion when checking concreteness.
Use it in `isConcreteType`.
* Renamed `isConcrete` to `isConcreteType`
* Defined `GHC.Core.TyCo.FVs.isInjectiveInType` as a more efficient
way to find if a particular type variable is used injectively than
finding all the injective variables. It is called in
`GHC.Tc.Utils.Unify.definitely_poly`, which in turn is used quite a
lot.
* Moved `rewriterView` to `GHC.Core.Type`, so we can use it from the
constraint solver.
Fixes #22194, #23199
Compile times decrease by an average of 0.1%; but there is a 7.4%
drop in compiler allocation on T15703.
Metric Decrease:
T15703
- - - - -
99b2734b by Simon Peyton Jones at 2023-04-14T20:01:02+02:00
Add some documentation about redundant constraints
- - - - -
3f2d0eb8 by Simon Peyton Jones at 2023-04-14T20:01:02+02:00
Improve partial signatures
This MR fixes #23223. The changes are in two places:
* GHC.Tc.Bind.checkMonomorphismRestriction
See the new `Note [When the MR applies]`
We now no longer stupidly attempt to apply the MR when the user
specifies a context, e.g. f :: Eq a => _ -> _
* GHC.Tc.Solver.decideQuantification
See rewritten `Note [Constraints in partial type signatures]`
Fixing this bug apparently breaks three tests:
* partial-sigs/should_compile/T11192
* partial-sigs/should_fail/Defaulting1MROff
* partial-sigs/should_fail/T11122
However they are all symptoms of #23232, so I'm marking them as
expect_broken(23232).
I feel happy about this MR. Nice.
- - - - -
23e2a8a0 by Simon Peyton Jones at 2023-04-14T20:01:02+02:00
Make approximateWC a bit cleverer
This MR fixes #23224: making approximateWC more clever
See the long `Note [ApproximateWC]` in GHC.Tc.Solver
All this is delicate and ad-hoc -- but it /has/ to be: we are
talking about inferring a type for a binding in the presence of
GADTs, type families and whatnot: known difficult territory.
We just try as hard as we can.
- - - - -
2c040246 by Matthew Pickering at 2023-04-15T00:57:14-04:00
docs: Update template-haskell docs to use Code Q a rather than Q (TExp a)
Since GHC Proposal #195, the type of [|| ... ||] has been Code Q a
rather than Q (TExp a). The documentation in the `template-haskell`
library wasn't updated to reflect this change.
Fixes #23148
- - - - -
0da18eb7 by Krzysztof Gogolewski at 2023-04-15T14:35:53+02:00
Show an error when we cannot default a concrete tyvar
Fixes #23153
- - - - -
bad2f8b8 by sheaf at 2023-04-15T15:14:36+02:00
Handle ConcreteTvs in inferResultToType
inferResultToType was discarding the ir_frr information, which meant
some metavariables ended up being MetaTvs instead of ConcreteTvs.
This function now creates new ConcreteTvs as necessary, instead of
always creating MetaTvs.
Fixes #23154
- - - - -
3b0ea480 by Simon Peyton Jones at 2023-04-16T18:12:20-04:00
Transfer DFunId_ness onto specialised bindings
Whether a binding is a DFunId or not has consequences for the `-fdicts-strict`
flag, essentially if we are doing demand analysis for a DFunId then `-fdicts-strict` does
not apply because the constraint solver can create recursive groups of dictionaries.
In #22549 this was fixed for the "normal" case, see
Note [Do not strictify the argument dictionaries of a dfun].
However the loop still existed if the DFunId was being specialised.
The problem was that the specialiser would specialise a DFunId and
turn it into a VanillaId and so the demand analyser didn't know to
apply special treatment to the binding anymore and the whole recursive
group was optimised to bottom.
The solution is to transfer over the DFunId-ness of the binding in the specialiser so
that the demand analyser knows not to apply the `-fstrict-dicts`.
Fixes #22549
- - - - -
a1371ebb by Oleg Grenrus at 2023-04-16T18:12:59-04:00
Add import lists to few GHC.Driver.Session imports
Related to https://gitlab.haskell.org/ghc/ghc/-/issues/23261.
There are a lot of GHC.Driver.Session which only use DynFlags,
but not the parsing code.
- - - - -
51479ceb by Matthew Pickering at 2023-04-17T08:08:48-04:00
Account for special GHC.Prim import in warnUnusedPackages
The GHC.Prim import is treated quite specially primarily because there
isn't an interface file for GHC.Prim. Therefore we record separately in
the ModSummary if it's imported or not so we don't go looking for it.
This logic hasn't made it's way to `-Wunused-packages` so if you
imported GHC.Prim then the warning would complain you didn't use
`-package ghc-prim`.
Fixes #23212
- - - - -
1532a8b2 by Simon Peyton Jones at 2023-04-17T08:09:24-04:00
Add regression test for #23199
- - - - -
0158c5f1 by Ryan Scott at 2023-04-17T18:43:27-04:00
validDerivPred: Reject exotic constraints in IrredPreds
This brings the `IrredPred` case in sync with the treatment of `ClassPred`s as
described in `Note [Valid 'deriving' predicate]` in `GHC.Tc.Validity`. Namely,
we should reject `IrredPred`s that are inferred from `deriving` clauses whose
arguments contain other type constructors, as described in `(VD2) Reject exotic
constraints` of that Note. This has the nice property that `deriving` clauses
whose inferred instance context mention `TypeError` will now emit the type
error in the resulting error message, which better matches existing intuitions
about how `TypeError` should work.
While I was in town, I noticed that much of `Note [Valid 'deriving' predicate]`
was duplicated in a separate `Note [Exotic derived instance contexts]` in
`GHC.Tc.Deriv.Infer`. I decided to fold the latter Note into the former so that
there is a single authority on describing the conditions under which an
inferred `deriving` constraint can be considered valid.
This changes the behavior of `deriving` in a way that existing code might
break, so I have made a mention of this in the GHC User's Guide. It seems very,
very unlikely that much code is relying on this strange behavior, however, and
even if there is, there is a clear, backwards-compatible migration path using
`StandaloneDeriving`.
Fixes #22696.
- - - - -
10364818 by Krzysztof Gogolewski at 2023-04-17T18:44:03-04:00
Misc cleanup
- Use dedicated list functions
- Make cloneBndrs and cloneRecIdBndrs monadic
- Fix invalid haddock comments in libraries/base
- - - - -
5e1d33d7 by Matthew Pickering at 2023-04-18T10:31:02-04:00
Convert interface file loading errors into proper diagnostics
This patch converts all the errors to do with loading interface files
into proper structured diagnostics.
* DriverMessage: Sometimes in the driver we attempt to load an interface
file so we embed the IfaceMessage into the DriverMessage.
* TcRnMessage: Most the time we are loading interface files during
typechecking, so we embed the IfaceMessage
This patch also removes the TcRnInterfaceLookupError constructor which
is superceded by the IfaceMessage, which is now structured compared to
just storing an SDoc before.
- - - - -
df1a5811 by sheaf at 2023-04-18T10:31:43-04:00
Don't panic in ltPatersonSize
The function GHC.Tc.Utils.TcType.ltPatersonSize would panic when it
encountered a type family on the RHS, as usually these are not allowed
(type families are not allowed on the RHS of class instances or of
quantified constraints). However, it is possible to still encounter
type families on the RHS after doing a bit of constraint solving, as
seen in test case T23171. This could trigger the panic in the call to
ltPatersonSize in GHC.Tc.Solver.Canonical.mk_strict_superclasses, which
is involved in avoiding loopy superclass constraints.
This patch simply changes ltPatersonSize to return "I don't know, because
there's a type family involved" in these cases.
Fixes #23171
- - - - -
830d1c3c by Josh Meredith at 2023-04-20T17:12:17+00:00
JS/base: provide implementation for mkdir (issue 22374)
- - - - -
30 changed files:
- compiler/GHC/CmmToAsm/X86/CodeGen.hs
- compiler/GHC/Core/Make.hs
- compiler/GHC/Core/Opt/SetLevels.hs
- compiler/GHC/Core/Opt/Simplify/Iteration.hs
- compiler/GHC/Core/Opt/Specialise.hs
- compiler/GHC/Core/Opt/WorkWrap/Utils.hs
- compiler/GHC/Core/Subst.hs
- compiler/GHC/Core/TyCo/FVs.hs
- compiler/GHC/Core/TyCo/Rep.hs
- compiler/GHC/Core/TyCon.hs
- compiler/GHC/Core/Type.hs
- compiler/GHC/Core/Type.hs-boot
- compiler/GHC/Data/Bag.hs
- compiler/GHC/Data/Maybe.hs
- compiler/GHC/Driver/Config/Diagnostic.hs
- compiler/GHC/Driver/Config/Tidy.hs
- compiler/GHC/Driver/Errors.hs
- compiler/GHC/Driver/Errors/Ppr.hs
- compiler/GHC/Driver/Errors/Types.hs
- compiler/GHC/Driver/Make.hs
- compiler/GHC/Driver/MakeFile.hs
- compiler/GHC/Hs/Expr.hs
- compiler/GHC/Hs/Pat.hs
- compiler/GHC/HsToCore/Errors/Types.hs
- compiler/GHC/Iface/Errors.hs
- + compiler/GHC/Iface/Errors/Ppr.hs
- + compiler/GHC/Iface/Errors/Types.hs
- compiler/GHC/Iface/Load.hs
- compiler/GHC/Iface/Recomp.hs
- compiler/GHC/IfaceToCore.hs
The diff was not included because it is too large.
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/0bc332e84ebb97effc0e35d48c604704d51ff32f...830d1c3cd72d4e86a520ad1d86eac341b02a9f95
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/0bc332e84ebb97effc0e35d48c604704d51ff32f...830d1c3cd72d4e86a520ad1d86eac341b02a9f95
You're receiving this email because of your account on gitlab.haskell.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-commits/attachments/20230420/6bd5664f/attachment-0001.html>
More information about the ghc-commits
mailing list