<p>Not a direct answer, but when I need to “hard-code” a name in a GHC plugin, I don’t use TH. Instead, I use <code>findImportedModule</code> and <code>lookupOrig</code> to look it up, e.g. as in </p>

<pre><code>lookupJDITyCon :: TcPluginM Class
lookupJDITyCon = do
    Found _ md   &lt;- findImportedModule jdiModule Nothing
    jdiTcNm &lt;- lookupOrig md (mkTcOcc "JustDoIt")
    tcLookupClass jdiTcNm
  where
jdiModule = mkModuleName "GHC.JustDoIt"
</code></pre>

<p>from the code of my <a href="https://github.com/nomeata/ghc-justdoit/blob/master/GHC/JustDoIt/Plugin.hs" rel="nofollow noreferrer"><code>ghc-justdoit</code></a> plugin.</p>

<p>I use Template Haskell names when the <em>user</em> needs to mention names, e.g. in splices or annotations, that I want to pick up in the plugin. This is what I do in <a href="https://github.com/nomeata/inspection-testing/blob/e11bf6ddf615bb62aa452ce761ded47599163bd1/src/Test/Inspection/Plugin.hs#L234" rel="nofollow noreferrer"><code>inspection-testing</code></a>. I discuss this a bit in the <a href="https://arxiv.org/abs/1803.07130" rel="nofollow noreferrer">appendix of the Inspection Testing paper</a>.</p>
Plugin name lookup behavior change from GHC 8.4 series
<p>[Update: Turns out this was a GHC bug and it is now fixed, slated for the 8.6.4 release: <a href="https://ghc.haskell.org/trac/ghc/ticket/16104#comment:8" rel="nofollow noreferrer">https://ghc.haskell.org/trac/ghc/ticket/16104#comment:8</a> ]</p>

<p>I'm trying to port a core plugin to GHC 8.6.3, which was last working fine with GHC 8.4 series. Unfortunately, I'm running into issues. Wondering if pluging programming requirements have changed, or is this a regression in GHC itself. I boiled it down to the following example and would like some guidance on how to make this work:</p>

<p>I have the following in file <code>TestPlugin.hs</code>:</p>

<pre><code>{-# LANGUAGE TemplateHaskell #-}

module TestPlugin (plugin) where

import GhcPlugins
import Data.Bits

plugin :: Plugin
plugin = defaultPlugin {installCoreToDos = install}
  where install _ todos = return (test : todos)

        test = CoreDoPluginPass "Test" check

        check :: ModGuts -&gt; CoreM ModGuts
        check m = do mbN &lt;- thNameToGhcName 'complement
                     case mbN of
                       Just _  -&gt; liftIO $ putStrLn "Found complement!"
                       Nothing -&gt; error "Failed to locate complement"

                     return m
</code></pre>

<p>And I have a very simple <code>Test.hs</code> file:</p>

<pre><code>{-# OPTIONS_GHC -fplugin TestPlugin #-}

main :: IO ()
main = return ()
</code></pre>

<p>With GHC-8.4.2, I have:</p>

<pre><code>$ ghc-8.4.2 --make -package ghc -c TestPlugin.hs
[1 of 1] Compiling TestPlugin       ( TestPlugin.hs, TestPlugin.o )

$ ghc-8.4.2 -package ghc -c Test.hs
Found complement!
</code></pre>

<p>But with GHC 8.6.3, I get:</p>

<pre><code>$ ghc-8.6.3 --make -package ghc -c TestPlugin.hs
[1 of 1] Compiling TestPlugin       ( TestPlugin.hs, TestPlugin.o )

$ ghc-8.6.3 -package ghc -c Test.hs
ghc: panic! (the 'impossible' happened)
  (GHC version 8.6.3 for x86_64-apple-darwin):
    Failed to locate complement
</code></pre>

<p>The problem goes away if I change <code>Test.hs</code> to:</p>

<pre><code>{-# OPTIONS_GHC -fplugin TestPlugin #-}

import Data.Bits  -- Should not be required in the client code!

main :: IO ()
main = return ()
</code></pre>

<p>That is, if I explicitly import <code>Data.Bits</code>. But tis is quite undesirable, since <code>Test.hs</code> is client code and the users of the plugin have no reason to import all bunch of modules the plugin might need for its own purposes. (In practice, this would require clients to import a whole bunch of irrelevant modules; quite unworkable and not maintainable.)</p>

<p>I've found the following stack-overflow ticket, which seems to suffer from a similar problem: <a href="https://stackoverflow.com/questions/50236926/how-to-replicate-the-behaviour-of-name-in-a-th-splice">How to replicate the behaviour of &#39;name in a TH splice</a> However, the answer suggested there is just not OK in this case (and perhaps wasn't really OK there either) since it would require unnecessary changes to client code in my case that is just not reasonable to expect. (Perhaps @JoachimBretner has an idea?) I've also filed this as a GHC ticket (<a href="https://ghc.haskell.org/trac/ghc/ticket/16104#ticket" rel="nofollow noreferrer">https://ghc.haskell.org/trac/ghc/ticket/16104#ticket</a>), but feedback from the stack-overflow community is greatly appreciated.</p>

<p>Should I be coding my plugin differently? Or is this a GHC regression?</p>