Forbid returning and passing tuples to FFI functions #2012
Conversation
Praetonus
added
the
changelog - changed
src/libponyc/expr/ffi.c
Outdated
|
|
||
| if(!intrinsic && (ast_id(decl_ret_type) == TK_TUPLETYPE)) | ||
| { | ||
| ast_error(opt->check.errors, decl_ret_type, "FFIs cannot return tuples"); |
There was a problem hiding this comment.
It's just a small tweak, but for consistency with some of the other compiler messages, I'd prefer to phrase this as "an FFI function cannot return a tuple".
|
After fiddling with the Clang API, I realised that setting up the interoperability might be easier than I initially thought. I'll probably have a basic implementation soon, so I'll mark this PR as DO NOT MERGE. If I encounter a major difficulty with Clang, then we can unblock this PR until it is sorted out. |
|
Actually, the interoperability won't be easy to implement because an important functionality (converting Clang types to LLVM types) is only part of Clang's internals and wouldn't be practical to replicate in ponyc. I'm going to submit a patch to Clang to expose that interface. |
|
@aturley does this impact on any of our sendence language binding code? |
|
As discussed on sync, this is ready to merge, but we wanted to give @SeanTAllen and/or @aturley a chance to raise objections first. |
|
@aturley is really the one who needs to weigh in... |
|
@SeanTAllen @jemc this doesn't impact us. |
|
Okay, then this is good to merge once @Praetonus resolves the merge conflicts. |
Passing complex objects by value in C is hard: there are many different calling conventions depending on the platform. For example, a C compiler is allowed to split the members of an object into different parameters, or to change the return value into an out parameter. The Pony compiler currently uses a naive implementation to pass objects to FFI functions and isn't able to use the correct calling convention for every call. Ideally, we'd want to rely on a C compiler API (like LibClang) to generate the correct signatures and calls. This change is a temporary measure to avoid spurious FFI bugs until we have the interoperability detailed above. LLVM intrinsics are still allowed to return and be passed tuples since their signatures are defined by LLVM.
|
Conficts fixed, CI is passing, merging. |
This removes the checks that were introduced in PR ponylang#2012 that only allow intrinsic FFI calls to use tuples. Now, tuples can again be passed into and returned from FFI functions (with all previously identified limitations).
This removes the checks that were introduced in PR ponylang#2012 that only allow intrinsic FFI calls to use tuples. Now, tuples can again be passed into and returned from FFI functions (with all previously identified limitations).
This removes the checks that were introduced in PR #2012 that only allow intrinsic FFI calls to use tuples. Now, tuples can again be passed into and returned from FFI functions (with all previously identified limitations).
Passing complex objects by value in C is hard: there are many different calling conventions depending on the platform. For example, a C compiler is allowed to split the members of an object into different parameters, or to change the return value into an out parameter.
The Pony compiler currently uses a naive implementation to pass objects to FFI functions and isn't able to use the correct calling convention for every call. Ideally, we'd want to rely on a C compiler API (like LibClang) to generate the correct signatures and calls.
This change is a temporary measure to avoid spurious FFI bugs until we have the interoperability detailed above. LLVM intrinsics are still allowed to return and be passed tuples since their signatures are defined by LLVM.