[GHC] #14779: Compiling with -g fails -lint-core checks

[GHC]

#14779: Compiling with -g fails -lint-core checks
-------------------------------------+-------------------------------------
        Reporter:  niteria           |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:
  (Debugging)                        |
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Compile-time      |  Unknown/Multiple
  crash or panic                     |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #14122, #14123,   |  Differential Rev(s):
  #8472, #14406                      |
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by niteria):

 Ok, I know what's going on "mechanically", but I'm missing some big
 picture stuff.

 In https://phabricator.haskell.org/D3051, bgamari added some logic in
 `Simplify.prepareRhs.go` to not tick top level string literals.

 Namely this fragment:
 {{{
              ; let tickIt (id, expr)
                        -- we have to take care not to tick top-level
 literal
                        -- strings. See Note [CoreSyn top-level string
 literals].
                      | isTopLevel top_lvl && exprIsLiteralString expr
                      = (id, expr)
                      | otherwise
                      = (id, mkTick (mkNoCount t) expr)
 }}}

 In the case that I'm looking at `top_level = NotTopLevel` and the literal
 string gets floated to the top.

 The call stack is as follows `Simplify.simplNonRecE` calls
 `Simplify.simplLazyBind` calls `Simplify.prepareRhs`.
 Now `simplNonRecE` always calls `simplLazyBind` with `NotTopLevel` and
 `simplLazyBind` uses that to call `prepareRhs`.

 So either:
 1. `top_level` doesn't mean that we're floating to top level, or
 2. it means that we're floating to top level, and we're not supposed to
 float the string to the top.

 I suspect it's 1., but I wasn't able to find a comment that explains its
 purpose.

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14779#comment:8>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler