Identifier Details

The IdDetails of an Id give stable, and necessary, information about the Id.

Just a synonym for CoVarId. Written separately so it can be exported in the hs-boot file.

Check if an IdDetails says CoVarId.

The number of arguments that a join point takes. Unlike the arity of a function, this is a purely syntactic property and is fixed when the join point is created (or converted from a value). Both type and value arguments are counted.

Recursive Selector Parent

Identifier Information

An IdInfo gives optional information about an Id. If present it never lies, but it may not be present, in which case there is always a conservative assumption which can be made.

Two Ids may have different info even though they have the same Unique (and are hence the same Id); for example, one might lack the properties attached to the other.

Most of the IdInfo gives information about the value, or definition, of the Id, independent of its usage. Exceptions to this are demandInfo, occInfo, oneShotInfo and callArityInfo.

Performance note: when we update IdInfo, we have to reallocate this entire record, so it is a good idea not to let this data structure get too big.

Basic IdInfo that carries no useful information whatsoever

More informative IdInfo we can use when we know the Id has no CAF references

If the Id is a lambda-bound variable then it may have lambda-bound variable info. Sometimes we know whether the lambda binding this variable is a "one-shot" lambda; that is, whether it is applied at most once.

This information may be useful in optimisation, as computations may safely be floated inside such a lambda without risk of duplicating work.

See also Note [OneShotInfo overview] above.

Info about a lambda-bound variable, if the Id is one

It is always safe to assume that an Id has no lambda-bound variable information

This is used to remove information on lambda binders that we have setup as part of a lambda group, assuming they will be applied all at once, but turn out to be part of an unsaturated lambda as in e.g:

(\x1. \x2. e) arg1

Zap info that depends on free variables

Remove all demand info on the IdInfo

Remove usage (but not strictness) info on the IdInfo

Remove usage environment info from the strictness signature on the IdInfo

Arity Information

An ArityInfo of n tells us that partial application of this Id to up to n-1 value arguments does essentially no work.

That is not necessarily the same as saying that it has n leading lambdas, because coerces may get in the way.

The arity might increase later in the compilation process, if an extra lambda floats up to the binding site.

Invariant: the Arity of an Id must never exceed the number of value arguments that appear in the type of the Id. See Note [Arity and function types].

It is always safe to assume that an Id has an arity of 0

Id arity, as computed by GHC.Core.Opt.Arity. Specifies how many arguments this Id has to be applied to before it doesn any meaningful work.

How this is called. This is the number of arguments to which a binding can be eta-expanded without losing any sharing. n = all calls have at least n arguments

A strictness signature. Describes how a function uses its arguments See Note [idArity varies independently of dmdTypeDepth] in GHC.Core.Opt.DmdAnal

Information on whether the function will ultimately return a freshly allocated constructor.

ID demand information

The Ids unfolding

Essentially returns the realUnfoldingInfo field, but does not expose the unfolding of a strong loop breaker.

This is the right thing to call if you plan to decide whether an unfolding will inline.

True of a non-loop-breaker Id that has a stable unfolding that is (a) always inlined; that is, with an UnfWhen guidance, or (b) a DFunUnfolding which never needs to be inlined

Inline Pragma Information

Tells when the inlining is active. When it is active the thing may be inlined, depending on how big it is.

If there was an INLINE pragma, then as a separate matter, the RHS will have been made to look small with a Core inline Note

The default InlinePragInfo is AlwaysActive, so the info serves entirely as a way to inhibit inlining until we want it

Any inline pragma attached to the Id

identifier Occurrence Information

How the Id occurs in the program

Inside Lambda

Rule Information

Records the specializations of this Id that we know about in the form of rewrite CoreRules that target them

Assume that no specializations exist: always safe

Retrieve the locally-defined free variables of both the left and right hand sides of the specialization rules

Change the name of the function the rule is keyed on all of the CoreRules

Specialisations of the Ids function which exist. See Note [Specialisations and RULES in IdInfo]

Constant applicative form Information

Records whether an Id makes Constant Applicative Form references

Id CAF info

Information about an identifier, from the code generator's point of view. Every identifier is bound to a LambdaFormInfo in the environment, which gives the code generator enough info to be able to tail call or return that identifier.

Tick box for Hpc-style coverage