Skip to content

Check coercion safety in StgLint

Currently we have a few (mostly wrong, e.g. in cgCase, see !1552 (closed)) coercion checking in STG-to-Cmm parts, but nothing complete. We should check all coercions in StgLint.

Checking types in STG is a losing battle (7f389a58), but we should be preserving PrimReps, so all checks should be done on those (which is fine as the coercion safety is already checked on PrimReps).

STG doesn't have explicit coercions, so we should check for these:

  • Types of return values should be safe to coerce to the return type of the function.
  • Similarly check argument types in function applications
  • Binders: in let and case expressions

When is a coercion safe? Quoting CoreLint

Note [Bad unsafe coercion]
~~~~~~~~~~~~~~~~~~~~~~~~~~
For discussion see https://gitlab.haskell.org/ghc/ghc/wikis/bad-unsafe-coercions
Linter introduces additional rules that checks improper coercion between
different types, called bad coercions. Following coercions are forbidden:

  (a) coercions between boxed and unboxed values;
  (b) coercions between unlifted values of the different sizes, here
      active size is checked, i.e. size of the actual value but not
      the space allocated for value;
  (c) coercions between floating and integral boxed values, this check
      is not yet supported for unboxed tuples, as no semantics were
      specified for that;
  (d) coercions from / to vector type
  (e) If types are unboxed tuples then tuple (# A_1,..,A_n #) can be
      coerced to (# B_1,..,B_m #) if n=m and for each pair A_i, B_i rules
      (a-e) holds.

I believe the same conditions should hold. All other coercions are safe.

(cc @simonpj @simonmar)

Edited by Ömer Sinan Ağacan
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information