Fallout from more assiduous RULE warnings
authorSimon Peyton Jones <simonpj@microsoft.com>
Tue, 28 Jul 2015 15:00:20 +0000 (16:00 +0100)
committerSimon Peyton Jones <simonpj@microsoft.com>
Tue, 28 Jul 2015 16:46:40 +0000 (17:46 +0100)
commita1dd7dd6ea276832aef0caaf805f0ab9f4e16262
treea1171fd0fd4d3fdc97f023c415fdd976d44ae183
parente343c0a7fbaca4285a89008e5e23d35a50603763
Fallout from more assiduous RULE warnings

GHC now warns if rules compete, so that it's not predicatable
which will work and which will not. E.g.

{-# RULES
  f (g x) = ...
  g True  = ...
  #-}

If we had (f (g True)) it's not clear which rule would fire.

This showed up fraility in the libraries.

* Suppress warnigns in Control.Arrow, Control.Category for class
  methods. At the moment we simply don't have a good way to write a
  RULE with a class method in the LHS.  See Trac #1595.  Arrow and
  Category attempt to do so; I have silenced the complaints with
  -fno-warn-inline-rule-shadowing, but it's not a great solution.

* Adjust the NOINLINE pragma on 'GHC.Base.map' to account for the
  map/coerce rule

* Adjust the rewrite rules in Enum, especially for the "literal 1"
  case.  See Note [Enum Integer rules for literal 1].

* Suppress warnings for 'bytestring' e.g.
   libraries/bytestring/Data/ByteString.hs:895:1: warning:
      Rule "ByteString specialise break (x==)" may never fire
        because rule "Class op ==" for ‘==’ might fire first
      Probable fix: add phase [n] or [~n] to the competing rule
libraries/base/Control/Arrow.hs
libraries/base/Control/Category.hs
libraries/base/GHC/Base.hs
libraries/base/GHC/Enum.hs
mk/warnings.mk