Skip to content

Call Arity has the trivial application case wrong

In e x, the result of x is not shared in contrast to e (f x), where CorePrep will turn it into let y = f x in e x. So in

  let f = ...
  in e (f x)

we know that f is called at most once, but in

  let f = ...
  in e f

we do not know that.

Previously Call Arity would assume that in e x, x is evaluated at most once. This rarely would make a difference (the argument x is analized with an incoming arity of 0, so no eta-expansion would be done anyways), but of course this should still be fixed.

I just validated a patch and will push shortly.

Trac metadata
Trac field Value
Version 7.10.2
Type Bug
TypeOfFailure OtherFailure
Priority normal
Resolution Unresolved
Component Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information