[GHC] #8025: "During interactive linking, GHCi couldn't find the following symbol" typechecker error with TemplateHaskell involved

[GHC]

#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