+      "BROKEN_TESTS": "encoding004 T10458 simd009 T25169",

+      "BROKEN_TESTS": "encoding004 T10458 simd009 T25169",

+      "BROKEN_TESTS": "encoding004 T10458 simd009 T25169",

+-- NB: but NOT true of (s ~ t) or (s ~~ t) or (Coercible s t)

+        ErrorMsgType, pprUserTypeErrorTy,

+import GHC.Data.Maybe   ( orElse, isJust )

+    -- Here, we want any nested TypeErrors to bubble up, even if they are

+    -- inside type family applications, so we pass 'True' to

+    -- 'containsUserTypeError'.

+    is_user_type_error item _ = containsUserTypeError True (errorItemPred item)

+      -- True <=> look under ty-fam apps, AppTy etc.

+      -- See (UTE2) in Note [Custom type errors in constraints].

+     We don't go looking for Unsatisfiable constraints deeply nested inside

+     a type like we do for TypeError.

+

+

+  | Just msg <- userTypeError_maybe True pty

+      --                            ^^^^

+      -- Look under type-family applications! We are reporting an error,

+      -- so we may as well look to see if there are any custom type errors

+      -- anywhere, as they might be helpful to the user. We gave the type

+      -- family application the chance to reduce, but it didn't.

+      --

+      -- See (UTE2) in Note [Custom type errors in constraints] in GHC.Tc.Types.Constraint.

+  = UserTypeError msg

+Failing to do so proved quite inconvenient for users, as evidenced by the

+To do this, tcCheckGivens calls getInertInsols, which returns all Given

+constraints that are definitely insoluble. See Note [When is a constraint insoluble?].

+

+Note [When is a constraint insoluble?]

+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+Whether a constraint is insoluble matters for accurate pattern-match

+warnings, as explained in Note [Pattern match warnings with insoluble Givens].

+

+We consider a constraint to be insoluble if it definitely cannot be solved,

+no matter what information we might further discover. For example, the following

+constraints are insoluble:

+

+  - TypeError msg

+  - TypeError msg ~ Int

+  - Unsatisfiable msg

+

+Many constraints that look like they can't be solved are in fact not reported

+as insoluble, as there might still be a possibility (no matter how remote) that

+they can still be solved:

+

+  1: Show (Int -> Int)

+

+  Reason: even though there is no relevant instance in scope, this constraint

+  could later get solved by a new instance.

+

+  2: C (Int ~ Bool), where C :: Constraint -> Constraint

+

+  Reason: even though 'Int ~ Bool' is insoluble, the constraint 'C (Int ~ Bool)'

+  might be soluble, e.g. if 'C' is a class and we have 'instance forall c. C c',

+  or 'C' is a type family and we have 'type instance C c = (() :: Constraint)'.

+

+  3: Nested occurences of TypeError don't always lead to insolubility. For

+     example, none of the following constraints are definitely insoluble:

+

+    (a) F alpha (TypeError msg)    -- 'F' is an arity 2 type family

+    (b) Eq (TypeError msg)

+    (c) c (TypeError msg)          -- 'c' is a metavariable

+    (d) (TC alpha) (TypeError msg) -- 'TC' is an arity 1 type family

+    (e) TypeError msg ~ rhs        -- (depends on rhs)

+

+  None of these constraints are definitely insoluble:

+

+    (a) Can be solved if 'F' reduces, e.g. 'alpha := Int', 'type instance F Int a = (() :: Constraint)'.

+    (b) Can be solved by 'instance forall x. Eq x'.

+    (c) Can be solved if 'c' unifies with 'C', as in example (2).

+    (d) Can be solved if 'TC alpha' reduces to 'C', as in example (2).

+    (e) If 'rhs' is a rigid type such as 'Int' or 'Maybe Char', then this

+        constraint is definitely insoluble. Otherwise, however, the constraint

+        could be soluble:

+          - rhs = G alpha, for an arity 1 type family G

+            G alpha could reduce to TypeError msg.

+          - rhs = k, for a skolem type variable k.

+            We could instantiate k to something else, and then the constraint

+            could become soluble.

+

+  For this reason, we are careful to not pull out certain occurrences of TypeError,

+  e.g. inside type family applications and class constraints.

+  See Note [Custom type errors in constraints].

+import GHC.Builtin.Names ( callStackTyConName, exceptionContextTyConName )

+import GHC.LanguageExtensions as LangExt

+import GHC.Rename.Env

+import qualified GHC.Rename.Env as TcM

+

+import GHC.Unit.Module.Graph

+import qualified Data.Set as Set

+--  - constraints that are custom type errors, of the form

+--    @TypeError msg@ or @Maybe (TypeError msg)@, but not constraints such as

+--    @F x (TypeError msg)@ in which the type error is nested under

+--    a type family application,

+  -- See Note [When is a constraint insoluble?]

+  = do { inert_cts <- getInertCts

+       ; return $ filterBag insolubleCt inert_cts }

+

+getInertCts :: TcS Cts

+getInertCts

+  = do { inerts <- getInertCans

+       ; return $

+          unionManyBags

+            [ fmap CIrredCan $ inert_irreds inerts

+            , foldDicts  (consBag . CDictCan) (inert_dicts  inerts) emptyBag

+            , foldFunEqs (consBag . CEqCan  ) (inert_funeqs inerts) emptyBag

+            , foldTyEqs  (consBag . CEqCan  ) (inert_eqs    inerts) emptyBag

+            ] }

+  = do { all_cts <- getInertCts

+       ; return (filter isGivenCt $ bagToList all_cts) }

+    is_type_error id = containsUserTypeError False (idType id)

+      -- False <=> do not look under ty-fam apps, AppTy etc.

+      -- See (UTE1) in Note [Custom type errors in constraints].

+{-# LANGUAGE MultiWayIf #-}

+        userTypeError_maybe, containsUserTypeError,

+        insolubleWantedCt, insolubleCt,

+import GHC.Core.TyCo.Rep

+import Control.Monad ( when )

+import Data.List  ( intersperse )

+import GHC.Data.Maybe ( firstJust, firstJusts )

+import qualified Data.Semigroup as S

+-- | Is this a definitely insoluble Wanted constraint? Namely:

+--

+--   - a Wanted,

+--   - which is insoluble (as per 'insolubleCt'),

+--   - that does not arise from a Given or a Wanted/Wanted fundep interaction.

+--

+  | CtWanted (WantedCt { ctev_loc = loc, ctev_rewriters = rewriters })

+      <- ctEvidence ct

+  , insolubleCt ct

+      -- It has no rewriters – see (IW1) in Note [Insoluble Wanteds]

+      -- It doesn't arise from a Given – see (IW2) in Note [Insoluble Wanteds]

+      -- It doesn't arise from a W/W fundep interaction – see (IW3) in Note [Insoluble Wanteds]

+-- | Returns True of constraints that are definitely insoluble, including

+-- constraints that include custom type errors, as per (1)

+-- in Note [Custom type errors in constraints].

+-- Can return 'True' for Given constraints, unlike 'insolubleWantedCt'.

+insolubleCt ct

+  | CIrredCan (IrredCt { ir_reason = reason }) <- ct

+  , isInsolubleReason reason

+  = True

+  | isJust $ isUnsatisfiableCt_maybe pred

+  = True

+  | containsUserTypeError False pred

+      -- False <=> do not look under ty-fam apps, AppTy etc.

+      -- See (UTE1) in Note [Custom type errors in constraints].

+  = True

+  | otherwise

+  = False

+  where

+    pred = ctPred ct

+--

+(IW1) We only treat it as insoluble if it has an empty rewriter set.  (See Note

+(IW2) If the Wanted arises from a Given (how can that happen?), don't

+(IW3) If the Wanted came from a Wanted/Wanted fundep interaction, don't

+A custom type error is a type family application 'TypeError msg' where

+'msg :: ErrorMessage', or an Unsatisfiable constraint.

+See Note [Custom type errors] and Note [The Unsatisfiable constraint]

+in GHC.Internal.TypeError.

+

+There are two ways in which the presence of such custom type errors inside a

+type impact GHC's behaviour:

+

+  (UTE1)

+    Constraints that contain a custom type error are considered to be

+    insoluble. This affects pattern-match warnings, as explained in

+    Note [Pattern match warnings with insoluble Givens] in GHC.Tc.Solver.

+

+    This includes examples such as:

+

+      TypeError msg           -- The actual constraint is a type error

+

+      TypeError msg ~# Int    -- Some type was supposed to be Int, but ended up

+                              -- being a type error instead

+

+    However, we must be careful about occurrences of custom type errors

+    nested inside the constraint, as they may not make the constraint

+    insoluble. This is explained in Note [When is a constraint insoluble?]

+    in GHC.Tc.Solver. In particular:

+

+      a. Do not look inside type family applications.

+      b. Do not look inside class constraints.

+      c. Do not look inside AppTy or in arguments of a type family past its arity.

+      d. Only consider 'TypeError msg ~ rhs' to be insoluble if rhs definitely

+         cannot unify with 'TypeError msg', e.g. if 'rhs = Int' the constraint

+         is insoluble, but if 'rhs = k[sk]' then it isn't.

+

+    These subtle cases are tested in T26400b.

+

+    A good use-case for type errors nested under type family applications is

+    described in "Detecting the undetectable" (https://blog.csongor.co.uk/report-stuck-families/)

+    which features:

+       type family Assert (err :: Constraint) (break :: Type -> Type) (a :: k) :: k where

+         Assert _ Dummy _ = Any

+         Assert _ _ k = k

+    and an unsolved constraint like 'Assert (TypeError ...) (F ty1) ty1 ~ ty2'

+    which reports when (F ty1) remains stuck.

+

+  (UTE2)

+    When reporting unsolved constraints, we pull out any custom type errors

+    and report the corresponding message to the user.

+

+    Unlike in (UTE1), we do want to pull out 'TypeError' wherever it occurs

+    inside the type, including inside type-family applications. We tried to

+    solve the constraint, reduce type families etc, but the constraint

+    remained unsolved all the way till the end. Now that we are reporting the

+    error, it makes sense to pull out the 'TypeError' and report the custom

+    error message to the user, as the intention is that this message might

+    be informative.

+

+    Examples:

+

+      Num (TypeError msg)     -- A class constraint is stuck due to a type error

+

+      F (TypeError msg) ~ a   -- A type function failed to evaluate due to a type error

+

+      Eq (F (TypeError msg))  -- Here the type error is nested under a type-function

+                              -- call, which failed to evaluate because of it,

+                              -- and so the `Eq` constraint was unsolved.

+                              -- This may happen when one function calls another

+                              -- and the called function produced a custom type error.

+

+We use a single function, 'userTypeError_maybe', to pull out TypeError according

+to the rules of either (UTE1) or (UTE2), depending on the passed in boolean

+flag to 'userTypeError_maybe': 'False' for (UTE1) and 'True' for (UTE2).

+-- | Does this type contain 'TypeError msg', either at the top-level or

+-- nested within it somewhere?

+--

+-- If so, return the error message.

+--

+-- See Note [Custom type errors in constraints].

+userTypeError_maybe

+  :: Bool -- ^ Look everywhere: inside type-family applications, class constraints, AppTys etc?

+  -> Type

+  -> Maybe ErrorMsgType

+userTypeError_maybe look_everywhere = go

+    go ty

+      | Just ty' <- coreView ty

+      = go ty'

+    go (TyConApp tc tys)

+      | tyConName tc == errorMessageTypeErrorFamName

+      , _kind : msg : _ <- tys

+              -- There may be more than 2 arguments, if the type error is

+              -- used as a type constructor (e.g. at kind `Type -> Type`).

+      = Just msg

+

+      -- (UTE1.d) TypeError msg ~ a is only insoluble if 'a' cannot be a type error

+      | not look_everywhere

+      , tc `hasKey` eqPrimTyConKey || tc `hasKey` eqReprPrimTyConKey

+      , [ ki1, ki2, ty1, ty2 ] <- tys

+      = if | Just msg <- go ki1

+           , isRigidTy ki2

+           -> Just msg

+           | Just msg <- go ki2

+           , isRigidTy ki1

+           -> Just msg

+           | Just msg <- go ty1

+           , isRigidTy ty2

+           -> Just msg

+           | Just msg <- go ty2

+           , isRigidTy ty1

+           -> Just msg

+           | otherwise

+           -> Nothing

+

+      -- (UTE1.a) Don't look under type family applications.

+      | tyConMustBeSaturated tc

+      , not look_everywhere

+      = Nothing

+        -- (UTE1.c) Don't even look in the arguments past the arity of the TyCon.

+

+      -- (UTE1.b) Don't look inside class constraints.

+      | isClassTyCon tc

+      , not look_everywhere

+      = foldr (firstJust . go) Nothing (drop (tyConArity tc) tys)

+      | otherwise

+      = foldr (firstJust . go) Nothing tys

+    go (ForAllTy (Bndr tv _) ty) = go (tyVarKind tv) `firstJust` go ty

+    go (FunTy { ft_mult = mult, ft_arg = arg, ft_res = res })

+      = firstJusts

+          [ go mult

+          , go (typeKind arg)

+          , go (typeKind res)

+          , go arg

+          , go res ]

+    go (AppTy t1 t2)

+      -- (UTE1.c) Don't look inside AppTy.

+      | not look_everywhere

+      = Nothing

+      | otherwise

+      = go t1 `firstJust` go t2

+    go (CastTy ty _co) = go ty

+    go (TyVarTy tv) = go (tyVarKind tv)

+    go (CoercionTy {}) = Nothing

+    go (LitTy {}) = Nothing

+--

+-- See Note [Custom type errors in constraints].

+containsUserTypeError

+  :: Bool -- ^ look inside type-family applications, 'AppTy', etc?

+  -> PredType

+  -> Bool

+containsUserTypeError look_in_famapps pred =

+  isJust (isUnsatisfiableCt_maybe pred)

+    ||

+  isJust (userTypeError_maybe look_in_famapps pred)

+import GHC.Tc.Types.Constraint ( userTypeError_maybe )

+  | Just msg <- userTypeError_maybe False ty

+      --                            ^^^^^

+      -- Don't look under type-family applications! We only want to pull out

+      -- definite errors.

+      --

+      -- See (UTE1) in Note [Custom type errors in constraints] in GHC.Tc.Types.Constraint.

+          -- Currently, we have no way to provide paths to [n]curses libs for

+          -- both - build and target - in cross builds. Thus, we only build it

+          -- for upper stages. As we only use stage0 to build upper stages,

+          -- this should be fine.

+          ++ [ terminfo | not windowsHost, not cross ]

+    haveCurses <- any (/= "") <$> traverse setting [ CursesIncludeDir, CursesLibDir ]

+      , when (cross && haveCurses)

+        [

+          terminfo

+        ]

+    const int MAX_ATTEMPTS = 256;

+    void *bad_allocs[MAX_ATTEMPTS];

+    size_t bad_alloc_lens[MAX_ATTEMPTS];

+    memset(bad_allocs, 0, sizeof(void*) * MAX_ATTEMPTS);

+    memset(bad_alloc_lens, 0, sizeof(size_t) * MAX_ATTEMPTS);

+

+    while (attempt < MAX_ATTEMPTS) {

+            // Free any portion *above* 8GB and hang on to the rest to increase

+            // the likelihood that we get a suitable allocation next iteration.

+            uintptr_t end = (W_) at + *len;

+            bad_allocs[attempt] = at;

+            if (end > minimumAddress) {

+                if (munmap((void *) minimumAddress, end - minimumAddress) < 0) {

+                    sysErrorBelch("unable to release high portion of low memory reservation");

+                }

+                bad_alloc_lens[attempt] = minimumAddress - (W_) at;

+            } else {

+                bad_alloc_lens[attempt] = *len;