#14123: Figure out invariants surrounding ticks in Core -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In the past we have had a number of issues stemming from ticks breaking various Core analyses in GHC, * #13233: a tick separates a levity-polymorphic tycon (e.g. an unboxed tuple tycon) from its levity arguments, resulting in a `typePrimRep` panic. * ticket:8472#comment:22: a tick wraps a primitive string literal, causing `CoreToStg` to fail to notice it is a string resulting in a panic * #14122: 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 (f5b275a239d2554c4da0b7621211642bf3b10650) to the `ghc-8.2` branch however 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. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14123 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler