#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

#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 jbracker): Replying to [comment:2 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.

I have trouble understanding why a plugin needs to be imported to the module that uses it. As far as I understand GHC dynamically loads the plugin module and uses it, but I don't see why the plugin needs to be imported to the compiled module, since the modules do not have access to the plugins functionality anyway. Is this required because the plugin might import other modules in scope?

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.

Yes, I agree. Thank you for extending the wiki page!

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.

Looking at the changes from that ticket it does not seem to be too much work: [changeset:"e25af05656b496b997c8f3520e5ac8e377a68e7b/ghc"] Though there might be lingering problems arising from this. Replying to [comment:3 adamgundry]:

I've added a [wiki:Plugins/TypeChecker#FAQ section to the typechecker plugins wiki page] documenting these issues. Suggestions for improvement are welcome!

Maybe a link to this ticket, in case someone wants to know more about the issue? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10077#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#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 jbracker): Replying to [comment:5 adamgundry]:

To try to clarify: it's not exactly true that the plugin needs to be **imported** into a module that uses it, although I believe the implementation works more-or-less like that, with some cleverness to avoid e.g. typeclass instances being brought in. The point is that if module `M` uses a plugin in module `P`, then we have to dynamically load `P` in order to typecheck `M`. Hence `P` cannot depend (directly or indirectly) on `M`!

When `-fplugin=P` is used on the command-line, GHC tries to load `P` for every module being compiled, which might include `P` itself. This isn't exactly a cyclic import, but it's pretty close.

Thank you for the clarification. I understand now.

...

Maybe a link to this ticket, in case someone wants to know more about the issue?

Yes. Done.

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

#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): Replying to [comment:7 ezyang]:

Isn't the case here that, when GHC attempts to compile a plugin, it shouldn't use the `-fplugin` arguments for the compilation? Simple stage restriction: you can't use a plugin on itself.

That's true, but I'm not quite sure what you're suggesting: do you mean that GHC should silently ignore the `-fplugin` argument when compiling the plugin itself (and its dependencies)? I guess that would be more convenient in this case, although I imagine it would be counterintuitive in other cases (e.g. if you were trying to use a plugin on a module without realising the plugin depended on that module). Perhaps those other cases are sufficiently obscure that it is worth doing, and could perhaps be combined with turning on `-dynamic` automatically. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10077#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#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: typechecker Resolution: | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): osa1, the cycle is that ghc thinks you have told it to compile module `P` using the plugin `P`. It's not literally an import cycle, but it is a dependency cycle of another kind. In your duplicate ticket #12204, ghc thinks it has to recompile `Plugin` because of the new command-line flag `-fplugin=Plugin`! By the way, these examples are illegal according to the documentation, which states the "module must be a member of a package registered in GHC’s package database".

do you mean that GHC should silently ignore the `-fplugin` argument when compiling the plugin itself (and its dependencies)?

What happens if there are multiple `-fplugin` arguments? We can't compile each plugin using the other plugins, as that is again a cycle. We could compile each plugin using the plugins specified before it on the command line, but that seems overly complicated and not necessarily what the user wants. Maybe the user wants to compile their program with plugin `A` (only), but to compile plugin `A` using plugin `B`. In general there is no good reason to think that the flags used to build a plugin should have any relation to the flags used to build the program that uses the plugin. In a cross-compilation scenario, even the compiler is different! I suggest that `ghc --make` should just not follow dependencies to plugins. If you want to build a plugin and a program that uses the plugin, you need two invocations of `ghc --make`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10077#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler