#8025: "During interactive linking, GHCi couldn't find the following symbol" typechecker error with TemplateHaskell involved -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Incorrect | Test Case: warning at compile-time | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by duog): I have not contributed to GHC before, and I would like to work on resolving this issue. Both haddock and flycheck should be able to use -fno-code to do a lot less work. Currently, haddock essentially turns off no-code when any modules use template haskell and flycheck uses no-link to work around both this issue and #10600. I think this can be resolved by having ghc itself enable codegen on home modules depended on by modules that use template haskell. I have a patch here [https://github.com/duog/ghc/tree/wip-nocode-th] which I just rebased onto your master. Note that the haddock submodule points to my github fork. downsweep is changed to do an additional pass over the modules, targetting any ModSummaries transitively depended on by a module that has LangExt.TemplateHaskell enabled. Those targeted modules have hscTarget changed from HscNothing to the default target of the platform. There are two shell scripts in the root of my fork which boot and run an ad-hoc benchmark of cabal haddock on the wreq library. This library uses template haskell to generate lenses, and imports home modules from modules that use template haskell. However, most modules are not imported from modules that use template haskell. With this patch, cabal haddock runs in about half the time. At least two points that need to be addressed: * Should this behaviour require an additional flag? It doesn't seem good for -fno-code to sometimes generate code. * Is the default target of the platform the correct choice? I would require some guidance to get this into a mergable state, if you are interested in taking this fix please let me know the next step. I am happy to use your phabricator if that is appropriate. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8025#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler