#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