Wrap the given expression in the coercion safely, dropping identity coercions and coalescing nested coercions

Wraps the given expression in the source annotation, dropping the annotation if possible.

bindNonRec x r b produces either:

let x = r in b

or:

case r of x { _DEFAULT_ -> b }

depending on whether we have to use a case or let binding for the expression (see needsCaseBinding). It's used by the desugarer to avoid building bindings that give Core Lint a heart attack, although actually the simplifier deals with them perfectly well. See also mkCoreLet

Tests whether we have to use a case rather than let binding for this expression as per the invariants of CoreExpr: see GHC.Core

This guy constructs the value that the scrutinee must have given that you are in one particular branch of a case

Extract the default case alternative

Find the case alternative corresponding to a particular constructor: panics if no such constructor exists

Merge alternatives preserving order; alternatives in the first argument shadow ones in the second

Given:

case (C a b x y) of
       C b x y -> ...

We want to drop the leading type argument of the scrutinee leaving the arguments to match against the pattern

Refine the default alternative to a DataAlt, if there is a unique way to do so. See Note [Refine DEFAULT case alternatives]

Recover the type of a well-typed Core expression. Fails when applied to the actual Type expression as it cannot really be said to have a type

Returns the type of the alternatives right hand side

Returns the type of the first alternative, which should be the same as for all alternatives

Makes a (->) type or an implicit forall type, depending on whether it is given a type variable or a term variable. This is used, for example, when producing the type of a lambda. Always uses Inferred binders.

mkLamType for multiple type or value arguments

exprIsHNF returns true for expressions that are certainly already evaluated to head normal form. This is used to decide whether it's ok to change:

case x of _ -> e

into:

e

and to decide whether it's safe to discard a seq.

So, it does not treat variables as evaluated, unless they say they are. However, it does treat partial applications and constructor applications as values, even if their arguments are non-trivial, provided the argument type is lifted. For example, both of these are values:

(:) (f x) (map f xs)
map (...redex...)

because seq on such things completes immediately.

For unlifted argument types, we have to be careful:

C (f x :: Int#)

Suppose f x diverges; then C (f x) is not a value. However this can't happen: see GHC.Core. This invariant states that arguments of unboxed type must be ok-for-speculation (or trivial).

exprOkForSpeculation returns True of an expression that is:

• Safe to evaluate even if normal order eval might not evaluate the expression at all, or
• Safe not to evaluate even if normal order would do so

It is usually called on arguments of unlifted type, but not always In particular, Simplify.rebuildCase calls it on lifted types when a 'case' is a plain seq. See the example in Note [exprOkForSpeculation: case expressions] below

Precisely, it returns True iff: a) The expression guarantees to terminate, b) soon, c) without causing a write side effect (e.g. writing a mutable variable) d) without throwing a Haskell exception e) without risking an unchecked runtime exception (array out of bounds, divide by zero)

For exprOkForSideEffects the list is the same, but omitting (e).

Note that exprIsHNF implies exprOkForSpeculation exprOkForSpeculation implies exprOkForSideEffects

See Note [PrimOp can_fail and has_side_effects] in GHC.Builtin.PrimOps and Note [Transformations affected by can_fail and has_side_effects]

As an example of the considerations in this test, consider:

let x = case y# +# 1# of { r# -> I# r# }
in E

being translated to:

case y# +# 1# of { r# ->
   let x = I# r#
   in E
}

We can only do this if the y + 1 is ok for speculation: it has no side effects, and can't diverge or raise an exception.

exprOkForSpeculation returns True of an expression that is:

• Safe to evaluate even if normal order eval might not evaluate the expression at all, or
• Safe not to evaluate even if normal order would do so

It is usually called on arguments of unlifted type, but not always In particular, Simplify.rebuildCase calls it on lifted types when a 'case' is a plain seq. See the example in Note [exprOkForSpeculation: case expressions] below

Precisely, it returns True iff: a) The expression guarantees to terminate, b) soon, c) without causing a write side effect (e.g. writing a mutable variable) d) without throwing a Haskell exception e) without risking an unchecked runtime exception (array out of bounds, divide by zero)

For exprOkForSideEffects the list is the same, but omitting (e).

Note that exprIsHNF implies exprOkForSpeculation exprOkForSpeculation implies exprOkForSideEffects

See Note [PrimOp can_fail and has_side_effects] in GHC.Builtin.PrimOps and Note [Transformations affected by can_fail and has_side_effects]

As an example of the considerations in this test, consider:

let x = case y# +# 1# of { r# -> I# r# }
in E

being translated to:

case y# +# 1# of { r# ->
   let x = I# r#
   in E
}

We can only do this if the y + 1 is ok for speculation: it has no side effects, and can't diverge or raise an exception.

A special version of exprOkForSpeculation used during Note [Speculative evaluation]. When the predicate arg fun_ok returns False for b, then b is never considered ok-for-spec.

Similar to exprIsHNF but includes CONLIKE functions as well as data constructors. Conlike arguments are considered interesting by the inliner.

Check if the expression is zero or more Ticks wrapped around a literal string.

Extract a literal string from an expression that is zero or more Ticks wrapped around a literal string. Returns Nothing if the expression has a different shape. Used to "look through" Ticks in places that need to handle literal strings.

Can we bind this CoreExpr at the top level?

A cheap equality test which bales out fast! If it returns True the arguments are definitely equal, otherwise, they may or may not be equal.

Cheap expression equality test, can ignore ticks by type.

Finds differences between core bindings, see diffExpr.

The main problem here is that while we expect the binds to have the same order in both lists, this is not guaranteed. To do this properly we'd either have to do some sort of unification or check all possible mappings, which would be seriously expensive. So instead we simply match single bindings as far as we can. This leaves us just with mutually recursive and/or mismatching bindings, which we then speculatively match by ordering them. It's by no means perfect, but gets the job done well enough.

Only used in GHC.Core.Lint.lintAnnots

Can we eta-reduce the given function to the specified arity? See Note [Eta reduction conditions].

If the expression is a Expr, converts. Otherwise, panics. NB: This does not convert Expr to CoercionTy.

Determines the type resulting from applying an expression with given type

True if the type has no non-bottom elements, e.g. when it is an empty datatype, or a GADT with non-satisfiable type parameters, e.g. Int :~: Bool. See Note [Bottoming expressions]

See Note [No alternatives lint check] for another use of this function.

If normSplitTyConApp_maybe _ ty = Just (tc, tys, co) then ty |> co = tc tys. It's splitTyConApp_maybe, but looks through coercions via topNormaliseType_maybe. Hence the "norm" prefix.

Strip ticks satisfying a predicate from top of an expression

Strip ticks satisfying a predicate from top of an expression, returning the remaining expression

Strip ticks satisfying a predicate from top of an expression, returning the ticks

Completely strip ticks satisfying a predicate from an expression. Note this is O(n) in the size of the expression!

collectMakeStaticArgs (makeStatic t srcLoc e) yields Just (makeStatic, t, srcLoc, e).

Returns Nothing for every other expression.

Does this binding bind a join point (or a recursive group of join points)?

Do we expect there to be any benefit if we make this var strict in order for it to get treated as as cbv argument? See Note [Which Ids should be strictified] See Note [CBV Function Ids] for more background.