Actually compute sparams in jl_fptr_sparam

[Keno]

I was running a debug build of julia through the cmdlineargs tests and saw it repeatedly hit the sparams != jl_emptysvec assertion. That assertion doesn't make sense to me, since jl_fptr_sparam is specifically used in the case where the sparams need to be recomputed:

julia/src/codegen.cpp

Lines 3038 to 3043 in 12698af

	if ((size_t)jl_subtype_env_size(lam->def.method->sig) != jl_svec_len(lam->sparam_vals))
	needsparams = true;
	for (size_t i = 0; i < jl_svec_len(lam->sparam_vals); ++i) {
	if (jl_is_typevar(jl_svecref(lam->sparam_vals, i)))
	needsparams = true;
	}

It's possible I'm missing some larger point, but this fixes the assertion.

[vtjnash]

It should never directly execute this function, as it should have copied the function pointer into a MethodInstance that is populated correctly

[Keno]

Can you elaborate how that is supposed to work, since it appears to not be happening under some circumstances?

[vtjnash]

I think jl_compilation_sig is supposed to form the version without sparam_vals, but when the call to methods such as cache_method processes that, it is expected to set cache_with_orig so that the cache gets a direct fast lookup of the vals, but later jl_normalize_to_compilable_mi (in jl_compile_method_internal) will ensure that we compile the jl_compilation_sig instead to compute the invoke, and then copy that pointer to the call.

I have the sense that some callers of jl_normalize_to_compilable_sig aren't correctly anticipating the need to verify the sparams they got back (generally they should check if they are egal to the original set going into it to verify whether it is valid to use that result directly)

Alternatively/additionally, we can go with this approach where we no longer cache that result, and instead rely on detecting on the fly whether sparam_vals has been computed already or not and re-computing them every time you call the method.

[JeffBezanson]

The intent was definitely to have the values already computed by this point since the type intersection is very expensive.

[KristofferC]

Also happens on CI, cf https://buildkite.com/julialang/julia-master/builds/44393#0194d263-5517-42e3-9822-8f8355888d33