[GHC] #16261: Mysterious rule shadowing warning

#16261: Mysterious rule shadowing warning -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Compiling `Data.Set.Internal` produces the following: {{{ Data/Set/Internal.hs:958:11: warning: [-Winline-rule-shadowing] Rule "Set.toAscListBack" may never fire because rule "Class op fromListN" for ‘GHCExts.fromListN’ might fire first Probable fix: add phase [n] or [~n] to the competing rule | 958 | {-# RULES "Set.toAscListBack" [1] foldrFB (:) [] = toAscList #-} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Data/Set/Internal.hs:960:11: warning: [-Winline-rule-shadowing] Rule "Set.toDescListBack" may never fire because rule "Class op fromListN" for ‘GHCExts.fromListN’ might fire first Probable fix: add phase [n] or [~n] to the competing rule | 960 | {-# RULES "Set.toDescListBack" [1] foldlFB (\xs x -> x : xs) [] = toDescList #-} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} What the heck does the class op rule for `fromListN` have to do with anything anywhere near here? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/16261 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#16261: Mysterious rule shadowing warning -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I think it's because of the overloaded list `[1]` which desugars to a call to `fromListN`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/16261#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#16261: Mysterious rule shadowing warning -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:1 mpickering]:
I think it's because of the overloaded list `[1]` which desugars to a call to `fromListN`.
That's ... not a list. It's a rule phase. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/16261#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#16261: Mysterious rule shadowing warning -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by dfeuer: Old description:
Compiling `Data.Set.Internal` produces the following:
{{{ Data/Set/Internal.hs:958:11: warning: [-Winline-rule-shadowing] Rule "Set.toAscListBack" may never fire because rule "Class op fromListN" for ‘GHCExts.fromListN’ might fire first Probable fix: add phase [n] or [~n] to the competing rule | 958 | {-# RULES "Set.toAscListBack" [1] foldrFB (:) [] = toAscList #-} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Data/Set/Internal.hs:960:11: warning: [-Winline-rule-shadowing] Rule "Set.toDescListBack" may never fire because rule "Class op fromListN" for ‘GHCExts.fromListN’ might fire first Probable fix: add phase [n] or [~n] to the competing rule | 960 | {-# RULES "Set.toDescListBack" [1] foldlFB (\xs x -> x : xs) [] = toDescList #-} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}}
What the heck does the class op rule for `fromListN` have to do with anything anywhere near here?
New description: Compiling `Data.Set.Internal` produces the following: {{{ Data/Set/Internal.hs:958:11: warning: [-Winline-rule-shadowing] Rule "Set.toAscListBack" may never fire because rule "Class op fromListN" for ‘GHCExts.fromListN’ might fire first Probable fix: add phase [n] or [~n] to the competing rule | 958 | {-# RULES "Set.toAscListBack" [1] foldrFB (:) [] = toAscList #-} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Data/Set/Internal.hs:960:11: warning: [-Winline-rule-shadowing] Rule "Set.toDescListBack" may never fire because rule "Class op fromListN" for ‘GHCExts.fromListN’ might fire first Probable fix: add phase [n] or [~n] to the competing rule | 960 | {-# RULES "Set.toDescListBack" [1] foldlFB (\xs x -> x : xs) [] = toDescList #-} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} What the heck does the class op rule for `fromListN` have to do with anything anywhere near here? Note in particular that this module neither defines `fromListN` (it takes its default definition) nor uses it in code or `RULES`. -- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/16261#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#16261: Mysterious rule shadowing warning -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Oops, how about `[]` then? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/16261#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#16261: Mysterious rule shadowing warning -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Yes, that's it. But the module doesn't even enable `OverloadedLists`. And why would we ''ever'' want `[]` to be interpreted as an overloaded list on a rule LHS? That makes no sense at all. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/16261#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#16261: [] interpreted as an overloaded list in rule LHS -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by dfeuer: Old description:
Compiling `Data.Set.Internal` produces the following:
{{{ Data/Set/Internal.hs:958:11: warning: [-Winline-rule-shadowing] Rule "Set.toAscListBack" may never fire because rule "Class op fromListN" for ‘GHCExts.fromListN’ might fire first Probable fix: add phase [n] or [~n] to the competing rule | 958 | {-# RULES "Set.toAscListBack" [1] foldrFB (:) [] = toAscList #-} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Data/Set/Internal.hs:960:11: warning: [-Winline-rule-shadowing] Rule "Set.toDescListBack" may never fire because rule "Class op fromListN" for ‘GHCExts.fromListN’ might fire first Probable fix: add phase [n] or [~n] to the competing rule | 960 | {-# RULES "Set.toDescListBack" [1] foldlFB (\xs x -> x : xs) [] = toDescList #-} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}}
What the heck does the class op rule for `fromListN` have to do with anything anywhere near here? Note in particular that this module neither defines `fromListN` (it takes its default definition) nor uses it in code or `RULES`.
New description: Compiling `Data.Set.Internal` produces the following: {{{ Data/Set/Internal.hs:958:11: warning: [-Winline-rule-shadowing] Rule "Set.toAscListBack" may never fire because rule "Class op fromListN" for ‘GHCExts.fromListN’ might fire first Probable fix: add phase [n] or [~n] to the competing rule | 958 | {-# RULES "Set.toAscListBack" [1] foldrFB (:) [] = toAscList #-} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Data/Set/Internal.hs:960:11: warning: [-Winline-rule-shadowing] Rule "Set.toDescListBack" may never fire because rule "Class op fromListN" for ‘GHCExts.fromListN’ might fire first Probable fix: add phase [n] or [~n] to the competing rule | 960 | {-# RULES "Set.toDescListBack" [1] foldlFB (\xs x -> x : xs) [] = toDescList #-} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} As mpickering figured out, the trouble is that `[]` in the rule LHS is being interpreted as an overloaded list. The module does ''not'' enable `OverloadedLists`. Furthermore, even if it ''did'', I would argue that it is ''never'' correct to put one in a rule LHS, so we should always interpret `[]` as the empty list constructor in `RULES` left-hand sides. -- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/16261#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#16261: [] interpreted as an overloaded list in rule LHS -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * version: 8.6.3 => 8.6.2 Comment: The problem showed up somewhere between 8.4.3 and 8.6.2. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/16261#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#16261: [] interpreted as an overloaded list in rule LHS -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Strike that; it was there much earlier. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/16261#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#16261: [] interpreted as an overloaded list in rule LHS -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * version: 8.6.2 => 8.6.3 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/16261#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#16261: [] interpreted as an overloaded list in rule LHS -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj):
Yes, that's it. But the module doesn't even enable OverloadedLists.
That is indeed odd. Digging into why would be v helpful. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/16261#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#16261: [] interpreted as an overloaded list in rule LHS -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:10 simonpj]:
Yes, that's it. But the module doesn't even enable OverloadedLists.
That is indeed odd. Digging into why would be v helpful.
I don't know anything about the implementation of the `RULES` system. What determines which extensions are in play in `RULES`? Do you agree with my opinion that `OverloadedLists` should ''never'' be enabled in a rule LHS, regardless of which extensions are enabled in the module? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/16261#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#16261: [] interpreted as an overloaded list in rule LHS -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj):
Do you agree with my opinion that OverloadedLists should never be enabled in a rule LHS, regardless of which extensions are enabled in the module?
No: I think the same extensions should be in scope everywhere otherwise people will say "but I wrote `f []` and it didn't match a rule whose LHS was `f []`". However I do agree that it's bizarre that `OverloadedLists` seems to be enabled on the rule LHS but not in the rest of the module. Deeply strange. We just need to understand more about what is happening. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/16261#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#16261: [] interpreted as an overloaded list in rule LHS -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => closed * resolution: => invalid Comment: Oh, what a fool I am! In all the test compilations, I was (by relic of a previous thing) enabling overloaded lists myself! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/16261#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC