Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compiler.return_type is broken for Compiler.jl as the standard library #56647

Open
aviatesk opened this issue Nov 22, 2024 · 0 comments
Open

Comments

@aviatesk
Copy link
Member

julia> using Compiler
Precompiling Compiler finished.
  1 dependency successfully precompiled in 2 seconds

julia> @assert Base.Compiler !== Compiler

julia> Compiler.return_type(sin, Tuple{Int})
ERROR: MethodError: no method matching _return_type(::Compiler.NativeInterpreter, ::Type{Tuple{typeof(sin), Int64}})
You may have intended to import Base._return_type
The applicable method may be too new: running in world age 6455, while current world is 23669.

Closest candidates are:
  _return_type(::Compiler.AbstractInterpreter, ::DataType) (method too new to be called from this world context.)
   @ Compiler ~/julia/julia3/Compiler/src/typeinfer.jl:1243

Stacktrace:
 [1] return_type(f::Any, t::DataType)
   @ Compiler ~/julia/julia3/Compiler/src/typeinfer.jl:1226
 [2] top-level scope
   @ REPL[3]:1

This definition of return_type assumes the use of :jl_call_in_typeinf_world, so it won’t work if Compiler.jl is loaded as a stdlib.

function return_type(@nospecialize(f), t::DataType) # this method has a special tfunc
world = tls_world_age()
args = Any[_return_type, NativeInterpreter(world), Tuple{Core.Typeof(f), t.parameters...}]
return ccall(:jl_call_in_typeinf_world, Any, (Ptr{Any}, Cint), args, length(args))
end
function return_type(@nospecialize(f), t::DataType, world::UInt)
return return_type(Tuple{Core.Typeof(f), t.parameters...}, world)
end
function return_type(t::DataType)
world = tls_world_age()
return return_type(t, world)
end
function return_type(t::DataType, world::UInt)
args = Any[_return_type, NativeInterpreter(world), t]
return ccall(:jl_call_in_typeinf_world, Any, (Ptr{Any}, Cint), args, length(args))
end
function _return_type(interp::AbstractInterpreter, t::DataType)
rt = Union{}
f = singleton_type(t.parameters[1])
if isa(f, Builtin)
args = Any[t.parameters...]
popfirst!(args)
rt = builtin_tfunction(interp, f, args, nothing)
rt = widenconst(rt)
else
for match in _methods_by_ftype(t, -1, get_inference_world(interp))::Vector
ty = typeinf_type(interp, match::MethodMatch)
ty === nothing && return Any
rt = tmerge(rt, ty)
rt === Any && break
end
end
return rt
end

In other words, since this is a feature specific to Base.Compiler, it might be better to define this function on the Base side.

aviatesk added a commit that referenced this issue Nov 22, 2024
With #56632, Compiler.jl as the stdlib can now be tested.
However, the PR was incomplete, and when tests are actually run on
`Compiler`, which is `!== Base.Compiler`, various errors occur,
including issues caused by #56647.

This commit resolves all these issues:
- manage the code for loading `Compiler` in `setup_Compiler.jl`,
  ensuring that the stdlib version of `Compiler` is loaded when
  `@activate Compiler` is used beforehand
- replace `Base.IRShow` with `Compiler.IRShow`
- test `Base.Compiler.return_type` instead of `Compiler.return_type`

This was split off from #56636.
aviatesk added a commit that referenced this issue Nov 22, 2024
With #56632, Compiler.jl as the stdlib can now be tested.
However, the PR was incomplete, and when tests are actually run on
`Compiler`, which is `!== Base.Compiler`, various errors occur,
including issues caused by #56647.

This commit resolves all these issues:
- manage the code for loading `Compiler` in `setup_Compiler.jl`,
  ensuring that the stdlib version of `Compiler` is loaded when
  `@activate Compiler` is used beforehand
- replace `Base.IRShow` with `Compiler.IRShow`
- test `Base.Compiler.return_type` instead of `Compiler.return_type`

This was split off from #56636.
aviatesk added a commit that referenced this issue Nov 22, 2024
With #56632, Compiler.jl as the stdlib can now be tested.
However, the PR was incomplete, and when tests are actually run on
`Compiler`, which is `!== Base.Compiler`, various errors occur,
including issues caused by #56647.

This commit resolves all these issues:
- manage the code for loading `Compiler` in `setup_Compiler.jl`,
ensuring that the stdlib version of `Compiler` is loaded when `@activate
Compiler` is used beforehand
- replace `Base.IRShow` with `Compiler.IRShow`
- test `Base.Compiler.return_type` instead of `Compiler.return_type`

This was split off from #56636.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant