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.