1 {-# LANGUAGE CPP, ViewPatterns, BangPatterns #-}
3 module TcFlatten(
4 FlattenMode(..),
5 flatten, flattenKind, flattenArgsNom,
7 unflattenWanteds
8 ) where
10 #include "HsVersions.h"
12 import GhcPrelude
14 import TcRnTypes
15 import TcType
16 import Type
17 import TcEvidence
18 import TyCon
19 import TyCoRep -- performs delicate algorithm on types
20 import Coercion
21 import Var
22 import VarSet
23 import VarEnv
24 import Outputable
26 import BasicTypes( SwapFlag(..) )
28 import Pair
29 import Util
30 import Bag
33 import Control.Arrow ( first )
35 {-
36 Note [The flattening story]
37 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
38 * A CFunEqCan is either of form
39 [G] <F xis> : F xis ~ fsk -- fsk is a FlatSkolTv
40 [W] x : F xis ~ fmv -- fmv is a FlatMetaTv
41 where
42 x is the witness variable
43 xis are function-free
44 fsk/fmv is a flatten skolem;
45 it is always untouchable (level 0)
47 * CFunEqCans can have any flavour: [G], [W], [WD] or [D]
49 * KEY INSIGHTS:
51 - A given flatten-skolem, fsk, is known a-priori to be equal to
52 F xis (the LHS), with <F xis> evidence. The fsk is still a
53 unification variable, but it is "owned" by its CFunEqCan, and
54 is filled in (unflattened) only by unflattenGivens.
56 - A unification flatten-skolem, fmv, stands for the as-yet-unknown
57 type to which (F xis) will eventually reduce. It is filled in
60 - All fsk/fmv variables are "untouchable". To make it simple to test,
61 we simply give them TcLevel=0. This means that in a CTyVarEq, say,
62 fmv ~ Int
63 we NEVER unify fmv.
65 - A unification flatten-skolem, fmv, ONLY gets unified when either
66 a) The CFunEqCan takes a step, using an axiom
67 b) By unflattenWanteds
68 They are never unified in any other form of equality.
69 For example [W] ffmv ~ Int is stuck; it does not unify with fmv.
71 * We *never* substitute in the RHS (i.e. the fsk/fmv) of a CFunEqCan.
72 That would destroy the invariant about the shape of a CFunEqCan,
73 and it would risk wanted/wanted interactions. The only way we
74 learn information about fsk is when the CFunEqCan takes a step.
76 However we *do* substitute in the LHS of a CFunEqCan (else it
77 would never get to fire!)
79 * Unflattening:
80 - We unflatten Givens when leaving their scope (see unflattenGivens)
81 - We unflatten Wanteds at the end of each attempt to simplify the
82 wanteds; see unflattenWanteds, called from solveSimpleWanteds.
84 * Ownership of fsk/fmv. Each canonical [G], [W], or [WD]
85 CFunEqCan x : F xis ~ fsk/fmv
86 "owns" a distinct evidence variable x, and flatten-skolem fsk/fmv.
87 Why? We make a fresh fsk/fmv when the constraint is born;
88 and we never rewrite the RHS of a CFunEqCan.
90 In contrast a [D] CFunEqCan /shares/ its fmv with its partner [W],
91 but does not "own" it. If we reduce a [D] F Int ~ fmv, where
92 say type instance F Int = ty, then we don't discharge fmv := ty.
93 Rather we simply generate [D] fmv ~ ty (in TcInteract.reduce_top_fun_eq,
94 and dischargeFmv)
96 * Inert set invariant: if F xis1 ~ fsk1, F xis2 ~ fsk2
97 then xis1 /= xis2
98 i.e. at most one CFunEqCan with a particular LHS
100 * Function applications can occur in the RHS of a CTyEqCan. No reason
101 not allow this, and it reduces the amount of flattening that must occur.
103 * Flattening a type (F xis):
104 - If we are flattening in a Wanted/Derived constraint
105 then create new [W] x : F xis ~ fmv
106 else create new [G] x : F xis ~ fsk
107 with fresh evidence variable x and flatten-skolem fsk/fmv
109 - Add it to the work list
111 - Replace (F xis) with fsk/fmv in the type you are flattening
113 - You can also add the CFunEqCan to the "flat cache", which
114 simply keeps track of all the function applications you
115 have flattened.
117 - If (F xis) is in the cache already, just
118 use its fsk/fmv and evidence x, and emit nothing.
120 - No need to substitute in the flat-cache. It's not the end
121 of the world if we start with, say (F alpha ~ fmv1) and
122 (F Int ~ fmv2) and then find alpha := Int. Athat will
123 simply give rise to fmv1 := fmv2 via [Interacting rule] below
125 * Canonicalising a CFunEqCan [G/W] x : F xis ~ fsk/fmv
126 - Flatten xis (to substitute any tyvars; there are already no functions)
127 cos :: xis ~ flat_xis
128 - New wanted x2 :: F flat_xis ~ fsk/fmv
129 - Add new wanted to flat cache
130 - Discharge x = F cos ; x2
132 * [Interacting rule]
133 (inert) [W] x1 : F tys ~ fmv1
134 (work item) [W] x2 : F tys ~ fmv2
135 Just solve one from the other:
136 x2 := x1
137 fmv2 := fmv1
138 This just unites the two fsks into one.
139 Always solve given from wanted if poss.
141 * For top-level reductions, see Note [Top-level reductions for type functions]
142 in TcInteract
145 Why given-fsks, alone, doesn't work
146 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
147 Could we get away with only flatten meta-tyvars, with no flatten-skolems? No.
149 [W] w : alpha ~ [F alpha Int]
151 ---> flatten
152 w = ...w'...
153 [W] w' : alpha ~ [fsk]
154 [G] <F alpha Int> : F alpha Int ~ fsk
156 --> unify (no occurs check)
157 alpha := [fsk]
159 But since fsk = F alpha Int, this is really an occurs check error. If
160 that is all we know about alpha, we will succeed in constraint
161 solving, producing a program with an infinite type.
163 Even if we did finally get (g : fsk ~ Bool) by solving (F alpha Int ~ fsk)
164 using axiom, zonking would not see it, so (x::alpha) sitting in the
165 tree will get zonked to an infinite type. (Zonking always only does
166 refl stuff.)
168 Why flatten-meta-vars, alone doesn't work
169 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
170 Look at Simple13, with unification-fmvs only
172 [G] g : a ~ [F a]
174 ---> Flatten given
175 g' = g;[x]
176 [G] g' : a ~ [fmv]
177 [W] x : F a ~ fmv
179 --> subst a in x
180 g' = g;[x]
181 x = F g' ; x2
182 [W] x2 : F [fmv] ~ fmv
184 And now we have an evidence cycle between g' and x!
186 If we used a given instead (ie current story)
188 [G] g : a ~ [F a]
190 ---> Flatten given
191 g' = g;[x]
192 [G] g' : a ~ [fsk]
193 [G] <F a> : F a ~ fsk
195 ---> Substitute for a
196 [G] g' : a ~ [fsk]
197 [G] F (sym g'); <F a> : F [fsk] ~ fsk
200 Why is it right to treat fmv's differently to ordinary unification vars?
201 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
202 f :: forall a. a -> a -> Bool
203 g :: F Int -> F Int -> Bool
205 Consider
206 f (x:Int) (y:Bool)
207 This gives alpha~Int, alpha~Bool. There is an inconsistency,
208 but really only one error. SherLoc may tell you which location
209 is most likely, based on other occurrences of alpha.
211 Consider
212 g (x:Int) (y:Bool)
213 Here we get (F Int ~ Int, F Int ~ Bool), which flattens to
214 (fmv ~ Int, fmv ~ Bool)
215 But there are really TWO separate errors.
217 ** We must not complain about Int~Bool. **
219 Moreover these two errors could arise in entirely unrelated parts of
220 the code. (In the alpha case, there must be *some* connection (eg
221 v:alpha in common envt).)
223 Note [Unflattening can force the solver to iterate]
224 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
225 Look at Trac #10340:
226 type family Any :: * -- No instances
227 get :: MonadState s m => m s
228 instance MonadState s (State s) where ...
230 foo :: State Any Any
231 foo = get
233 For 'foo' we instantiate 'get' at types mm ss
234 [WD] MonadState ss mm, [WD] mm ss ~ State Any Any
235 Flatten, and decompose
236 [WD] MonadState ss mm, [WD] Any ~ fmv
237 [WD] mm ~ State fmv, [WD] fmv ~ ss
238 Unify mm := State fmv:
239 [WD] MonadState ss (State fmv)
240 [WD] Any ~ fmv, [WD] fmv ~ ss
241 Now we are stuck; the instance does not match!! So unflatten:
242 fmv := Any
243 ss := Any (*)
244 [WD] MonadState Any (State Any)
246 The unification (*) represents progress, so we must do a second
247 round of solving; this time it succeeds. This is done by the 'go'
248 loop in solveSimpleWanteds.
250 This story does not feel right but it's the best I can do; and the
251 iteration only happens in pretty obscure circumstances.
254 ************************************************************************
255 * *
256 * Examples
257 Here is a long series of examples I had to work through
258 * *
259 ************************************************************************
261 Simple20
262 ~~~~~~~~
263 axiom F [a] = [F a]
265 [G] F [a] ~ a
266 -->
267 [G] fsk ~ a
268 [G] [F a] ~ fsk (nc)
269 -->
270 [G] F a ~ fsk2
271 [G] fsk ~ [fsk2]
272 [G] fsk ~ a
273 -->
274 [G] F a ~ fsk2
275 [G] a ~ [fsk2]
276 [G] fsk ~ a
278 ----------------------------------------
279 indexed-types/should_compile/T44984
281 [W] H (F Bool) ~ H alpha
282 [W] alpha ~ F Bool
283 -->
284 F Bool ~ fmv0
285 H fmv0 ~ fmv1
286 H alpha ~ fmv2
288 fmv1 ~ fmv2
289 fmv0 ~ alpha
291 flatten
292 ~~~~~~~
293 fmv0 := F Bool
294 fmv1 := H (F Bool)
295 fmv2 := H alpha
296 alpha := F Bool
297 plus
298 fmv1 ~ fmv2
300 But these two are equal under the above assumptions.
301 Solve by Refl.
304 --- under plan B, namely solve fmv1:=fmv2 eagerly ---
305 [W] H (F Bool) ~ H alpha
306 [W] alpha ~ F Bool
307 -->
308 F Bool ~ fmv0
309 H fmv0 ~ fmv1
310 H alpha ~ fmv2
312 fmv1 ~ fmv2
313 fmv0 ~ alpha
314 -->
315 F Bool ~ fmv0
316 H fmv0 ~ fmv1
317 H alpha ~ fmv2 fmv2 := fmv1
319 fmv0 ~ alpha
321 flatten
322 fmv0 := F Bool
323 fmv1 := H fmv0 = H (F Bool)
324 retain H alpha ~ fmv2
325 because fmv2 has been filled
326 alpha := F Bool
329 ----------------------------
330 indexed-types/should_failt/T4179
332 after solving
333 [W] fmv_1 ~ fmv_2
334 [W] A3 (FCon x) ~ fmv_1 (CFunEqCan)
335 [W] A3 (x (aoa -> fmv_2)) ~ fmv_2 (CFunEqCan)
337 ----------------------------------------
338 indexed-types/should_fail/T7729a
340 a) [W] BasePrimMonad (Rand m) ~ m1
341 b) [W] tt m1 ~ BasePrimMonad (Rand m)
343 ---> process (b) first
344 BasePrimMonad (Ramd m) ~ fmv_atH
345 fmv_atH ~ tt m1
347 ---> now process (a)
348 m1 ~ s_atH ~ tt m1 -- An obscure occurs check
351 ----------------------------------------
352 typecheck/TcTypeNatSimple
354 Original constraint
355 [W] x + y ~ x + alpha (non-canonical)
356 ==>
357 [W] x + y ~ fmv1 (CFunEqCan)
358 [W] x + alpha ~ fmv2 (CFuneqCan)
359 [W] fmv1 ~ fmv2 (CTyEqCan)
361 (sigh)
363 ----------------------------------------
366 [G] Const a ~ ()
367 ==> flatten
368 [G] fsk ~ ()
369 work item: Const a ~ fsk
370 ==> fire top rule
371 [G] fsk ~ ()
372 work item fsk ~ ()
374 Surely the work item should rewrite to () ~ ()? Well, maybe not;
375 it'a very special case. More generally, our givens look like
376 F a ~ Int, where (F a) is not reducible.
379 ----------------------------------------
380 indexed_types/should_fail/T8227:
382 Why using a different can-rewrite rule in CFunEqCan heads
383 does not work.
385 Assuming NOT rewriting wanteds with wanteds
387 Inert: [W] fsk_aBh ~ fmv_aBk -> fmv_aBk
388 [W] fmv_aBk ~ fsk_aBh
390 [G] Scalar fsk_aBg ~ fsk_aBh
391 [G] V a ~ f_aBg
393 Worklist includes [W] Scalar fmv_aBi ~ fmv_aBk
394 fmv_aBi, fmv_aBk are flatten unification variables
396 Work item: [W] V fsk_aBh ~ fmv_aBi
398 Note that the inert wanteds are cyclic, because we do not rewrite
399 wanteds with wanteds.
402 Then we go into a loop when normalise the work-item, because we
403 use rewriteOrSame on the argument of V.
405 Conclusion: Don't make canRewrite context specific; instead use
406 [W] a ~ ty to rewrite a wanted iff 'a' is a unification variable.
409 ----------------------------------------
411 Here is a somewhat similar case:
413 type family G a :: *
415 blah :: (G a ~ Bool, Eq (G a)) => a -> a
416 blah = error "urk"
418 foo x = blah x
420 For foo we get
421 [W] Eq (G a), G a ~ Bool
422 Flattening
423 [W] G a ~ fmv, Eq fmv, fmv ~ Bool
424 We can't simplify away the Eq Bool unless we substitute for fmv.
425 Maybe that doesn't matter: we would still be left with unsolved
426 G a ~ Bool.
428 --------------------------
429 Trac #9318 has a very simple program leading to
431 [W] F Int ~ Int
432 [W] F Int ~ Bool
434 We don't want to get "Error Int~Bool". But if fmv's can rewrite
435 wanteds, we will
437 [W] fmv ~ Int
438 [W] fmv ~ Bool
439 --->
440 [W] Int ~ Bool
443 ************************************************************************
444 * *
445 * FlattenEnv & FlatM
446 * The flattening environment & monad
447 * *
448 ************************************************************************
450 -}
452 type FlatWorkListRef = TcRef [Ct] -- See Note [The flattening work list]
454 data FlattenEnv
455 = FE { fe_mode :: !FlattenMode
456 , fe_loc :: !CtLoc -- See Note [Flattener CtLoc]
457 , fe_flavour :: !CtFlavour
458 , fe_eq_rel :: !EqRel -- See Note [Flattener EqRels]
459 , fe_work :: !FlatWorkListRef } -- See Note [The flattening work list]
461 data FlattenMode -- Postcondition for all three: inert wrt the type substitution
462 = FM_FlattenAll -- Postcondition: function-free
463 | FM_SubstOnly -- See Note [Flattening under a forall]
465 -- | FM_Avoid TcTyVar Bool -- See Note [Lazy flattening]
466 -- -- Postcondition:
467 -- -- * tyvar is only mentioned in result under a rigid path
468 -- -- e.g. [a] is ok, but F a won't happen
469 -- -- * If flat_top is True, top level is not a function application
470 -- -- (but under type constructors is ok e.g. [F a])
472 instance Outputable FlattenMode where
473 ppr FM_FlattenAll = text "FM_FlattenAll"
474 ppr FM_SubstOnly = text "FM_SubstOnly"
476 eqFlattenMode :: FlattenMode -> FlattenMode -> Bool
477 eqFlattenMode FM_FlattenAll FM_FlattenAll = True
478 eqFlattenMode FM_SubstOnly FM_SubstOnly = True
479 -- FM_Avoid tv1 b1 `eq` FM_Avoid tv2 b2 = tv1 == tv2 && b1 == b2
480 eqFlattenMode _ _ = False
482 -- | The 'FlatM' monad is a wrapper around 'TcS' with the following
484 -- and (2) it maintains the flattening worklist.
485 -- See Note [The flattening work list].
486 newtype FlatM a
487 = FlatM { runFlatM :: FlattenEnv -> TcS a }
490 m >>= k = FlatM \$ \env ->
491 do { a <- runFlatM m env
492 ; runFlatM (k a) env }
494 instance Functor FlatM where
495 fmap = liftM
497 instance Applicative FlatM where
498 pure x = FlatM \$ const (pure x)
499 (<*>) = ap
501 liftTcS :: TcS a -> FlatM a
502 liftTcS thing_inside
503 = FlatM \$ const thing_inside
505 emitFlatWork :: Ct -> FlatM ()
506 -- See Note [The flattening work list]
507 emitFlatWork ct = FlatM \$ \env -> updTcRef (fe_work env) (ct :)
509 -- convenient wrapper when you have a CtEvidence describing
510 -- the flattening operation
511 runFlattenCtEv :: FlattenMode -> CtEvidence -> FlatM a -> TcS a
512 runFlattenCtEv mode ev
513 = runFlatten mode (ctEvLoc ev) (ctEvFlavour ev) (ctEvEqRel ev)
515 -- Run thing_inside (which does flattening), and put all
516 -- the work it generates onto the main work list
517 -- See Note [The flattening work list]
518 runFlatten :: FlattenMode -> CtLoc -> CtFlavour -> EqRel -> FlatM a -> TcS a
519 runFlatten mode loc flav eq_rel thing_inside
520 = do { flat_ref <- newTcRef []
521 ; let fmode = FE { fe_mode = mode
522 , fe_loc = loc
523 , fe_flavour = flav
524 , fe_eq_rel = eq_rel
525 , fe_work = flat_ref }
526 ; res <- runFlatM thing_inside fmode
527 ; new_flats <- readTcRef flat_ref
529 ; return res }
530 where
532 = wl { wl_funeqs = add_funeqs new_flats (wl_funeqs wl) }
534 add_funeqs [] wl = wl
536 -- add_funeqs fs ws = reverse fs ++ ws
537 -- e.g. add_funeqs [f1,f2,f3] [w1,w2,w3,w4]
538 -- = [f3,f2,f1,w1,w2,w3,w4]
540 traceFlat :: String -> SDoc -> FlatM ()
541 traceFlat herald doc = liftTcS \$ traceTcS herald doc
543 getFlatEnvField :: (FlattenEnv -> a) -> FlatM a
544 getFlatEnvField accessor
545 = FlatM \$ \env -> return (accessor env)
547 getEqRel :: FlatM EqRel
548 getEqRel = getFlatEnvField fe_eq_rel
550 getRole :: FlatM Role
551 getRole = eqRelRole <\$> getEqRel
553 getFlavour :: FlatM CtFlavour
554 getFlavour = getFlatEnvField fe_flavour
556 getFlavourRole :: FlatM CtFlavourRole
557 getFlavourRole
558 = do { flavour <- getFlavour
559 ; eq_rel <- getEqRel
560 ; return (flavour, eq_rel) }
562 getMode :: FlatM FlattenMode
563 getMode = getFlatEnvField fe_mode
565 getLoc :: FlatM CtLoc
566 getLoc = getFlatEnvField fe_loc
568 checkStackDepth :: Type -> FlatM ()
569 checkStackDepth ty
570 = do { loc <- getLoc
571 ; liftTcS \$ checkReductionDepth loc ty }
573 -- | Change the 'EqRel' in a 'FlatM'.
574 setEqRel :: EqRel -> FlatM a -> FlatM a
575 setEqRel new_eq_rel thing_inside
576 = FlatM \$ \env ->
577 if new_eq_rel == fe_eq_rel env
578 then runFlatM thing_inside env
579 else runFlatM thing_inside (env { fe_eq_rel = new_eq_rel })
581 -- | Change the 'FlattenMode' in a 'FlattenEnv'.
582 setMode :: FlattenMode -> FlatM a -> FlatM a
583 setMode new_mode thing_inside
584 = FlatM \$ \env ->
585 if new_mode `eqFlattenMode` fe_mode env
586 then runFlatM thing_inside env
587 else runFlatM thing_inside (env { fe_mode = new_mode })
589 -- | Make sure that flattening actually produces a coercion (in other
590 -- words, make sure our flavour is not Derived)
591 -- Note [No derived kind equalities]
592 noBogusCoercions :: FlatM a -> FlatM a
593 noBogusCoercions thing_inside
594 = FlatM \$ \env ->
595 -- No new thunk is made if the flavour hasn't changed (note the bang).
596 let !env' = case fe_flavour env of
597 Derived -> env { fe_flavour = Wanted WDeriv }
598 _ -> env
599 in
600 runFlatM thing_inside env'
602 bumpDepth :: FlatM a -> FlatM a
603 bumpDepth (FlatM thing_inside)
604 = FlatM \$ \env -> do
605 -- bumpDepth can be called a lot during flattening so we force the
606 -- new env to avoid accumulating thunks.
607 { let !env' = env { fe_loc = bumpCtLocDepth (fe_loc env) }
608 ; thing_inside env' }
610 {-
611 Note [The flattening work list]
612 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
613 The "flattening work list", held in the fe_work field of FlattenEnv,
614 is a list of CFunEqCans generated during flattening. The key idea
615 is this. Consider flattening (Eq (F (G Int) (H Bool)):
616 * The flattener recursively calls itself on sub-terms before building
617 the main term, so it will encounter the terms in order
618 G Int
619 H Bool
620 F (G Int) (H Bool)
621 flattening to sub-goals
622 w1: G Int ~ fuv0
623 w2: H Bool ~ fuv1
624 w3: F fuv0 fuv1 ~ fuv2
626 * Processing w3 first is BAD, because we can't reduce i t,so it'll
627 get put into the inert set, and later kicked out when w1, w2 are
628 solved. In Trac #9872 this led to inert sets containing hundreds
629 of suspended calls.
631 * So we want to process w1, w2 first.
633 * So you might think that we should just use a FIFO deque for the work-list,
634 so that putting adding goals in order w1,w2,w3 would mean we processed
635 w1 first.
637 * BUT suppose we have 'type instance G Int = H Char'. Then processing
638 w1 leads to a new goal
639 w4: H Char ~ fuv0
640 We do NOT want to put that on the far end of a deque! Instead we want
641 to put it at the *front* of the work-list so that we continue to work
642 on it.
644 So the work-list structure is this:
646 * The wl_funeqs (in TcS) is a LIFO stack; we push new goals (such as w4) on
647 top (extendWorkListFunEq), and take new work from the top
648 (selectWorkItem).
650 * When flattening, emitFlatWork pushes new flattening goals (like
651 w1,w2,w3) onto the flattening work list, fe_work, another
652 push-down stack.
654 * When we finish flattening, we *reverse* the fe_work stack
655 onto the wl_funeqs stack (which brings w1 to the top).
657 The function runFlatten initialises the fe_work stack, and reverses
658 it onto wl_fun_eqs at the end.
660 Note [Flattener EqRels]
661 ~~~~~~~~~~~~~~~~~~~~~~~
662 When flattening, we need to know which equality relation -- nominal
663 or representation -- we should be respecting. The only difference is
664 that we rewrite variables by representational equalities when fe_eq_rel
665 is ReprEq, and that we unwrap newtypes when flattening w.r.t.
666 representational equality.
668 Note [Flattener CtLoc]
669 ~~~~~~~~~~~~~~~~~~~~~~
670 The flattener does eager type-family reduction.
671 Type families might loop, and we
672 don't want GHC to do so. A natural solution is to have a bounded depth
673 to these processes. A central difficulty is that such a solution isn't
674 quite compositional. For example, say it takes F Int 10 steps to get to Bool.
675 How many steps does it take to get from F Int -> F Int to Bool -> Bool?
676 10? 20? What about getting from Const Char (F Int) to Char? 11? 1? Hard to
677 know and hard to track. So, we punt, essentially. We store a CtLoc in
678 the FlattenEnv and just update the environment when recurring. In the
679 TyConApp case, where there may be multiple type families to flatten,
680 we just copy the current CtLoc into each branch. If any branch hits the
681 stack limit, then the whole thing fails.
683 A consequence of this is that setting the stack limits appropriately
684 will be essentially impossible. So, the official recommendation if a
685 stack limit is hit is to disable the check entirely. Otherwise, there
686 will be baffling, unpredictable errors.
688 Note [Lazy flattening]
689 ~~~~~~~~~~~~~~~~~~~~~~
690 The idea of FM_Avoid mode is to flatten less aggressively. If we have
691 a ~ [F Int]
692 there seems to be no great merit in lifting out (F Int). But if it was
693 a ~ [G a Int]
694 then we *do* want to lift it out, in case (G a Int) reduces to Bool, say,
695 which gets rid of the occurs-check problem. (For the flat_top Bool, see
696 comments above and at call sites.)
698 HOWEVER, the lazy flattening actually seems to make type inference go
699 *slower*, not faster. perf/compiler/T3064 is a case in point; it gets
700 *dramatically* worse with FM_Avoid. I think it may be because
701 floating the types out means we normalise them, and that often makes
702 them smaller and perhaps allows more re-use of previously solved
703 goals. But to be honest I'm not absolutely certain, so I am leaving
704 FM_Avoid in the code base. What I'm removing is the unique place
705 where it is *used*, namely in TcCanonical.canEqTyVar.
708 other examples where lazy flattening caused problems.
710 Bottom line: FM_Avoid is unused for now (Nov 14).
711 Note: T5321Fun got faster when I disabled FM_Avoid
712 T5837 did too, but it's pathalogical anyway
714 Note [Phantoms in the flattener]
715 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
716 Suppose we have
718 data Proxy p = Proxy
720 and we're flattening (Proxy ty) w.r.t. ReprEq. Then, we know that `ty`
721 is really irrelevant -- it will be ignored when solving for representational
722 equality later on. So, we omit flattening `ty` entirely. This may
723 violate the expectation of "xi"s for a bit, but the canonicaliser will
724 soon throw out the phantoms when decomposing a TyConApp. (Or, the
725 canonicaliser will emit an insoluble, in which case the unflattened version
726 yields a better error message anyway.)
728 Note [No derived kind equalities]
729 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
730 A kind-level coercion can appear in types, via mkCastTy. So, whenever
731 we are generating a coercion in a dependent context (in other words,
732 in a kind) we need to make sure that our flavour is never Derived
733 (as Derived constraints have no evidence). The noBogusCoercions function
734 changes the flavour from Derived just for this purpose.
736 -}
738 {- *********************************************************************
739 * *
740 * Externally callable flattening functions *
741 * *
742 * They are all wrapped in runFlatten, so their *
743 * flattening work gets put into the work list *
744 * *
745 ********************************************************************* -}
747 flatten :: FlattenMode -> CtEvidence -> TcType
748 -> TcS (Xi, TcCoercion)
749 flatten mode ev ty
750 = do { traceTcS "flatten {" (ppr mode <+> ppr ty)
751 ; (ty', co) <- runFlattenCtEv mode ev (flatten_one ty)
752 ; traceTcS "flatten }" (ppr ty')
753 ; return (ty', co) }
755 -- specialized to flattening kinds: never Derived, always Nominal
756 -- See Note [No derived kind equalities]
757 flattenKind :: CtLoc -> CtFlavour -> TcType -> TcS (Xi, TcCoercionN)
758 flattenKind loc flav ty
759 = do { traceTcS "flattenKind {" (ppr flav <+> ppr ty)
760 ; let flav' = case flav of
761 Derived -> Wanted WDeriv -- the WDeriv/WOnly choice matters not
762 _ -> flav
763 ; (ty', co) <- runFlatten FM_FlattenAll loc flav' NomEq (flatten_one ty)
764 ; traceTcS "flattenKind }" (ppr ty' \$\$ ppr co) -- co is never a panic
765 ; return (ty', co) }
767 flattenArgsNom :: CtEvidence -> TyCon -> [TcType] -> TcS ([Xi], [TcCoercion], TcCoercionN)
768 -- Externally-callable, hence runFlatten
769 -- Flatten a vector of types all at once; in fact they are
770 -- always the arguments of type family or class, so
771 -- ctEvFlavour ev = Nominal
772 -- and we want to flatten all at nominal role
773 -- The kind passed in is the kind of the type family or class, call it T
774 -- The last coercion returned has type (typeKind(T xis) ~N typeKind(T tys))
775 flattenArgsNom ev tc tys
776 = do { traceTcS "flatten_args {" (vcat (map ppr tys))
777 ; (tys', cos, kind_co)
778 <- runFlattenCtEv FM_FlattenAll ev (flatten_args_tc tc (repeat Nominal) tys)
779 ; traceTcS "flatten }" (vcat (map ppr tys'))
780 ; return (tys', cos, kind_co) }
783 {- *********************************************************************
784 * *
785 * The main flattening functions
786 * *
787 ********************************************************************* -}
789 {- Note [Flattening]
790 ~~~~~~~~~~~~~~~~~~~~
791 flatten ty ==> (xi, co)
792 where
793 xi has no type functions, unless they appear under ForAlls
794 has no skolems that are mapped in the inert set
795 has no filled-in metavariables
796 co :: xi ~ ty
798 Key invariants:
799 (F0) co :: xi ~ zonk(ty)
800 (F1) typeKind(xi) succeeds and returns a fully zonked kind
801 (F2) typeKind(xi) `eqType` zonk(typeKind(ty))
803 Note that it is flatten's job to flatten *every type function it sees*.
804 flatten is only called on *arguments* to type functions, by canEqGiven.
806 Flattening also:
807 * zonks, removing any metavariables, and
808 * applies the substitution embodied in the inert set
810 Because flattening zonks and the returned coercion ("co" above) is also
811 zonked, it's possible that (co :: xi ~ ty) isn't quite true. So, instead,
812 we can rely on this fact:
814 (F1) typeKind(xi) succeeds and returns a fully zonked kind
816 Note that the left-hand type of co is *always* precisely xi. The right-hand
817 type may or may not be ty, however: if ty has unzonked filled-in metavariables,
818 then the right-hand type of co will be the zonked version of ty.
819 It is for this reason that we
820 occasionally have to explicitly zonk, when (co :: xi ~ ty) is important
821 even before we zonk the whole program. For example, see the FTRNotFollowed
822 case in flattenTyVar.
824 Why have these invariants on flattening? Because we sometimes use typeKind
825 during canonicalisation, and we want this kind to be zonked (e.g., see
826 TcCanonical.canEqTyVar).
828 Flattening is always homogeneous. That is, the kind of the result of flattening is
829 always the same as the kind of the input, modulo zonking. More formally:
831 (F2) typeKind(xi) `eqType` zonk(typeKind(ty))
833 This invariant means that the kind of a flattened type might not itself be flat.
835 Recall that in comments we use alpha[flat = ty] to represent a
836 flattening skolem variable alpha which has been generated to stand in
837 for ty.
839 ----- Example of flattening a constraint: ------
840 flatten (List (F (G Int))) ==> (xi, cc)
841 where
842 xi = List alpha
843 cc = { G Int ~ beta[flat = G Int],
844 F beta ~ alpha[flat = F beta] }
845 Here
846 * alpha and beta are 'flattening skolem variables'.
847 * All the constraints in cc are 'given', and all their coercion terms
848 are the identity.
850 NB: Flattening Skolems only occur in canonical constraints, which
851 are never zonked, so we don't need to worry about zonking doing
852 accidental unflattening.
854 Note that we prefer to leave type synonyms unexpanded when possible,
855 so when the flattener encounters one, it first asks whether its
856 transitive expansion contains any type function applications. If so,
857 it expands the synonym and proceeds; if not, it simply returns the
858 unexpanded synonym.
860 Note [flatten_args performance]
861 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
862 In programs with lots of type-level evaluation, flatten_args becomes
863 part of a tight loop. For example, see test perf/compiler/T9872a, which
864 calls flatten_args a whopping 7,106,808 times. It is thus important
865 that flatten_args be efficient.
867 Performance testing showed that the current implementation is indeed
868 efficient. It's critically important that zipWithAndUnzipM be
869 specialized to TcS, and it's also quite helpful to actually `inline`
870 it. On test T9872a, here are the allocation stats (Dec 16, 2014):
872 * Unspecialized, uninlined: 8,472,613,440 bytes allocated in the heap
873 * Specialized, uninlined: 6,639,253,488 bytes allocated in the heap
874 * Specialized, inlined: 6,281,539,792 bytes allocated in the heap
876 To improve performance even further, flatten_args_nom is split off
877 from flatten_args, as nominal equality is the common case. This would
878 be natural to write using mapAndUnzipM, but even inlined, that function
879 is not as performant as a hand-written loop.
881 * mapAndUnzipM, inlined: 7,463,047,432 bytes allocated in the heap
882 * hand-written recursion: 5,848,602,848 bytes allocated in the heap
884 If you make any change here, pay close attention to the T9872{a,b,c} tests
885 and T5321Fun.
887 If we need to make this yet more performant, a possible way forward is to
888 duplicate the flattener code for the nominal case, and make that case
889 faster. This doesn't seem quite worth it, yet.
891 Note [flatten_args]
892 ~~~~~~~~~~~~~~~~~~~
893 Invariant (F2) of Note [Flattening] says that flattening is homogeneous.
894 This causes some trouble when flattening a function applied to a telescope
895 of arguments, perhaps with dependency. For example, suppose
897 type family F :: forall (j :: Type) (k :: Type). Maybe j -> Either j k -> Bool -> [k]
899 and we wish to flatten the args of (with kind applications explicit)
901 F a b (Just a c) (Right a b d) False
903 where all variables are skolems and
905 a :: Type
906 b :: Type
907 c :: a
908 d :: k
910 [G] aco :: a ~ fa
911 [G] bco :: b ~ fb
912 [G] cco :: c ~ fc
913 [G] dco :: d ~ fd
915 We process the args in left-to-right order. The first two args are easy:
917 (sym aco, fa) <- flatten a
918 (sym bco, fb) <- flatten b
920 But now consider flattening (Just a c :: Maybe a). Regardless of how this
921 flattens, the result will have kind (Maybe a), due to (F2). And yet, when
922 we build the application (F fa fb ...), we need this argument to have kind
923 (Maybe fa), not (Maybe a). Suppose (Just a c) flattens to f3 (the "3" is
924 because it's the 3rd argument). We know f3 :: Maybe a. In order to get f3
925 to have kind Maybe fa, we must cast it. The coercion to use is determined
926 by the kind of F: we see in F's kind that the third argument has kind
927 Maybe j. Critically, we also know that the argument corresponding to j
928 (in our example, a) flattened with a coercion (sym aco). We can thus
929 know the coercion needed for the 3rd argument is (Maybe aco).
931 More generally, we must use the Lifting Lemma, as implemented in
932 Coercion.liftCoSubst. As we work left-to-right, any variable that is a
933 dependent parameter (j and k, in our example) gets mapped in a lifting context
934 to the coercion that is output from flattening the corresponding argument (aco
935 and bco, in our example). Then, after flattening later arguments, we lift the
936 kind of these arguments in the lifting context that we've be building up.
937 This coercion is then used to keep the result of flattening well-kinded.
939 Working through our example, this is what happens:
941 1. Flatten a, getting (sym aco, fa). Extend the (empty) LC with [j |-> sym aco]
943 2. Flatten b, getting (sym bco, fb). Extend the LC with [k |-> sym bco].
945 3. Flatten (Just a c), getting (co3, f3). Lifting the kind (Maybe j) with our LC
946 yields lco3 :: Maybe fa ~ Maybe a. Use (f3 |> sym lco3) as the argument to
947 F.
949 4. Flatten (Right a b d), getting (co4, f4). Lifting the kind (Either j k) with our LC
950 yields lco4 :: Either fa fb ~ Either a b. Use (f4 |> sym lco4) as the 4th
951 argument to F.
953 5. Flatten False, getting (<False>, False). We lift Bool with our LC, getting <Bool>;
954 casting has no effect. (Indeed we lifted and casted with no effect for steps 1 and 2, as well.)
956 We're now almost done, but the new application (F fa fb (f3 |> sym lco3) (f4
957 |> sym lco4) False) has the wrong kind. Its kind is [fb], instead of the original [b].
958 So we must use our LC one last time to lift the result kind [k], getting res_co :: [fb] ~ [b], and
959 we cast our result.
961 Accordingly, the final result is
963 F fa fb (Just fa (fc |> aco) |> Maybe (sym aco) |> sym (Maybe (sym aco)))
964 (Right fa fb (fd |> bco) |> Either (sym aco) (sym bco) |> sym (Either (sym aco) (sym bco)))
965 False
966 |> [sym bco]
968 The res_co is returned as the third return value from flatten_args.
970 Note [Last case in flatten_args]
971 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
972 In writing flatten_args's `go`, we know here that tys cannot be empty,
973 because that case is first. We've run out of
974 binders. But perhaps inner_ki is a tyvar that has been instantiated with a
975 Î -type. I believe this, today, this Î -type must be an ordinary function.
976 But tomorrow, we may allow, say, visible type application in types. And
977 it's best to be prepared.
979 Here is an example.
981 a :: forall (k :: Type). k -> k
982 type family Star
983 Proxy :: forall j. j -> Type
984 axStar :: Star ~ Type
985 type family NoWay :: Bool
986 axNoWay :: NoWay ~ False
987 bo :: Type
988 [G] bc :: bo ~ Bool (in inert set)
990 co :: (forall j. j -> Type) ~ (forall (j :: Star). (j |> axStar) -> Star)
991 co = forall (j :: sym axStar). (<j> -> sym axStar)
993 We are flattening:
994 a (forall (j :: Star). (j |> axStar) -> Star) -- 1
995 (Proxy |> co) -- 2
996 (bo |> sym axStar) -- 3
997 (NoWay |> sym bc) -- 4
998 :: Star
1000 Flattening (1) gives us
1001 (forall j. j -> Type)
1002 co1 :: (forall j. j -> Type) ~ (forall (j :: Star). (j |> axStar) -> Star)
1003 We also extend the lifting context with
1004 k |-> co1
1006 Flattening (2) gives us
1007 (Proxy |> co)
1008 But building (a (forall j. j -> Type) Proxy) would be ill-kinded. So we cast the
1009 result of flattening by sym co1, to get
1010 (Proxy |> co |> sym co1)
1011 Happily, co and co1 cancel each other out, leaving us with
1012 Proxy
1013 co2 :: Proxy ~ (Proxy |> co)
1015 Now we need to flatten (3). After flattening, should we tack on a homogenizing
1016 coercion? The way we normally tell is to look at the kind of `a`. (See Note
1017 [flatten_args].) Here, the remainder of the kind of `a` that we're left with
1018 after processing two arguments is just `k`.
1020 The way forward is look up k in the lifting context, getting co1. If we're at
1021 all well-typed, co1 will be a coercion between Î -types, with enough binders on
1022 both sides to accommodate any remaining arguments in flatten_args. So, let's
1023 decompose co1 with decomposePiCos. This decomposition needs arguments to use
1024 to instantiate any kind parameters. Look at the type of co1. If we just
1025 decomposed it, we would end up with coercions whose types include j, which is
1026 out of scope here. Accordingly, decomposePiCos takes a list of types whose
1027 kinds are the *right-hand* types in the decomposed coercion. (See comments on
1028 decomposePiCos, which also reverses the orientation of the coercions.)
1029 The right-hand types are the unflattened ones -- conveniently what we have to
1030 hand.
1032 So we now call
1034 decomposePiCos (forall j. j -> Type)
1035 [bo |> sym axStar, NoWay |> sym bc]
1036 co1
1038 to get
1040 co3 :: Star ~ Type
1041 co4 :: (j |> axStar) ~ (j |> co3), substituted to
1042 (bo |> sym axStar |> axStar) ~ (bo |> sym axStar |> co3)
1043 == bo ~ bo
1044 res_co :: Type ~ Star -- this one's not reversed in decomposePiCos
1046 We then use these casts on (3) and (4) to get
1048 (bo |> sym axStar |> co3 :: Type) -- (C3)
1049 (NoWay |> sym bc |> co4 :: bo) -- (C4)
1051 We can simplify to
1053 bo -- (C3)
1054 (NoWay |> sym bc :: bo) -- (C4)
1056 Now, to flatten (C3) and (C4), we still need to keep track of dependency.
1057 We know the type of the function applied to (C3) and (C4) must be
1058 (forall j. j -> Type), the flattened type
1059 associated with k (the final type in the kind of `a`.) (We discard the lifting
1060 context up to this point; as we've already substituted k, the domain of the
1061 lifting context we used for (1) and (2), away.)
1063 We now flatten (C3) to get
1064 Bool -- F3
1065 co5 :: Bool ~ bo
1066 and flatten (C4) to get
1067 (False |> sym bc)
1068 Like we did when flattening (2), we need to cast the result of flattening
1069 (4), by lifting the type j with a lifting context containing
1070 [j |-> co5]. This lifting yields co5.
1071 We cast the result of flattening (C4) by sym co5 (this is the normal
1072 cast-after-flattening; see Note [flatten_args]):
1073 (False |> sym bc |> sym co5)
1074 which is really just
1075 False -- F4
1076 co4 :: False ~ (NoWay |> sym bc)
1078 Now, we build up the result
1080 a (forall j. j -> Type)
1081 Proxy
1082 Bool
1083 False
1084 |> res_co
1086 Let's check whether this is well-typed. We know
1088 a :: forall (k :: Type). k -> k
1090 a (forall j. j -> Type) :: (forall j. j -> Type) -> forall j. j -> Type
1092 a (forall j. j -> Type)
1093 Proxy
1094 :: forall j. j -> Type
1096 a (forall j. j -> Type)
1097 Proxy
1098 Bool
1099 :: Bool -> Type
1101 a (forall j. j -> Type)
1102 Proxy
1103 Bool
1104 False
1105 :: Type
1107 a (forall j. j -> Type)
1108 Proxy
1109 Bool
1110 False
1111 |> res_co
1112 :: Star
1114 as desired. (Why do we want Star? Because we started with something of kind Star!)
1116 Whew.
1118 Note [flatten_exact_fam_app_fully performance]
1119 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1121 The refactor of GRefl seems to cause performance trouble for T9872x: the allocation of flatten_exact_fam_app_fully_performance increased. See note [Generalized reflexive coercion] in TyCoRep for more information about GRefl and Trac #15192 for the current state.
1123 The explicit pattern match in homogenise_result helps with T9872a, b, c.
1125 Still, it increases the expected allocation of T9872d by ~2%.
1127 TODO: a step-by-step replay of the refactor to analyze the performance.
1129 -}
1131 {-# INLINE flatten_args_tc #-}
1132 flatten_args_tc
1133 :: TyCon -- T
1134 -> [Role] -- Role r
1135 -> [Type] -- Arg types [t1,..,tn]
1136 -> FlatM ( [Xi] -- List of flattened args [x1,..,xn]
1137 -- 1-1 corresp with [t1,..,tn]
1138 , [Coercion] -- List of arg coercions [co1,..,con]
1139 -- 1-1 corresp with [t1,..,tn]
1140 -- coi :: xi ~r ti
1141 , CoercionN) -- Result coercion, rco
1142 -- rco : (T t1..tn) ~N (T (x1 |> co1) .. (xn |> con))
1143 flatten_args_tc tc = flatten_args all_bndrs any_named_bndrs inner_ki emptyVarSet
1144 -- NB: TyCon kinds are always closed
1145 where
1146 (bndrs, named)
1147 = ty_con_binders_ty_binders' (tyConBinders tc)
1148 -- it's possible that the result kind has arrows (for, e.g., a type family)
1149 -- so we must split it
1150 (inner_bndrs, inner_ki, inner_named) = split_pi_tys' (tyConResKind tc)
1151 !all_bndrs = bndrs `chkAppend` inner_bndrs
1152 !any_named_bndrs = named || inner_named
1153 -- NB: Those bangs there drop allocations in T9872{a,c,d} by 8%.
1155 {-# INLINE flatten_args #-}
1156 flatten_args :: [TyCoBinder] -> Bool -- Binders, and True iff any of them are
1157 -- named.
1158 -> Kind -> TcTyCoVarSet -- function kind; kind's free vars
1159 -> [Role] -> [Type] -- these are in 1-to-1 correspondence
1160 -> FlatM ([Xi], [Coercion], CoercionN)
1161 -- Coercions :: Xi ~ Type, at roles given
1162 -- Third coercion :: typeKind(fun xis) ~N typeKind(fun tys)
1163 -- That is, the third coercion relates the kind of some function (whose kind is
1164 -- passed as the first parameter) instantiated at xis to the kind of that
1165 -- function instantiated at the tys. This is useful in keeping flattening
1166 -- homoegeneous. The list of roles must be at least as long as the list of
1167 -- types.
1168 -- See Note [flatten_args]
1169 flatten_args orig_binders
1170 any_named_bndrs
1171 orig_inner_ki
1172 orig_fvs
1173 orig_roles
1174 orig_tys
1175 = if any_named_bndrs
1176 then flatten_args_slow orig_binders
1177 orig_inner_ki
1178 orig_fvs
1179 orig_roles
1180 orig_tys
1181 else flatten_args_fast orig_binders orig_inner_ki orig_roles orig_tys
1183 {-# INLINE flatten_args_fast #-}
1184 -- | fast path flatten_args, in which none of the binders are named and
1185 -- therefore we can avoid tracking a lifting context.
1186 -- There are many bang patterns in here. It's been observed that they
1187 -- greatly improve performance of an optimized build.
1188 -- The T9872 test cases are good witnesses of this fact.
1189 flatten_args_fast :: [TyCoBinder]
1190 -> Kind
1191 -> [Role]
1192 -> [Type]
1193 -> FlatM ([Xi], [Coercion], CoercionN)
1194 flatten_args_fast orig_binders orig_inner_ki orig_roles orig_tys
1195 = fmap finish (iterate orig_tys orig_roles orig_binders)
1196 where
1198 iterate :: [Type]
1199 -> [Role]
1200 -> [TyCoBinder]
1201 -> FlatM ([Xi], [Coercion], [TyCoBinder])
1202 iterate (ty:tys) (role:roles) (_:binders) = do
1203 (xi, co) <- go role ty
1204 (xis, cos, binders) <- iterate tys roles binders
1205 pure (xi : xis, co : cos, binders)
1206 iterate [] _ binders = pure ([], [], binders)
1207 iterate _ _ _ = pprPanic
1208 "flatten_args wandered into deeper water than usual" (vcat [])
1209 -- This debug information is commented out because leaving it in
1210 -- causes a ~2% increase in allocations in T9872{a,c,d}.
1211 {-
1212 (vcat [ppr orig_binders,
1213 ppr orig_inner_ki,
1214 ppr (take 10 orig_roles), -- often infinite!
1215 ppr orig_tys])
1216 -}
1218 {-# INLINE go #-}
1219 go :: Role
1220 -> Type
1221 -> FlatM (Xi, Coercion)
1222 go role ty
1223 = case role of
1224 -- In the slow path we bind the Xi and Coercion from the recursive
1225 -- call and then use it such
1226 --
1227 -- let kind_co = mkTcSymCo \$ mkReflCo Nominal (tyBinderType binder)
1228 -- casted_xi = xi `mkCastTy` kind_co
1229 -- casted_co = xi |> kind_co ~r xi ; co
1230 --
1231 -- but this isn't necessary:
1232 -- mkTcSymCo (Refl a b) = Refl a b,
1233 -- mkCastTy x (Refl _ _) = x
1234 -- mkTcGReflLeftCo _ ty (Refl _ _) `mkTransCo` co = co
1235 --
1236 -- Also, no need to check isAnonTyCoBinder or isNamedTyCoBinder, since
1237 -- we've already established that they're all anonymous.
1238 Nominal -> setEqRel NomEq \$ flatten_one ty
1239 Representational -> setEqRel ReprEq \$ flatten_one ty
1240 Phantom -> -- See Note [Phantoms in the flattener]
1241 do { ty <- liftTcS \$ zonkTcType ty
1242 ; return (ty, mkReflCo Phantom ty) }
1245 {-# INLINE finish #-}
1246 finish :: ([Xi], [Coercion], [TyCoBinder]) -> ([Xi], [Coercion], CoercionN)
1247 finish (xis, cos, binders) = (xis, cos, kind_co)
1248 where
1249 final_kind = mkPiTys binders orig_inner_ki
1250 kind_co = mkNomReflCo final_kind
1252 {-# INLINE flatten_args_slow #-}
1253 -- | Slow path, compared to flatten_args_fast, because this one must track
1254 -- a lifting context.
1255 flatten_args_slow :: [TyCoBinder] -> Kind -> TcTyCoVarSet
1256 -> [Role] -> [Type]
1257 -> FlatM ([Xi], [Coercion], CoercionN)
1258 flatten_args_slow orig_binders orig_inner_ki orig_fvs orig_roles orig_tys
1259 = go [] [] orig_lc orig_binders orig_inner_ki orig_roles orig_tys
1260 where
1261 orig_lc = emptyLiftingContext \$ mkInScopeSet \$ orig_fvs
1263 go :: [Xi] -- Xis accumulator, in reverse order
1264 -> [Coercion] -- Coercions accumulator, in reverse order
1265 -- These are in 1-to-1 correspondence
1266 -> LiftingContext -- mapping from tyvars to flattening coercions
1267 -> [TyCoBinder] -- Unsubsted binders of function's kind
1268 -> Kind -- Unsubsted result kind of function (not a Pi-type)
1269 -> [Role] -- Roles at which to flatten these ...
1270 -> [Type] -- ... unflattened types
1271 -> FlatM ([Xi], [Coercion], CoercionN)
1272 go acc_xis acc_cos lc binders inner_ki _ []
1273 = return (reverse acc_xis, reverse acc_cos, kind_co)
1274 where
1275 final_kind = mkTyCoPiTys binders inner_ki
1276 kind_co = liftCoSubst Nominal lc final_kind
1278 go acc_xis acc_cos lc (binder:binders) inner_ki (role:roles) (ty:tys)
1279 = do { (xi, co) <- case role of
1280 Nominal -> setEqRel NomEq \$
1281 if isNamedTyCoBinder binder
1282 then noBogusCoercions \$ flatten_one ty
1283 else flatten_one ty
1285 Representational -> ASSERT( isAnonTyCoBinder binder )
1286 setEqRel ReprEq \$ flatten_one ty
1288 Phantom -> -- See Note [Phantoms in the flattener]
1289 ASSERT( isAnonTyCoBinder binder )
1290 do { ty <- liftTcS \$ zonkTcType ty
1291 ; return (ty, mkReflCo Phantom ty) }
1293 -- By Note [Flattening] invariant (F2),
1294 -- typeKind(xi) = typeKind(ty). But, it's possible that xi will be
1295 -- used as an argument to a function whose kind is different, if
1296 -- earlier arguments have been flattened to new types. We thus
1297 -- need a coercion (kind_co :: old_kind ~ new_kind).
1298 --
1299 -- The bangs here have been observed to improve performance
1300 -- significantly in optimized builds.
1301 ; let kind_co = mkTcSymCo \$
1302 liftCoSubst Nominal lc (tyCoBinderType binder)
1303 !casted_xi = xi `mkCastTy` kind_co
1304 casted_co = mkTcCoherenceLeftCo role xi kind_co co
1306 -- now, extend the lifting context with the new binding
1307 !new_lc | Just tv <- tyCoBinderVar_maybe binder
1308 = extendLiftingContextAndInScope lc tv casted_co
1309 | otherwise
1310 = lc
1312 ; go (casted_xi : acc_xis)
1313 (casted_co : acc_cos)
1314 new_lc
1315 binders
1316 inner_ki
1317 roles
1318 tys
1319 }
1321 -- See Note [Last case in flatten_args]
1322 go acc_xis acc_cos lc [] inner_ki roles tys
1323 | Just k <- tcGetTyVar_maybe inner_ki
1324 , Just co1 <- liftCoSubstTyVar lc Nominal k
1325 = do { let co1_kind = coercionKind co1
1326 (arg_cos, res_co) = decomposePiCos co1 co1_kind tys
1327 casted_tys = ASSERT2( equalLength tys arg_cos
1328 , ppr tys \$\$ ppr arg_cos )
1329 zipWith mkCastTy tys arg_cos
1330 -- In general decomposePiCos can return fewer cos than tys,
1331 -- but not here; see "If we're at all well-typed..."
1332 -- in Note [Last case in flatten_args]. Hence the ASSERT.
1333 zapped_lc = zapLiftingContext lc
1334 Pair flattened_kind _ = co1_kind
1335 (bndrs, new_inner) = splitPiTys flattened_kind
1337 ; (xis_out, cos_out, res_co_out)
1338 <- go acc_xis acc_cos zapped_lc bndrs new_inner roles casted_tys
1339 -- cos_out :: xis_out ~ casted_tys
1340 -- we need to return cos :: xis_out ~ tys
1341 ; let cos = zipWith3 mkTcGReflRightCo
1342 roles
1343 casted_tys
1344 (map mkTcSymCo arg_cos)
1345 cos' = zipWith mkTransCo cos_out cos
1347 ; return (xis_out, cos', res_co_out `mkTcTransCo` res_co) }
1349 go _ _ _ _ _ _ _ = pprPanic
1350 "flatten_args wandered into deeper water than usual" (vcat [])
1351 -- This debug information is commented out because leaving it in
1352 -- causes a ~2% increase in allocations in T9872d.
1353 -- That's independent of the analagous case in flatten_args_fast:
1354 -- each of these causes a 2% increase on its own, so commenting them
1355 -- both out gives a 4% decrease in T9872d.
1356 {-
1358 (vcat [ppr orig_binders,
1359 ppr orig_inner_ki,
1360 ppr (take 10 orig_roles), -- often infinite!
1361 ppr orig_tys])
1362 -}
1364 ------------------
1365 flatten_one :: TcType -> FlatM (Xi, Coercion)
1366 -- Flatten a type to get rid of type function applications, returning
1367 -- the new type-function-free type, and a collection of new equality
1368 -- constraints. See Note [Flattening] for more detail.
1369 --
1370 -- Postcondition: Coercion :: Xi ~ TcType
1371 -- The role on the result coercion matches the EqRel in the FlattenEnv
1373 flatten_one xi@(LitTy {})
1374 = do { role <- getRole
1375 ; return (xi, mkReflCo role xi) }
1377 flatten_one (TyVarTy tv)
1378 = flattenTyVar tv
1380 flatten_one (AppTy ty1 ty2)
1381 = flatten_app_tys ty1 [ty2]
1383 flatten_one (TyConApp tc tys)
1384 -- Expand type synonyms that mention type families
1385 -- on the RHS; see Note [Flattening synonyms]
1386 | Just (tenv, rhs, tys') <- expandSynTyCon_maybe tc tys
1387 , let expanded_ty = mkAppTys (substTy (mkTvSubstPrs tenv) rhs) tys'
1388 = do { mode <- getMode
1389 ; case mode of
1390 FM_FlattenAll | not (isFamFreeTyCon tc)
1391 -> flatten_one expanded_ty
1392 _ -> flatten_ty_con_app tc tys }
1394 -- Otherwise, it's a type function application, and we have to
1395 -- flatten it away as well, and generate a new given equality constraint
1396 -- between the application and a newly generated flattening skolem variable.
1397 | isTypeFamilyTyCon tc
1398 = flatten_fam_app tc tys
1400 -- For * a normal data type application
1401 -- * data family application
1402 -- we just recursively flatten the arguments.
1403 | otherwise
1404 -- FM_Avoid stuff commented out; see Note [Lazy flattening]
1405 -- , let fmode' = case fmode of -- Switch off the flat_top bit in FM_Avoid
1406 -- FE { fe_mode = FM_Avoid tv _ }
1407 -- -> fmode { fe_mode = FM_Avoid tv False }
1408 -- _ -> fmode
1409 = flatten_ty_con_app tc tys
1411 flatten_one (FunTy ty1 ty2)
1412 = do { (xi1,co1) <- flatten_one ty1
1413 ; (xi2,co2) <- flatten_one ty2
1414 ; role <- getRole
1415 ; return (mkFunTy xi1 xi2, mkFunCo role co1 co2) }
1417 flatten_one ty@(ForAllTy {})
1418 -- TODO (RAE): This is inadequate, as it doesn't flatten the kind of
1419 -- the bound tyvar. Doing so will require carrying around a substitution
1420 -- and the usual substTyVarBndr-like silliness. Argh.
1422 -- We allow for-alls when, but only when, no type function
1423 -- applications inside the forall involve the bound type variables.
1424 = do { let (bndrs, rho) = tcSplitForAllVarBndrs ty
1425 tvs = binderVars bndrs
1426 ; (rho', co) <- setMode FM_SubstOnly \$ flatten_one rho
1427 -- Substitute only under a forall
1428 -- See Note [Flattening under a forall]
1429 ; return (mkForAllTys bndrs rho', mkHomoForAllCos tvs co) }
1431 flatten_one (CastTy ty g)
1432 = do { (xi, co) <- flatten_one ty
1433 ; (g', _) <- flatten_co g
1435 ; role <- getRole
1436 ; return (mkCastTy xi g', castCoercionKind co role xi ty g' g) }
1438 flatten_one (CoercionTy co) = first mkCoercionTy <\$> flatten_co co
1440 -- | "Flatten" a coercion. Really, just zonk it so we can uphold
1441 -- (F1) of Note [Flattening]
1442 flatten_co :: Coercion -> FlatM (Coercion, Coercion)
1443 flatten_co co
1444 = do { co <- liftTcS \$ zonkCo co
1445 ; env_role <- getRole
1446 ; let co' = mkTcReflCo env_role (mkCoercionTy co)
1447 ; return (co, co') }
1449 -- flatten (nested) AppTys
1450 flatten_app_tys :: Type -> [Type] -> FlatM (Xi, Coercion)
1451 -- commoning up nested applications allows us to look up the function's kind
1452 -- only once. Without commoning up like this, we would spend a quadratic amount
1453 -- of time looking up functions' types
1454 flatten_app_tys (AppTy ty1 ty2) tys = flatten_app_tys ty1 (ty2:tys)
1455 flatten_app_tys fun_ty arg_tys
1456 = do { (fun_xi, fun_co) <- flatten_one fun_ty
1457 ; flatten_app_ty_args fun_xi fun_co arg_tys }
1459 -- Given a flattened function (with the coercion produced by flattening) and
1460 -- a bunch of unflattened arguments, flatten the arguments and apply.
1461 -- The coercion argument's role matches the role stored in the FlatM monad.
1462 --
1463 -- The bang patterns used here were observed to improve performance. If you
1464 -- wish to remove them, be sure to check for regeressions in allocations.
1465 flatten_app_ty_args :: Xi -> Coercion -> [Type] -> FlatM (Xi, Coercion)
1466 flatten_app_ty_args fun_xi fun_co []
1467 -- this will be a common case when called from flatten_fam_app, so shortcut
1468 = return (fun_xi, fun_co)
1469 flatten_app_ty_args fun_xi fun_co arg_tys
1470 = do { (xi, co, kind_co) <- case tcSplitTyConApp_maybe fun_xi of
1471 Just (tc, xis) ->
1472 do { let tc_roles = tyConRolesRepresentational tc
1473 arg_roles = dropList xis tc_roles
1474 ; (arg_xis, arg_cos, kind_co)
1475 <- flatten_vector (typeKind fun_xi) arg_roles arg_tys
1477 -- Here, we have fun_co :: T xi1 xi2 ~ ty
1478 -- and we need to apply fun_co to the arg_cos. The problem is
1479 -- that using mkAppCo is wrong because that function expects
1480 -- its second coercion to be Nominal, and the arg_cos might
1481 -- not be. The solution is to use transitivity:
1482 -- T <xi1> <xi2> arg_cos ;; fun_co <arg_tys>
1483 ; eq_rel <- getEqRel
1484 ; let app_xi = mkTyConApp tc (xis ++ arg_xis)
1485 app_co = case eq_rel of
1486 NomEq -> mkAppCos fun_co arg_cos
1487 ReprEq -> mkTcTyConAppCo Representational tc
1488 (zipWith mkReflCo tc_roles xis ++ arg_cos)
1489 `mkTcTransCo`
1490 mkAppCos fun_co (map mkNomReflCo arg_tys)
1491 ; return (app_xi, app_co, kind_co) }
1492 Nothing ->
1493 do { (arg_xis, arg_cos, kind_co)
1494 <- flatten_vector (typeKind fun_xi) (repeat Nominal) arg_tys
1495 ; let arg_xi = mkAppTys fun_xi arg_xis
1496 arg_co = mkAppCos fun_co arg_cos
1497 ; return (arg_xi, arg_co, kind_co) }
1499 ; role <- getRole
1500 ; return (homogenise_result xi co role kind_co) }
1502 flatten_ty_con_app :: TyCon -> [TcType] -> FlatM (Xi, Coercion)
1503 flatten_ty_con_app tc tys
1504 = do { role <- getRole
1505 ; (xis, cos, kind_co) <- flatten_args_tc tc (tyConRolesX role tc) tys
1506 ; let tyconapp_xi = mkTyConApp tc xis
1507 tyconapp_co = mkTyConAppCo role tc cos
1508 ; return (homogenise_result tyconapp_xi tyconapp_co role kind_co) }
1510 -- Make the result of flattening homogeneous (Note [Flattening] (F2))
1511 homogenise_result :: Xi -- a flattened type
1512 -> Coercion -- :: xi ~r original ty
1513 -> Role -- r
1514 -> CoercionN -- kind_co :: typeKind(xi) ~N typeKind(ty)
1515 -> (Xi, Coercion) -- (xi |> kind_co, (xi |> kind_co)
1516 -- ~r original ty)
1517 homogenise_result xi co r kind_co
1518 -- the explicit pattern match here improves the performance of T9872a, b, c by
1519 -- ~2%
1520 | isGReflCo kind_co = (xi `mkCastTy` kind_co, co)
1521 | otherwise = (xi `mkCastTy` kind_co
1522 , (mkSymCo \$ GRefl r xi (MCo kind_co)) `mkTransCo` co)
1523 {-# INLINE homogenise_result #-}
1525 -- Flatten a vector (list of arguments).
1526 flatten_vector :: Kind -- of the function being applied to these arguments
1527 -> [Role] -- If we're flatten w.r.t. ReprEq, what roles do the
1528 -- args have?
1529 -> [Type] -- the args to flatten
1530 -> FlatM ([Xi], [Coercion], CoercionN)
1531 flatten_vector ki roles tys
1532 = do { eq_rel <- getEqRel
1533 ; case eq_rel of
1534 NomEq -> flatten_args bndrs
1535 any_named_bndrs
1536 inner_ki
1537 fvs
1538 (repeat Nominal)
1539 tys
1540 ReprEq -> flatten_args bndrs
1541 any_named_bndrs
1542 inner_ki
1543 fvs
1544 roles
1545 tys
1546 }
1547 where
1548 (bndrs, inner_ki, any_named_bndrs) = split_pi_tys' ki
1549 fvs = tyCoVarsOfType ki
1550 {-# INLINE flatten_vector #-}
1552 {-
1553 Note [Flattening synonyms]
1554 ~~~~~~~~~~~~~~~~~~~~~~~~~~
1555 Not expanding synonyms aggressively improves error messages, and
1556 keeps types smaller. But we need to take care.
1558 Suppose
1559 type T a = a -> a
1560 and we want to flatten the type (T (F a)). Then we can safely flatten
1561 the (F a) to a skolem, and return (T fsk). We don't need to expand the
1562 synonym. This works because TcTyConAppCo can deal with synonyms
1563 (unlike TyConAppCo), see Note [TcCoercions] in TcEvidence.
1565 But (Trac #8979) for
1566 type T a = (F a, a) where F is a type function
1567 we must expand the synonym in (say) T Int, to expose the type function
1568 to the flattener.
1571 Note [Flattening under a forall]
1572 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1573 Under a forall, we
1574 (a) MUST apply the inert substitution
1575 (b) MUST NOT flatten type family applications
1576 Hence FMSubstOnly.
1578 For (a) consider c ~ a, a ~ T (forall b. (b, [c]))
1579 If we don't apply the c~a substitution to the second constraint
1580 we won't see the occurs-check error.
1582 For (b) consider (a ~ forall b. F a b), we don't want to flatten
1583 to (a ~ forall b.fsk, F a b ~ fsk)
1584 because now the 'b' has escaped its scope. We'd have to flatten to
1585 (a ~ forall b. fsk b, forall b. F a b ~ fsk b)
1586 and we have not begun to think about how to make that work!
1588 ************************************************************************
1589 * *
1590 Flattening a type-family application
1591 * *
1592 ************************************************************************
1593 -}
1595 flatten_fam_app :: TyCon -> [TcType] -> FlatM (Xi, Coercion)
1596 -- flatten_fam_app can be over-saturated
1597 -- flatten_exact_fam_app is exactly saturated
1598 -- flatten_exact_fam_app_fully lifts out the application to top level
1599 -- Postcondition: Coercion :: Xi ~ F tys
1600 flatten_fam_app tc tys -- Can be over-saturated
1601 = ASSERT2( tys `lengthAtLeast` tyConArity tc
1602 , ppr tc \$\$ ppr (tyConArity tc) \$\$ ppr tys)
1604 do { mode <- getMode
1605 ; case mode of
1606 { FM_SubstOnly -> flatten_ty_con_app tc tys
1607 ; FM_FlattenAll ->
1609 -- Type functions are saturated
1610 -- The type function might be *over* saturated
1611 -- in which case the remaining arguments should
1612 -- be dealt with by AppTys
1613 do { let (tys1, tys_rest) = splitAt (tyConArity tc) tys
1614 ; (xi1, co1) <- flatten_exact_fam_app_fully tc tys1
1615 -- co1 :: xi1 ~ F tys1
1617 ; flatten_app_ty_args xi1 co1 tys_rest } } }
1619 -- the [TcType] exactly saturate the TyCon
1620 -- See note [flatten_exact_fam_app_fully performance]
1621 flatten_exact_fam_app_fully :: TyCon -> [TcType] -> FlatM (Xi, Coercion)
1622 flatten_exact_fam_app_fully tc tys
1623 -- See Note [Reduce type family applications eagerly]
1624 -- the following typeKind should never be evaluated, as it's just used in
1625 -- casting, and casts by refl are dropped
1626 = do { let reduce_co = mkNomReflCo (typeKind (mkTyConApp tc tys))
1627 ; mOut <- try_to_reduce_nocache tc tys reduce_co id
1628 ; case mOut of
1629 Just out -> pure out
1630 Nothing -> do
1631 { -- First, flatten the arguments
1632 ; (xis, cos, kind_co)
1633 <- setEqRel NomEq \$ -- just do this once, instead of for
1634 -- each arg
1635 flatten_args_tc tc (repeat Nominal) tys
1636 -- kind_co :: typeKind(F xis) ~N typeKind(F tys)
1637 ; eq_rel <- getEqRel
1638 ; cur_flav <- getFlavour
1639 ; let role = eqRelRole eq_rel
1640 ret_co = mkTyConAppCo role tc cos
1641 -- ret_co :: F xis ~ F tys; might be heterogeneous
1643 -- Now, look in the cache
1644 ; mb_ct <- liftTcS \$ lookupFlatCache tc xis
1645 ; case mb_ct of
1646 Just (co, rhs_ty, flav) -- co :: F xis ~ fsk
1647 -- flav is [G] or [WD]
1648 -- See Note [Type family equations] in TcSMonad
1649 | (NotSwapped, _) <- flav `funEqCanDischargeF` cur_flav
1650 -> -- Usable hit in the flat-cache
1651 do { traceFlat "flatten/flat-cache hit" \$
1652 (ppr tc <+> ppr xis \$\$ ppr rhs_ty)
1653 ; (fsk_xi, fsk_co) <- flatten_one rhs_ty
1654 -- The fsk may already have been unified, so
1655 -- flatten it
1656 -- fsk_co :: fsk_xi ~ fsk
1657 ; let xi = fsk_xi `mkCastTy` kind_co
1658 co' = mkTcCoherenceLeftCo role fsk_xi kind_co fsk_co
1659 `mkTransCo`
1660 maybeSubCo eq_rel (mkSymCo co)
1661 `mkTransCo` ret_co
1662 ; return (xi, co')
1663 }
1664 -- :: fsk_xi ~ F xis
1666 -- Try to reduce the family application right now
1667 -- See Note [Reduce type family applications eagerly]
1668 _ -> do { mOut <- try_to_reduce tc
1669 xis
1670 kind_co
1671 (`mkTransCo` ret_co)
1672 ; case mOut of
1673 Just out -> pure out
1674 Nothing -> do
1675 { loc <- getLoc
1676 ; (ev, co, fsk) <- liftTcS \$
1677 newFlattenSkolem cur_flav loc tc xis
1679 -- The new constraint (F xis ~ fsk) is not
1680 -- necessarily inert (e.g. the LHS may be a
1681 -- redex) so we must put it in the work list
1682 ; let ct = CFunEqCan { cc_ev = ev
1683 , cc_fun = tc
1684 , cc_tyargs = xis
1685 , cc_fsk = fsk }
1686 ; emitFlatWork ct
1688 ; traceFlat "flatten/flat-cache miss" \$
1689 (ppr tc <+> ppr xis \$\$ ppr fsk \$\$ ppr ev)
1691 -- NB: fsk's kind is already flattened because
1692 -- the xis are flattened
1693 ; let fsk_ty = mkTyVarTy fsk
1694 xi = fsk_ty `mkCastTy` kind_co
1695 co' = mkTcCoherenceLeftCo role fsk_ty kind_co (maybeSubCo eq_rel (mkSymCo co))
1696 `mkTransCo` ret_co
1697 ; return (xi, co')
1698 }
1699 }
1700 }
1701 }
1703 where
1705 -- try_to_reduce and try_to_reduce_nocache (below) could be unified into
1706 -- a more general definition, but it was observed that separating them
1707 -- gives better performance (lower allocation numbers in T9872x).
1709 try_to_reduce :: TyCon -- F, family tycon
1710 -> [Type] -- args, not necessarily flattened
1711 -> CoercionN -- kind_co :: typeKind(F args) ~N
1712 -- typeKind(F orig_args)
1713 -- where
1714 -- orig_args is what was passed to the outer
1715 -- function
1716 -> ( Coercion -- :: (xi |> kind_co) ~ F args
1717 -> Coercion ) -- what to return from outer function
1718 -> FlatM (Maybe (Xi, Coercion))
1719 try_to_reduce tc tys kind_co update_co
1720 = do { checkStackDepth (mkTyConApp tc tys)
1721 ; mb_match <- liftTcS \$ matchFam tc tys
1722 ; case mb_match of
1723 -- NB: norm_co will always be homogeneous. All type families
1724 -- are homogeneous.
1725 Just (norm_co, norm_ty)
1726 -> do { traceFlat "Eager T.F. reduction success" \$
1727 vcat [ ppr tc, ppr tys, ppr norm_ty
1728 , ppr norm_co <+> dcolon
1729 <+> ppr (coercionKind norm_co)
1730 ]
1731 ; (xi, final_co) <- bumpDepth \$ flatten_one norm_ty
1732 ; eq_rel <- getEqRel
1733 ; let co = maybeSubCo eq_rel norm_co
1734 `mkTransCo` mkSymCo final_co
1735 ; flavour <- getFlavour
1736 -- NB: only extend cache with nominal equalities
1737 ; when (eq_rel == NomEq) \$
1738 liftTcS \$
1739 extendFlatCache tc tys ( co, xi, flavour )
1740 ; let role = eqRelRole eq_rel
1741 xi' = xi `mkCastTy` kind_co
1742 co' = update_co \$
1743 mkTcCoherenceLeftCo role xi kind_co (mkSymCo co)
1744 ; return \$ Just (xi', co') }
1745 Nothing -> pure Nothing }
1747 try_to_reduce_nocache :: TyCon -- F, family tycon
1748 -> [Type] -- args, not necessarily flattened
1749 -> CoercionN -- kind_co :: typeKind(F args)
1750 -- ~N typeKind(F orig_args)
1751 -- where
1752 -- orig_args is what was passed to the
1753 -- outer function
1754 -> ( Coercion -- :: (xi |> kind_co) ~ F args
1755 -> Coercion ) -- what to return from outer
1756 -- function
1757 -> FlatM (Maybe (Xi, Coercion))
1758 try_to_reduce_nocache tc tys kind_co update_co
1759 = do { checkStackDepth (mkTyConApp tc tys)
1760 ; mb_match <- liftTcS \$ matchFam tc tys
1761 ; case mb_match of
1762 -- NB: norm_co will always be homogeneous. All type families
1763 -- are homogeneous.
1764 Just (norm_co, norm_ty)
1765 -> do { (xi, final_co) <- bumpDepth \$ flatten_one norm_ty
1766 ; eq_rel <- getEqRel
1767 ; let co = maybeSubCo eq_rel norm_co
1768 `mkTransCo` mkSymCo final_co
1769 role = eqRelRole eq_rel
1770 xi' = xi `mkCastTy` kind_co
1771 co' = update_co \$
1772 mkTcCoherenceLeftCo role xi kind_co (mkSymCo co)
1773 ; return \$ Just (xi', co') }
1774 Nothing -> pure Nothing }
1776 {- Note [Reduce type family applications eagerly]
1777 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1778 If we come across a type-family application like (Append (Cons x Nil) t),
1779 then, rather than flattening to a skolem etc, we may as well just reduce
1780 it on the spot to (Cons x t). This saves a lot of intermediate steps.
1781 Examples that are helped are tests T9872, and T5321Fun.
1783 Performance testing indicates that it's best to try this *twice*, once
1784 before flattening arguments and once after flattening arguments.
1785 Adding the extra reduction attempt before flattening arguments cut
1786 the allocation amounts for the T9872{a,b,c} tests by half.
1788 An example of where the early reduction appears helpful:
1790 type family Last x where
1791 Last '[x] = x
1792 Last (h ': t) = Last t
1794 workitem: (x ~ Last '[1,2,3,4,5,6])
1796 Flattening the argument never gets us anywhere, but trying to flatten
1797 it at every step is quadratic in the length of the list. Reducing more
1798 eagerly makes simplifying the right-hand type linear in its length.
1800 Testing also indicated that the early reduction should *not* use the
1801 flat-cache, but that the later reduction *should*. (Although the
1802 effect was not large.) Hence the Bool argument to try_to_reduce. To
1803 me (SLPJ) this seems odd; I get that eager reduction usually succeeds;
1804 and if don't use the cache for eager reduction, we will miss most of
1805 the opportunities for using it at all. More exploration would be good
1806 here.
1808 At the end, once we've got a flat rhs, we extend the flatten-cache to record
1809 the result. Doing so can save lots of work when the same redex shows up more
1810 than once. Note that we record the link from the redex all the way to its
1811 *final* value, not just the single step reduction. Interestingly, using the
1812 flat-cache for the first reduction resulted in an increase in allocations
1813 of about 3% for the four T9872x tests. However, using the flat-cache in
1814 the later reduction is a similar gain. I (Richard E) don't currently (Dec '14)
1815 have any knowledge as to *why* these facts are true.
1817 ************************************************************************
1818 * *
1819 Flattening a type variable
1820 * *
1821 ********************************************************************* -}
1823 -- | The result of flattening a tyvar "one step".
1824 data FlattenTvResult
1825 = FTRNotFollowed
1826 -- ^ The inert set doesn't make the tyvar equal to anything else
1828 | FTRFollowed TcType Coercion
1829 -- ^ The tyvar flattens to a not-necessarily flat other type.
1830 -- co :: new type ~r old type, where the role is determined by
1831 -- the FlattenEnv
1833 flattenTyVar :: TyVar -> FlatM (Xi, Coercion)
1834 flattenTyVar tv
1835 = do { mb_yes <- flatten_tyvar1 tv
1836 ; case mb_yes of
1837 FTRFollowed ty1 co1 -- Recur
1838 -> do { (ty2, co2) <- flatten_one ty1
1839 -- ; traceFlat "flattenTyVar2" (ppr tv \$\$ ppr ty2)
1840 ; return (ty2, co2 `mkTransCo` co1) }
1842 FTRNotFollowed -- Done, but make sure the kind is zonked
1843 -- Note [Flattening] invariant (F1)
1844 -> do { tv' <- liftTcS \$ updateTyVarKindM zonkTcType tv
1845 ; role <- getRole
1846 ; let ty' = mkTyVarTy tv'
1847 ; return (ty', mkTcReflCo role ty') } }
1849 flatten_tyvar1 :: TcTyVar -> FlatM FlattenTvResult
1850 -- "Flattening" a type variable means to apply the substitution to it
1851 -- Specifically, look up the tyvar in
1852 -- * the internal MetaTyVar box
1853 -- * the inerts
1856 flatten_tyvar1 tv
1857 = do { mb_ty <- liftTcS \$ isFilledMetaTyVar_maybe tv
1858 ; case mb_ty of
1859 Just ty -> do { traceFlat "Following filled tyvar"
1860 (ppr tv <+> equals <+> ppr ty)
1861 ; role <- getRole
1862 ; return (FTRFollowed ty (mkReflCo role ty)) } ;
1863 Nothing -> do { traceFlat "Unfilled tyvar" (ppr tv)
1864 ; fr <- getFlavourRole
1865 ; flatten_tyvar2 tv fr } }
1867 flatten_tyvar2 :: TcTyVar -> CtFlavourRole -> FlatM FlattenTvResult
1868 -- The tyvar is not a filled-in meta-tyvar
1869 -- Try in the inert equalities
1870 -- See Definition [Applying a generalised substitution] in TcSMonad
1871 -- See Note [Stability of flattening] in TcSMonad
1873 flatten_tyvar2 tv fr@(_, eq_rel)
1874 = do { ieqs <- liftTcS \$ getInertEqs
1875 ; mode <- getMode
1876 ; case lookupDVarEnv ieqs tv of
1877 Just (ct:_) -- If the first doesn't work,
1878 -- the subsequent ones won't either
1879 | CTyEqCan { cc_ev = ctev, cc_tyvar = tv
1880 , cc_rhs = rhs_ty, cc_eq_rel = ct_eq_rel } <- ct
1881 , let ct_fr = (ctEvFlavour ctev, ct_eq_rel)
1882 , ct_fr `eqCanRewriteFR` fr -- This is THE key call of eqCanRewriteFR
1883 -> do { traceFlat "Following inert tyvar"
1884 (ppr mode <+>
1885 ppr tv <+>
1886 equals <+>
1887 ppr rhs_ty \$\$ ppr ctev)
1888 ; let rewrite_co1 = mkSymCo (ctEvCoercion ctev)
1889 rewrite_co = case (ct_eq_rel, eq_rel) of
1890 (ReprEq, _rel) -> ASSERT( _rel == ReprEq )
1891 -- if this ASSERT fails, then
1893 rewrite_co1
1894 (NomEq, NomEq) -> rewrite_co1
1895 (NomEq, ReprEq) -> mkSubCo rewrite_co1
1897 ; return (FTRFollowed rhs_ty rewrite_co) }
1898 -- NB: ct is Derived then fmode must be also, hence
1899 -- we are not going to touch the returned coercion
1900 -- so ctEvCoercion is fine.
1902 _other -> return FTRNotFollowed }
1904 {-
1905 Note [An alternative story for the inert substitution]
1906 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1907 (This entire note is just background, left here in case we ever want
1908 to return the previous state of affairs)
1910 We used (GHC 7.8) to have this story for the inert substitution inert_eqs
1912 * 'a' is not in fvs(ty)
1913 * They are *inert* in the weaker sense that there is no infinite chain of
1914 (i1 `eqCanRewrite` i2), (i2 `eqCanRewrite` i3), etc
1916 This means that flattening must be recursive, but it does allow
1917 [G] a ~ [b]
1918 [G] b ~ Maybe c
1920 This avoids "saturating" the Givens, which can save a modest amount of work.
1921 It is easy to implement, in TcInteract.kick_out, by only kicking out an inert
1922 only if (a) the work item can rewrite the inert AND
1923 (b) the inert cannot rewrite the work item
1925 This is significantly harder to think about. It can save a LOT of work
1926 in occurs-check cases, but we don't care about them much. Trac #5837
1927 is an example; all the constraints here are Givens
1929 [G] a ~ TF (a,Int)
1930 -->
1931 work TF (a,Int) ~ fsk
1932 inert fsk ~ a
1934 --->
1935 work fsk ~ (TF a, TF Int)
1936 inert fsk ~ a
1938 --->
1939 work a ~ (TF a, TF Int)
1940 inert fsk ~ a
1942 ---> (attempting to flatten (TF a) so that it does not mention a
1943 work TF a ~ fsk2
1944 inert a ~ (fsk2, TF Int)
1945 inert fsk ~ (fsk2, TF Int)
1947 ---> (substitute for a)
1948 work TF (fsk2, TF Int) ~ fsk2
1949 inert a ~ (fsk2, TF Int)
1950 inert fsk ~ (fsk2, TF Int)
1952 ---> (top-level reduction, re-orient)
1953 work fsk2 ~ (TF fsk2, TF Int)
1954 inert a ~ (fsk2, TF Int)
1955 inert fsk ~ (fsk2, TF Int)
1957 ---> (attempt to flatten (TF fsk2) to get rid of fsk2
1958 work TF fsk2 ~ fsk3
1959 work fsk2 ~ (fsk3, TF Int)
1960 inert a ~ (fsk2, TF Int)
1961 inert fsk ~ (fsk2, TF Int)
1963 --->
1964 work TF fsk2 ~ fsk3
1965 inert fsk2 ~ (fsk3, TF Int)
1966 inert a ~ ((fsk3, TF Int), TF Int)
1967 inert fsk ~ ((fsk3, TF Int), TF Int)
1969 Because the incoming given rewrites all the inert givens, we get more and
1970 more duplication in the inert set. But this really only happens in pathalogical
1971 casee, so we don't care.
1974 ************************************************************************
1975 * *
1976 Unflattening
1977 * *
1978 ************************************************************************
1980 An unflattening example:
1981 [W] F a ~ alpha
1982 flattens to
1983 [W] F a ~ fmv (CFunEqCan)
1984 [W] fmv ~ alpha (CTyEqCan)
1985 We must solve both!
1986 -}
1988 unflattenWanteds :: Cts -> Cts -> TcS Cts
1989 unflattenWanteds tv_eqs funeqs
1990 = do { tclvl <- getTcLevel
1992 ; traceTcS "Unflattening" \$ braces \$
1993 vcat [ text "Funeqs =" <+> pprCts funeqs
1994 , text "Tv eqs =" <+> pprCts tv_eqs ]
1996 -- Step 1: unflatten the CFunEqCans, except if that causes an occurs check
1997 -- Occurs check: consider [W] alpha ~ [F alpha]
1998 -- ==> (flatten) [W] F alpha ~ fmv, [W] alpha ~ [fmv]
1999 -- ==> (unify) [W] F [fmv] ~ fmv
2000 -- See Note [Unflatten using funeqs first]
2001 ; funeqs <- foldrBagM unflatten_funeq emptyCts funeqs
2002 ; traceTcS "Unflattening 1" \$ braces (pprCts funeqs)
2004 -- Step 2: unify the tv_eqs, if possible
2005 ; tv_eqs <- foldrBagM (unflatten_eq tclvl) emptyCts tv_eqs
2006 ; traceTcS "Unflattening 2" \$ braces (pprCts tv_eqs)
2008 -- Step 3: fill any remaining fmvs with fresh unification variables
2009 ; funeqs <- mapBagM finalise_funeq funeqs
2010 ; traceTcS "Unflattening 3" \$ braces (pprCts funeqs)
2012 -- Step 4: remove any tv_eqs that look like ty ~ ty
2013 ; tv_eqs <- foldrBagM finalise_eq emptyCts tv_eqs
2015 ; let all_flat = tv_eqs `andCts` funeqs
2016 ; traceTcS "Unflattening done" \$ braces (pprCts all_flat)
2018 ; return all_flat }
2019 where
2020 ----------------
2021 unflatten_funeq :: Ct -> Cts -> TcS Cts
2022 unflatten_funeq ct@(CFunEqCan { cc_fun = tc, cc_tyargs = xis
2023 , cc_fsk = fmv, cc_ev = ev }) rest
2024 = do { -- fmv should be an un-filled flatten meta-tv;
2025 -- we now fix its final value by filling it, being careful
2026 -- to observe the occurs check. Zonking will eliminate it
2027 -- altogether in due course
2028 rhs' <- zonkTcType (mkTyConApp tc xis)
2029 ; case occCheckExpand [fmv] rhs' of
2030 Just rhs'' -- Normal case: fill the tyvar
2031 -> do { setReflEvidence ev NomEq rhs''
2032 ; unflattenFmv fmv rhs''
2033 ; return rest }
2035 Nothing -> -- Occurs check
2036 return (ct `consCts` rest) }
2038 unflatten_funeq other_ct _
2039 = pprPanic "unflatten_funeq" (ppr other_ct)
2041 ----------------
2042 finalise_funeq :: Ct -> TcS Ct
2043 finalise_funeq (CFunEqCan { cc_fsk = fmv, cc_ev = ev })
2044 = do { demoteUnfilledFmv fmv
2045 ; return (mkNonCanonical ev) }
2046 finalise_funeq ct = pprPanic "finalise_funeq" (ppr ct)
2048 ----------------
2049 unflatten_eq :: TcLevel -> Ct -> Cts -> TcS Cts
2050 unflatten_eq tclvl ct@(CTyEqCan { cc_ev = ev, cc_tyvar = tv
2051 , cc_rhs = rhs, cc_eq_rel = eq_rel }) rest
2053 | NomEq <- eq_rel -- See Note [Do not unify representational equalities]
2054 -- in TcInteract
2055 , isFmvTyVar tv -- Previously these fmvs were untouchable,
2056 -- but now they are touchable
2057 -- NB: unlike unflattenFmv, filling a fmv here /does/
2058 -- bump the unification count; it is "improvement"
2059 -- Note [Unflattening can force the solver to iterate]
2060 = ASSERT2( tyVarKind tv `eqType` typeKind rhs, ppr ct )
2061 -- CTyEqCan invariant should ensure this is true
2062 do { is_filled <- isFilledMetaTyVar tv
2063 ; elim <- case is_filled of
2064 False -> do { traceTcS "unflatten_eq 2" (ppr ct)
2065 ; tryFill ev tv rhs }
2066 True -> do { traceTcS "unflatten_eq 3" (ppr ct)
2067 ; try_fill_rhs ev tclvl tv rhs }
2068 ; if elim
2069 then do { setReflEvidence ev eq_rel (mkTyVarTy tv)
2070 ; return rest }
2071 else return (ct `consCts` rest) }
2073 | otherwise
2074 = return (ct `consCts` rest)
2076 unflatten_eq _ ct _ = pprPanic "unflatten_irred" (ppr ct)
2078 ----------------
2079 try_fill_rhs ev tclvl lhs_tv rhs
2080 -- Constraint is lhs_tv ~ rhs_tv,
2081 -- and lhs_tv is filled, so try RHS
2082 | Just (rhs_tv, co) <- getCastedTyVar_maybe rhs
2083 -- co :: kind(rhs_tv) ~ kind(lhs_tv)
2084 , isFmvTyVar rhs_tv || (isTouchableMetaTyVar tclvl rhs_tv
2085 && not (isTyVarTyVar rhs_tv))
2086 -- LHS is a filled fmv, and so is a type
2087 -- family application, which a TyVarTv should
2088 -- not unify with
2089 = do { is_filled <- isFilledMetaTyVar rhs_tv
2090 ; if is_filled then return False
2091 else tryFill ev rhs_tv
2092 (mkTyVarTy lhs_tv `mkCastTy` mkSymCo co) }
2094 | otherwise
2095 = return False
2097 ----------------
2098 finalise_eq :: Ct -> Cts -> TcS Cts
2099 finalise_eq (CTyEqCan { cc_ev = ev, cc_tyvar = tv
2100 , cc_rhs = rhs, cc_eq_rel = eq_rel }) rest
2101 | isFmvTyVar tv
2102 = do { ty1 <- zonkTcTyVar tv
2103 ; rhs' <- zonkTcType rhs
2104 ; if ty1 `tcEqType` rhs'
2105 then do { setReflEvidence ev eq_rel rhs'
2106 ; return rest }
2107 else return (mkNonCanonical ev `consCts` rest) }
2109 | otherwise
2110 = return (mkNonCanonical ev `consCts` rest)
2112 finalise_eq ct _ = pprPanic "finalise_irred" (ppr ct)
2114 tryFill :: CtEvidence -> TcTyVar -> TcType -> TcS Bool
2115 -- (tryFill tv rhs ev) assumes 'tv' is an /un-filled/ MetaTv
2116 -- If tv does not appear in 'rhs', it set tv := rhs,
2117 -- binds the evidence (which should be a CtWanted) to Refl<rhs>
2118 -- and return True. Otherwise returns False
2119 tryFill ev tv rhs
2120 = ASSERT2( not (isGiven ev), ppr ev )
2121 do { rhs' <- zonkTcType rhs
2122 ; case () of
2123 _ | Just tv' <- tcGetTyVar_maybe rhs'
2124 , tv == tv' -- tv == rhs
2125 -> return True
2127 _ | Just rhs'' <- occCheckExpand [tv] rhs'
2128 -> do { -- Fill the tyvar
2129 unifyTyVar tv rhs''
2130 ; return True }
2132 _ | otherwise -- Occurs check
2133 -> return False
2134 }
2136 setReflEvidence :: CtEvidence -> EqRel -> TcType -> TcS ()
2137 setReflEvidence ev eq_rel rhs
2138 = setEvBindIfWanted ev (evCoercion refl_co)
2139 where
2140 refl_co = mkTcReflCo (eqRelRole eq_rel) rhs
2142 {-
2143 Note [Unflatten using funeqs first]
2144 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2145 [W] G a ~ Int
2146 [W] F (G a) ~ G a
2148 do not want to end up with
2149 [W] F Int ~ Int
2150 because that might actually hold! Better to end up with the two above
2151 unsolved constraints. The flat form will be
2153 G a ~ fmv1 (CFunEqCan)
2154 F fmv1 ~ fmv2 (CFunEqCan)
2155 fmv1 ~ Int (CTyEqCan)
2156 fmv1 ~ fmv2 (CTyEqCan)
2158 Flatten using the fun-eqs first.
2159 -}
2161 -- | Like 'splitPiTys'' but comes with a 'Bool' which is 'True' iff there is at
2162 -- least one named binder.
2163 split_pi_tys' :: Type -> ([TyCoBinder], Type, Bool)
2164 split_pi_tys' ty = split ty ty
2165 where
2166 split orig_ty ty | Just ty' <- coreView ty = split orig_ty ty'
2167 split _ (ForAllTy b res) = let (bs, ty, _) = split res res
2168 in (Named b : bs, ty, True)
2169 split _ (FunTy arg res) = let (bs, ty, named) = split res res
2170 in (Anon arg : bs, ty, named)
2171 split orig_ty _ = ([], orig_ty, False)
2172 {-# INLINE split_pi_tys' #-}
2174 -- | Like 'tyConBindersTyCoBinders' but you also get a 'Bool' which is true iff
2175 -- there is at least one named binder.
2176 ty_con_binders_ty_binders' :: [TyConBinder] -> ([TyCoBinder], Bool)
2177 ty_con_binders_ty_binders' = foldr go ([], False)
2178 where
2179 go (Bndr tv (NamedTCB vis)) (bndrs, _)
2180 = (Named (Bndr tv vis) : bndrs, True)
2181 go (Bndr tv AnonTCB) (bndrs, n)
2182 = (Anon (tyVarKind tv) : bndrs, n)
2183 {-# INLINE go #-}
2184 {-# INLINE ty_con_binders_ty_binders' #-}