[GHC] #10077: Providing type checker plugin on command line results in false cyclic import error

[GHC]

#10077: Providing type checker plugin on command line results in false cyclic
import error
-------------------------------------+-------------------------------------
        Reporter:  jbracker          |                   Owner:
            Type:  bug               |                  Status:  new
        Priority:  normal            |               Milestone:
       Component:  Compiler (Type    |                 Version:  7.11
  checker)                           |                Keywords:
      Resolution:                    |  typechecker plugin cycle imports
Operating System:  Linux             |            Architecture:  x86_64
 Type of failure:  Incorrect         |  (amd64)
  warning at compile-time            |               Test Case:
      Blocked By:                    |                Blocking:
 Related Tickets:                    |  Differential Revisions:
-------------------------------------+-------------------------------------

Comment (by adamgundry):

 This is arguably correct behaviour, though I agree that it's less than
 ideal. The combination of `--make` and `-fplugin` is often troublesome,
 because `-fplugin MyPlugin` essentially imports `MyPlugin` in every module
 being compiled. (As usual, when you do `ghc --make <flags> Test.hs` the
 dependencies of `Test.hs` are compiled with the same command-line flags
 `<flags>`.) Thus your first example ends up compiling `MyPlugin` with
 `-fplugin MyPlugin`, which is obviously cyclic.

 If you're defining and using a plugin in a single package, I recommend
 using `OPTIONS_GHC` pragmas in the modules that rely on the plugin, rather
 than supplying `-fplugin` on the command line. As you've discovered, this
 avoids the problem. Alternatively, you can define the plugin in one
 package and use it in another, then it is easy to compile the first
 package without `-fplugin`, and you can use it globally in the second
 package.

 I guess we should make the documentation clearer about how to avoid this
 problem, and perhaps change the cyclic import message to be more
 informative in the presence of plugins.

 Regarding `-dynamic`, I guess we should do something similar to #8180,
 since it's basically the same issue: if you use `-fplugin MyPlugin`
 anywhere in the module graph, the compilation manager should make sure
 that `MyPlugin` is compiled with `-dynamic` or `-dynamic-too`. I don't
 know how tricky this would be to implement, though.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10077#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler