Skip to content

Figure out invariants surrounding ticks in Core

In the past we have had a number of issues stemming from ticks breaking various Core analyses in GHC,

  • #13233 (closed): a tick separates a levity-polymorphic tycon (e.g. an unboxed tuple tycon) from its levity arguments, resulting in a typePrimRep panic.
  • #8472 (closed): a tick wraps a primitive string literal, causing CoreToStg to fail to notice it is a string resulting in a panic
  • #14122 (closed): Another literal string issue which I have yet to debug but seems very likely to be tick-related.

We have merged a stop-gap solution/hack (f5b275a2) to the master branch (present in GHC 8.2.1) however we will need a more principled solution in the long-term (e.g. before 8.4). We will need to start by defining precisely where ticks are allowed and add appropriate logic to CoreLint to verify that this invariant is upheld.

Edited by Ben Gamari
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information