[GHC] #10595: BuiltinRules override other rules in some cases.

[GHC]

#10595: BuiltinRules override other rules in some cases.
-------------------------------------+-------------------------------------
        Reporter:  gjsimms           |                   Owner:
            Type:  bug               |                  Status:  new
        Priority:  high              |               Milestone:
       Component:  Compiler          |                 Version:  7.11
      Resolution:                    |                Keywords:
Operating System:  Unknown/Multiple  |            Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |               Test Case:
      Blocked By:                    |                Blocking:
 Related Tickets:                    |  Differential Revisions:
-------------------------------------+-------------------------------------

Comment (by simonpj):

 In [changeset:"a1dd7dd6ea276832aef0caaf805f0ab9f4e16262/ghc" a1dd7dd/ghc]:
 {{{
 #!CommitTicketReference repository="ghc"
 revision="a1dd7dd6ea276832aef0caaf805f0ab9f4e16262"
 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
 }}}
 The commit message should have said #10595!  Typo.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10595#comment:14>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler