Type inference failing for nested reduction

[simsurace]

The following nested reduction does not infer, even after #45789:

using Test

struct FunctionSum{Tf}
    functions::Tf
end

(F::FunctionSum)(x) = sum(f -> f(x), F.functions)

F = FunctionSum((x -> sqrt(x), FunctionSum((x -> x^2, x -> x^3))))
@inferred F(1.) # ERROR

[Keno]

This trips the recursion heuristic, because it can't prove that the FunctionSum -> sum -> FunctionSum -> sum method loop terminates. We could perhaps see if we can tweak the heuristics to notice that the tparam is shrinking, but it's a tricky bit of the code.

[N5N3]

#45789 only works for reduction on nested Iterator, not nested reduction.
As @Keno pointed out, your code will triger indirect recursion anyway, so our compiler would give up inference even the type is shrinking.(see #45759)
As a temporary workaround, you can try to avoid constructing nested FunctionSum or flatten the nested FunctionSum before you call sum (like ComposedFunction on master).

[jakobnissen]

Probably a duplicate of #40084. I was bitten by this with the following example. Even more mysterious, the inference works if I define the same function twice...

julia> using Test

julia> f(x) = sum(x) do v
           sum(length, v)
       end;

julia> @inferred f([[[1]]])
ERROR: return type Int64 does not match inferred return type Any
Stacktrace:
 [1] error(s::String)
   @ Base ./error.jl:35
 [2] top-level scope
   @ REPL[3]:1

julia> f(x) = sum(x) do v
           sum(length, v)
       end;

julia> @inferred f([[[1]]])
1

[simsurace]

Great example! The phenomenon about it being inferred after a second definition has happened to me as well, it is really weird. E.g. I redefined a function in a package that was type-unstable in the unit tests, but then was type stable after being overwritten with the same source code.

[schlichtanders]

I run into similar issues. Redefining the same helps.

In a sense this looks promising, as the compiler had all information already on the first run, but somehow needed to runs to actually get it.

[oscardssmith]

I just ran into a similar example:

julia> f(u) = [u[] for _ in 1:2]
f (generic function with 1 method)

julia> @inferred f(Float64)
ERROR: return type Vector{Vector{Float64}} does not match inferred return type Vector

[vtjnash]

Don't think that has anything to do with this issue, since there is no nested inference there (only a closure capture of a Type)