FFI creates closures which are not present in the kernel program

[alexmarkov]

NativeFunctionPointer.asFunction and DynamicLibraryExtension.lookupFunction from dart:ffi are implemented using opaque _asFunctionInternal which is declared in the following way:

@pragma("vm:recognized", "other")
@pragma("vm:external-name", "Ffi_asFunctionInternal")
external DS _asFunctionInternal<DS extends Function, NS extends Function>(
    Pointer<NativeFunction<NS>> ptr, bool isLeaf);

_asFunctionInternal can magically create and return closures which are not present in the kernel program. As a result, whole-program analysis (TFA) cannot see all possible closures in the program which hinders its ability to analyze possible targets of closure calls (this issue blocks #39692).

I see the following possible solutions:

• Change FFI transformation to create those closures explicitly in kernel AST.
• Replace those closures with tear-offs of (external) trampoline methods, taken explicitly in kernel AST.
• Recognize and handle _asFunctionInternal specially during TFA (maybe add a special pragma for that purpose).

@dcharkes @mkustermann Thoughts?

[dcharkes]

👍 for addressing this.

Change FFI transformation to create those closures explicitly in kernel AST.

I guess the challenge is to wire up what we would create in the kernel AST with what's constructed in BuildFfiAsFunctionInternal and BuildFfiAsFunctionInternalCall. If we create a closure in kernel already, then we need to mark it somehow so that we can recognize it (for example with a pragma such as IsCachableIdempotent, instead of as a recognized method like it is now).

Nothing pops up in my mind why creating the closures in kernel wouldn't work, but I haven't paged everything atm.

Replace those closures with tear-offs of (external) trampoline methods, taken explicitly in kernel AST.

Are you saying you want to create a kernel node of a tear-off invocation? And then wire that up BuildFfiAsFunctionInternal and BuildFfiAsFunctionInternalCall? What's the difference with option 1? Or is it mostly similar? Shouldn't the closure in option 1 also be external or have a bogus body?

Or did you mean something completely different with this option.

Recognize and handle _asFunctionInternal specially during TFA (maybe add a special pragma for that purpose).

That seems like the least clean solution. However, it would allow us to leave FFI internals untouched and might be reusable for other things. It would be kind of similar in nature to the _nativeEffect.

I don't have a strong opinion about which option to choose I think.