#11126: Entered absent arg in a Repa program -------------------------------------+------------------------------------- Reporter: tuplanolla | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3221 Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): This is an error that came up repeatedly when I worked on my own usage analysis (which includes absence analysis). It was caused by RULEs (orphans and associated ones) and/or unfoldings in module `Lib` referencing otherwise absent/dead bindings, so that some binding (e.g. specialisations of an exported binding) that appeared to be dead could suddenly become alive when a specialisation fired in some client module `Main`. That lead to such an absent error, spread over multiple modules. FWIW, this won't frequently occur with the current demand analyser, because it assumes that *all* top-level bindings are alive instead of trying hard to find the minimal set, like the occurence analyser does. But this may pop up again e.g. for Call Arity, where the assumption is that only exported ids are such 'usage roots'. The disregard for RULEs and Unfoldings could lead, in theory, to a situation where we eta-expand a binding from arity 2 to arity 3 because every considered live call allows that, but some call in a RULE or Unfolding might still only have arity 2. Like in #10176, this could make bindings too lazy for their own good. The (naive) fix of treating Unfoldings/RULEs as an additional RHS of a binding (`if ? then orig_rhs else unfolding`) had detrimental effect on the precision of my usage analysis. I suspect this is the case here, too? In the end, I decided not to include the fix in order to be comparable to Call Arity and demand analysis, which is quite a shame. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11126#comment:17 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler