`Float64(::BigFloat)` infers poorly

[topolarity]

Using JET.jl avi/demo with JuliaLowering:

julia> report_opt(Float64, (BigFloat,))
═════ 3 possible errors found ═════
┌ Float64(x::BigFloat) @ Base.MPFR ./mpfr.jl:546
│┌ Float64(x::BigFloat, r::Base.MPFR.MPFRRoundingMode) @ Base.MPFR ./mpfr.jl:546
││┌ to_ieee754(::Type{Float64}, x::BigFloat, rm::Base.MPFR.MPFRRoundingMode) @ Base.MPFR ./mpfr.jl:522
│││┌ correct_rounding_requires_increment(x::Base.MPFR.BigFloatDataRoundingIncrementHelper{…}, rounding_mode::Base.MPFR.MPFRRoundingMode, sign_bit::Bool) @ Base.Rounding ./rounding.jl:144
││││┌ (::Base.Rounding.var"#correct_rounding_requires_increment##0#correct_rounding_requires_increment##1"{…})(z::Base.Rounding.RoundBit) @ Base.Rounding ./:141
│││││ runtime dispatch detected: %1::Any(z::Base.Rounding.RoundBit)::Any
││││└────────────────────
│││┌ correct_rounding_requires_increment(x::Base.MPFR.BigFloatDataRoundingIncrementHelper{…}, rounding_mode::Base.MPFR.MPFRRoundingMode, sign_bit::Bool) @ Base.Rounding ./rounding.jl:145
││││┌ (::Base.Rounding.var"#correct_rounding_requires_increment##0#correct_rounding_requires_increment##1"{…})(z::Base.Rounding.StickyBit) @ Base.Rounding ./:141
│││││ runtime dispatch detected: %1::Any(z::Base.Rounding.StickyBit)::Any
││││└────────────────────
│││┌ correct_rounding_requires_increment(x::Base.MPFR.BigFloatDataRoundingIncrementHelper{…}, rounding_mode::Base.MPFR.MPFRRoundingMode, sign_bit::Bool) @ Base.Rounding ./rounding.jl:149
││││┌ (::Base.Rounding.var"#correct_rounding_requires_increment##0#correct_rounding_requires_increment##1"{…})(z::Base.Rounding.FinalBit) @ Base.Rounding ./:141
│││││ runtime dispatch detected: %1::Any(z::Base.Rounding.FinalBit)::Any
││││└────────────────────

compared to standard JET.jl + Scheme lowering:

julia> report_opt(Float64, (BigFloat,))
No errors detected

Seems that:

    f = let y = x
        (z::Union{FinalBit,RoundBit,StickyBit}) -> y(z)::Bool
    end

is not able to infer / propagate f for some reason (it is the %1::Any above)

[aviatesk]

I think this issue is due to the limitations of the avi/JL-integration branch.
The basic idea of that branch is to hook into abstract interpretation, and when new code is inferred, it uses CodeTracking to retrieve the method's code, then parses and lowers it with JS/JL. Then, it replaces the inferred CodeInfo with the one JL created.

This works for simple code, but in situations like this, the replacement itself probably fails. This is because the new code lowered by JL has variables and closures with different identities compared to what the native lowerer creates. To solve this problem, we might just have to wait for JL's integration into the base.

If inference starts using the CodeInfo created by JL, then the replacement won't be needed at all. However, even in that case, we'd still need to either encode information equivalent to SyntaxTree into CodeInfo (which is the proper solution), or stash it somewhere in a global state, mapped to CodeInfo (which is a solution for prototyping).