-fallow-incoherent-instances suggested when already used

[iampure@…]

This is essentially the same issue as with the monomorphism restriction, but then for another flag.

[simonpj]

Please give a repo case. Otherwise nothing will happen!

Simom

[guest]

I've seen this too, unfortunately I can't send the code that produced this error as I gave up in despair and deleted it. But the problem is real.

Adrian Hey

[guest]

I thought I should add a bit more detail about this. I saw it with Windows ghc 6.6.1 FWIW. The scenario is you write some code which won't compile (ghc giving an error message suggesting using this flag will fix the problem). You recompile with this flag and get exactly the same error message. There are 2 things wrong with this IMO:

1- (Ideally) ghc should not advise the use of a flag unless it really will fix the immediate problem.

2- It should not give an error message advising the use of a flag which has already been used.

The current behaviour leaves the user (me in this case) wondering if the compiler really knows what it's talking about and whether there really is a problem in the code or if this is a *real* bug in the compiler (rather than just bad choice of error messages).

Adrian Hey

[simonpj]

I think this one is correct. You have to use -fallow-incoherent-instances when compiling the instance declarations, not in the client module that uses them. This is supposed to be a feature: the library writer can control instances individually.

I'll clarify the error message though. Thanks.

Simon

[simonpj]

The error message now says:

  To pick the first instance above, use -fallow-incoherent-instances
  when compiling the other instance declarations

I hope that makes it clear why the message appears even though -fallow-incoherent-instances is set for the module that is actually being compiled.