Re: [GHC] #1595: duplicate "not in scope" error when giving multiple vars type-signatures at once
#1595: duplicate "not in scope" error when giving multiple vars type-signatures at once -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: michalt Type: bug | Status: closed Priority: normal | Milestone: 7.2.1 Component: Compiler | Version: 6.6.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | rename/should_fail/T1595 Blocked By: | Blocking: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones <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 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1595#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
participants (1)
-
GHC