[vm/ffi] `FfiNative` return types treatment inconsistent with `asFunction`

[dcharkes]

@FfiNative<Handle Function()>('doesntmatter')
external String? doesntmatter();

https://dart-review.googlesource.com/c/sdk/+/252601/6/pkg/vm/testcases/transformations/ffi/ffinative.dart

asFunction and lookupFunction do not allow the return type to be sticter than Object when the native type is Handle.

The old natives do allow the return type to be stricter than Object.

It would be good to update FfiNatives to be consistent with asFunction, but that would make them inconsistent with old natives.

[mkustermann]

@dcharkes The code you are quoting is not executed but rather there for generating expectation files of what the transformer produces. So there's no issue with this code. It doesn't really matter whether its String? or Object?.

[dcharkes]

If we add static linking, this will be transformed to an immediate FFI call that does not do a type check on the result value, allowing non String?s to flow there. (I haven't checked if the current transform does add a type check, maybe it also doesn't.)

I've disallowed that behavior in the linked CL, so I had to update the transformer test to make it pass again.

[mkustermann]

Whether one uses static or dynamic linking shouldn't change any behavior.

Whether we trust the types written by the developer is another question entirely: If user writes Int8 we expect native function takes int8_t. If user writes String? we expect native code to return null | String. We could check explicitly via as-check or not - that's a choice. Irrespective of what choice we make, it will be true for dynamic (e.g. lookupFunction) or static binding (@FfiNative)

Coming back to the test itself: It just checks how the transform handles returning Handle and uses String? but could use any other type.

Maybe I misunderstand the concern here?

[dcharkes]

Whether one uses static or dynamic linking shouldn't change any behavior.

For asFunction and lookupFunction we opted to only allow Object as return value. For FfiNative we apparently opted to let the user specify a more narrow type. This is inconsistent. We should fix this inconsistency. Using asFunction or dynamic FfiNative linking shouldn't change any behavior.

Whether we trust the types written by the developer is another question entirely: If user writes Int8 we expect native function takes int8_t. If user writes String? we expect native code to return null | String. We could check explicitly via as-check or not - that's a choice. Irrespective of what choice we make, it will be true for dynamic (e.g. lookupFunction) or static binding (@FfiNative)

Agreed, it is a choice we make. I assume we made that choice consciously for asFunction and lookupFunction when adding Handles. For FfiNatives, we have a function dedicated specifically to this behavior, indicating deviating from asFunction intentionally, but I cannot find any reasoning for this on the CL. (And I didn't catch the differing behavior when reviewing it.)

I propose we stick to asFunction behavior. We can always allow developers to write stricter types later if need be. The other way around would be a breaking change later.

[mkustermann]

For asFunction and lookupFunction we opted to only allow Object as return value. For FfiNative we apparently opted to
let the user specify a more narrow type. This is inconsistent.

Thanks for the explanation - it's the inconsistency you're concerned about (though that's not related to the test that is quoted in this issue).

I'd like to avoid a situation where we do more checking for @FfiNative as we do for normal natives. So if the ladder doesn't check, I don't think we should check by-default (maybe in --enable-assertions mode).

[dcharkes]

it's the inconsistency you're concerned about

Yes, sorry for the confusion. Thanks for helping me clarify. 😄

though that's not related to the test that is quoted in this issue

By removing the inconsistency (by only allowing Object) the test started failing.

I'd like to avoid a situation where we do more checking for @FfiNative as we do for normal natives. So if the ladder doesn't check, I don't think we should check by-default (maybe in --enable-assertions mode).

By only allowing Object, we need no checking.
Of course a subsequent as check by users will introduce a check.

If we want to avoid those user-written as checks, we should change asFunction and lookupFunction to allow stricter return types instead.