
#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): phab:D4423 #8472, #14406 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm afraid I'm still not happy. The offending case is this. Before, we have: {{{ T14779.conMkFixed = srcT14779.hs:78:1-49 T14779.mkConstr (srcT14779.hs:78:23-29 T14779.tyFixed) (srcT14779.hs:78:31-39 GHC.CString.unpackCString# "MkFixed"#) ((srcT14779.hs:78:41-42 GHC.Types.[]) @ GHC.Base.String) (srcT14779.hs:78:44-49 T14779.Prefix) }}} The simplifier inlines `mkConstr`, let-binding its arguments like this {{{ conMkFixed = let str_s2UM :: Addr# str_s2UM = srcT14779.hs:78:31-39 "MkFixed"# str_a2jk :: String str_a2jk = srcT14779.hs:78:31-39 unpackCString# str_s2UM in ...str_a2jk... }}} and then the simplifier floats those two bindings outward. Ben/Bartosz's patch messes with `prepareRhs` in a slightly delicate way, to remove the tick on the string, but I think the bug is earlier. '''I believe we should never have a tick wrapped around a literal string'''. That's certainly what Phab:D3925 seems to say. If that is true (is it?) then that invariant is already broken in the above intermediate form. We should instead have {{{ conMkFixed = let str_s2UM :: Addr# str_s2UM = "MkFixed"# str_a2jk :: String str_a2jk = srcT14779.hs:78:31-39 unpackCString# str_s2UM in ...str_a2jk... }}} Let's first establish whether we ever want a tick wrapped around a literal string. If we don't, let's adopt Phab:D3925, and make the smart constructor `mkTick` guarantee it. (Unfortunately `CoreUtils.mkTick` is a jolly complicated function and I don't understand it.) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14779#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler