Opened 3 years ago

Closed 3 years ago

Last modified 22 months ago

#10294 closed bug (fixed)

Missing instances if compiling with -fplugin

Reported by: jscholl Owned by:
Priority: normal Milestone: 8.0.1
Component: Compiler (Type checker) Version: 7.10.1
Keywords: Cc:
Operating System: Linux Architecture: x86_64 (amd64)
Type of failure: GHC rejects valid program Test Case: plugins/T10294, plugins/T10294a
Blocked By: #10420 Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


Using the example from " Using Annotations" of the GHC user manual does not work correctly with GHC 7.10. The following fails:

$ ghc -c Bug1.hs -fplugin=SayAnnNames.Plugin

    No instance for (Data SomeAnn) arising from an annotation
    In the annotation: {-# ANN foo SomeAnn #-}

It does not seem to matter why the type class is required:

$ ghc -c Bug2.hs -fplugin=SayAnnNames.Plugin

    No instance for (Data SomeAnn) arising from a use of ‘bar’
    In the expression: bar SomeAnn
    In an equation for ‘baz’: baz = bar SomeAnn

Compiling without -fplugin works fine, though. If SomeAnn is defined in a different module than SayAnnNames.Plugin and reexported from it, the instances are in scope, too.

Attachments (3)

ann-bug- (1.0 KB) - added by jscholl 3 years ago.
Cabal package containing the example plugin from the user manual
Bug1.hs (96 bytes) - added by jscholl 3 years ago.
Bug2.hs (138 bytes) - added by jscholl 3 years ago.

Download all attachments as: .zip

Change History (11)

Changed 3 years ago by jscholl

Attachment: ann-bug- added

Cabal package containing the example plugin from the user manual

Changed 3 years ago by jscholl

Attachment: Bug1.hs added

Changed 3 years ago by jscholl

Attachment: Bug2.hs added

comment:1 Changed 3 years ago by ezyang

Blocked By: 10420 added
Resolution: duplicate
Status: newclosed

Pretty sure this is a duplicate of #10420, which was reported later but has a proper diagnosis of the problem. But maybe we should put this test example into the test suite in any case.

comment:2 Changed 3 years ago by Edward Z. Yang <ezyang@…>

In 0cb1f5cf26fae946ca745abc5e302e62a8f66feb/ghc:

Filter orphan rules based on imports, fixes #10294 and #10420.

If we have an orphan rule in our database, don't apply it
unless the defining module is transitively imported by the
module we are processing.  We do this by defining a new RuleEnv
data type which includes both the RuleBase as well as the set
of visible orphan modules, and threading this through the
relevant environments (CoreReader, RuleCheckEnv and ScEnv).

This is analogous to the instances fix we applied in #2182
4c834fdddf4d44d12039da4d6a2c63a660975b95, but done for RULES.
An important knock-on effect is that we can remove some buggy
code in LoadInterface which tried to avoid loading interfaces
that were loaded by plugins (which sometimes caused instances
and rules to NEVER become visible).

One note about tests: I renamed the old plugins07 test to T10420
and replaced plugins07 with a test to ensure that a plugin
import did not cause new rules to be loaded in.

Signed-off-by: Edward Z. Yang <>

Test Plan: validate

Reviewers: simonpj, austin, goldfire

Subscribers: bgamari, thomie

Differential Revision:

GHC Trac Issues: #10420

comment:3 Changed 3 years ago by Joachim Breitner <mail@…>

In 4ee658a02ccc6d3aa0b6a0a5f2f5934a593f1356/ghc:

Mark test case for #10294 expect_broken on #10301

as it is broken on Travis, and in #10301 others have reported the same

comment:4 Changed 3 years ago by Joachim Breitner <mail@…>

In 8e6a50339a4a61d4f2cbec645c78abc85098a294/ghc:

Mark test case for #10294 conditionally expect_broken on #10301

the hypothesis is that it only breaks with `DYNAMIC_GHC_PROGRAMS = NO`,
so use `unless(have_dynamic(),expect_broken(10301))` to not break the
Phabricator build.

comment:5 Changed 3 years ago by thomie

Resolution: duplicate
Status: closednew
Test Case: plugins/T10294, plugins/T10294a

The pre_cmd of T10294 and T10294a generates the following warning with a devel2 build:

$ make -s --no-print-directory -C annotation-plugin package.T10294
WARNING: file compiler/specialise/Specialise.hs, line 722
  specImport discarding: mapM_ :: forall a_a5Mh
                                         (m_a5Mi :: * -> *)
                                         (t_a5Mk :: * -> *).
                                  (Foldable t_a5Mk, Monad m_a5Mi) =>
                                  (a_a5Mh -> m_a5Mi b_a5Mj) -> t_a5Mk a_a5Mh -> m_a5Mi ()
    want: False
    stable: False
    calls: mapM_ _ @ CoreM _ @ [] $fFoldable[] $fMonadCoreM

This makes the test fail for me, even when DYNAMIC_GHC_PROGRAMS=YES (my timeout program stops working for some reason when it sees unexpected output). I don't know if the warning can be ignored, so I'm reopening this ticket.

comment:6 Changed 3 years ago by thomie

Milestone: 7.12.1
Resolution: fixed
Status: newclosed

Nevermind, that warning only shows up when ghc is compiled with -DDEBUG, and is not related to this ticket at all. Closing as duplicate again.

comment:7 Changed 3 years ago by thoughtpolice


Milestone renamed

comment:8 Changed 22 months ago by Ben Gamari <ben@…>

In 0cad52d/ghc:

testsuite: Mark T10294 as fixed

It seems that c3c702441137dc8f7ee0dd5ac313be96d625459a resolved #10301.
It took a while to notice this since it only broke when tested against a
statically linked GHC, a configuration which Harbormaster doesn't test.

Test Plan: Validate

Reviewers: angerman, austin

Subscribers: thomie, nomeata

Differential Revision:

GHC Trac Issues: #10294, #10301
Note: See TracTickets for help on using tickets.