Providing type checker plugin on command line results in false cyclic import error

I am playing around with the new type checker plugins using the current development branch of GHC. When I supply the plugin module to GHC through the command line I get a cyclic import error message, which I think is false. If I supply the same plugin module using a pragma I do not get an error message.

Minimal Example (Command Line)

MyPlugin.hs:

module MyPlugin ( plugin ) where

import Plugins ( Plugin, defaultPlugin )

plugin :: Plugin
plugin = defaultPlugin

Test.hs:

module Test where

main :: IO ()
main = return ()

Command line call of GHC:

~/ghc/inplace/bin/ghc-stage2 \
  --make 
  -package ghc-7.11.20150209 \
  -fplugin=MyPlugin \
  Test.hs

Results in the following error

Module imports form a cycle:
  module ‘MyPlugin’ (./MyPlugin.hs) imports itself

which does not seem reasonable to me understand.

Minimal example (pragma)

On the other hand, if I change Test.hs to the following

{-# OPTIONS_GHC -fplugin MyPlugin #-} 
module Test where

main :: IO ()
main = return ()

and calling GHC like this

~/ghc/inplace/bin/ghc-stage2 \
  --make \
  -package ghc-7.11.20150209 \
  -dynamic \
  Test.hs

it works.

I did not change MyPlugin.hs.

Note

1. Using -fplugin=MyPlugin vs. -fplugin MyPlugin does not make a difference.
2. The command line example behaves the same independent of whether I supply the -dynamic flag or not.
3. I had to add the -dynamic flag, because otherwise GHC will complain that:

<no location info>: cannot find normal object file ‘./MyPlugin.dyn_o’ while linking an interpreted expression This might be a long shot, but maybe using the -fplugin option should imply the -dynamic flag?

Trac metadata

Trac field	Value
Version	7.11
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler (Type checker)
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture