Linking JuliaLang/julia#57931 as a relevant discussion (though mostly about the shared library argument to ccall) and in case you have opinions to add

Does this still support get_item(::Type{T}) where T = @ccall foo()::Ref{T} ?

IIRC the ccall lowering is an awkward "local 'static' TypeVars + top-level evaluation" where the local static parameters have to be preserved as TypeVars in the resulting expression

Does this still support get_item(::Type{T}) where T = @ccall foo()::Ref{T} ?

No, good catch! I think I've made it slightly too restrictive right now. Do the exact same rules apply to cglobal and cfunction?

I can easily add :static_parameter as allowed use of bindings, alongside :global. I should rename the kind to ... something. K"static_eval" might be good enough for now (more precise names welcome)

@topolarity wow, the cases where static parameters are allowed are quite limited in the existing runtime's interpretation of ccall parameters because they're checked quite early. I didn't expect this:

julia> get_item(::Type{T}) where T = @ccall foo()::Ref{T}
get_item (generic function with 1 method)

julia> get_item(::Type{T}) where T = @ccall foo()::T
ERROR: TypeError: in ccall method definition, expected Type, got a value of type TypeVar

I've updated things here to allow any use of static parameters because it doesn't seem like lowering can make the decision about which uses of static parameters are valid.

Do the exact same rules apply to cglobal and cfunction?

I believe so!

Here @cfunction works the same:

julia> plus(x::T) where T = @cfunction($((y)->x+y), Ref{T}, (Ref{T},))
julia> ccall(plus(1).ptr, Ref{Int}, (Ref{Int},), 2)
3
julia> ccall(plus(1 + 3im).ptr, Ref{Complex{Int}}, (Ref{Complex{Int}},), 2 - 2im)
3 + 1im

and it looks like cglobal does too:

julia> find_sym(::Val{symbol}) where symbol = cglobal(symbol)
julia> find_sym(Val{:malloc}())
Ptr{Nothing} @0x00007bcdf5aad650

they're checked quite early

Yeah, that's true. That error message is arguably a defect of the type-checking in method.c (https://github.com/JuliaLang/julia/blob/44fdede182dbc8e1e6f0e40c5af0470060e5063b/src/method.c#L194-L204), but in general we do require that the ccall etc. has a static C ABI at method definition time, even though the underlying Julia types might be dynamic. I think we do that so that we can still successfully codegen the de-specialized method (without libffi and other shenanigans to handle fully-dynamic C ABIs).

That error message should probably be more like this one:

julia> struct Foo{T}; val::T; end
julia> foo(x::T) where T = @cfunction($((y)->[x] .+ y), Foo{T}, (Foo{T},))
ERROR: cfunction method definition: return type doesn't correspond to a C type

I think we do that so that we can still successfully codegen the de-specialized method

Makes sense, that was also my guess after I got over the surprise :-)

That error message should probably be more like this one
ERROR: cfunction method definition: return type doesn't correspond to a C type

From the user's high level point of view they may very well be trying to use ccall with a C type (eg, Cint), but the TypeVar hasn't been resolved by the compiler at that early point in compilation (and may never be known statically if we compile a nospecialize version of the function). So it probably should hedge a bit ... like "return type couldn't be statically resolved to a C type" or something.

Ok, I think this will do. Thanks for the comments!