
#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