Documentation

Typecheck something within the context of a deriving strategy. This is of particular importance when the deriving strategy is via. For instance:

deriving via (S a) instance C (T a)

We need to typecheck S a, and moreover, we need to extend the tyvar environment with a before typechecking C (T a), since S a quantified the type variable a.

Type-check a visible type application

Describes the kind expected in a certain context.

Used for the type variables of a type or class decl in the "kind checking" and "type checking" pass, but not in the initial-kind run.

Kind-check a LHsQTyVars. If the decl under consideration has a complete, user-supplied kind signature (CUSK), generalise the result. Used in getInitialKind (for tycon kinds and other kinds) and in kind-checking (but not for tycon kinds, which are checked with tcTyClDecls). See Note [CUSKs: complete user-supplied kind signatures] in HsDecls.

This function does not do telescope checking.

Apply a type of a given kind to a list of arguments. This instantiates invisible parameters as necessary. Always consumes all the arguments, using matchExpectedFunKind as necessary. This takes an optional VarEnv Kind which maps kind variables to kinds.- These kinds should be used to instantiate invisible kind variables; they come from an enclosing class for an associated type/data family.

If the inner action emits constraints, report them as errors and fail; otherwise, propagates the return value. Useful as a wrapper around tcImplicitTKBndrs, which uses solveLocalEqualities, when there won't be another chance to solve constraints

Type-check a thing that emits only equality constraints, then solve those constraints. Fails outright if there is trouble. Use this if you're not going to get another crack at solving (because, e.g., you're checking a datatype declaration)

This instantiates invisible arguments for the type being checked if it must be saturated and is not yet saturated. It then calls and uses the result from checkExpectedKindX to build the final type Obeys Note [The tcType invariant]

Do we require type families to be saturated?

Whenever a type is about to be added to the environment, it's necessary to make sure that any free meta-tyvars in the type are promoted to the current TcLevel. (They might be at a higher level due to the level-bumping in tcExplicitTKBndrs, for example.) This function both zonks *and* promotes. Why at the same time? See Note [Recipe for checking a signature]

Make an appropriate message for an error in a function argument. Used for both expressions and types.

Add a "In the data declaration for T" or some such.