Rust trait support in the AST/HIR/macro, and codegen for C #621
Conversation
emarteca
force-pushed
the
foreign_traits
branch
from
f8fa36a to
c809f71
Compare
There was a problem hiding this comment.
From the HIR design I think types and traits should be treated as completely distinct beings, with separate lookups.
It's fine for the lookup to overlap in the AST since it's useful to be able to have the error "you typed Trait, did you mean impl Trait" during lowering, but otherwise I don't think traits should have TypeIds or live under TypeDef/etc
Sounds good, that makes sense! I just pushed a refactor that splits traits out from this infra in the HIR -- we added |
emarteca
changed the title
emarteca
force-pushed
the
foreign_traits
branch
from
d758fe8 to
e637b56
Compare
|
Force-pushing to rebase onto main (now including the callbacks code that's in main) |
|
Macro and C codegen are up -- tomorrow I'll add it to the proper code infrastructure and fix the lints errors/etc |
emarteca
force-pushed
the
foreign_traits
branch
from
ff5c0dc to
048ee7a
Compare
|
Force pushing to rebase with main again |
|
Macro and C codegen are up and tested, and all the github action tests are passing -- I think this code is ready for review! |
…ument, instead of hardcoded wrapping it
…e is an input-only struct
First version of representing function types at the AST level, and of lowering these to HIR callback types. Note: here the HIR Callback converted back to Everywhere for simplicity; see TODOs in the code
…are not representable
…Position InputOnly and Everywhere; propagating this through the tool
emarteca
force-pushed
the
foreign_traits
branch
from
b58ef64 to
550db53
Compare
|
Addressed code review + rebase with main (hence force push) |
| unsafe extern "C" fn(*const c_void, diplomat_runtime::DiplomatSlice<u8>) -> i32, | ||
| } | ||
| #[repr(C)] | ||
| pub struct DiplomatTraitStruct_TesterTrait { |
There was a problem hiding this comment.
thought: an annoying thing about this is that someone wishing to use TesterTrait in a different module will have to manually import this type, which we haven't typically needed in the macro. It's tricky to avoid though, the main thing I can think of is scouring the imports for TesterTrait and tacking on an additional import of the trait struct.
There was a problem hiding this comment.
Oh yeah that's a good point. I guess we can add a note about that in the docs; I can't think of how to avoid it
This is built on top of the WIP pull request for callback support (#552).
It is a manual example of a C representation of a Rust trait
TestingTrait, that can be passed to a Rust function expecting an object implementing this trait.The files to look at are example/simple_testing/src/lib.rs for the Rust code (including what we think should be generated), and example/simple_testing/main.c for the C code (including what we think should be generated).
We've written our design out in this linked doc. Feedback welcome! :-)