C# future simple codegen #1357
C# future simple codegen #1357
Conversation
yowl
force-pushed
the
csharp-future-simple
branch
from
b14b14b to
c3fce61
Compare
|
Thanks for doing this, @yowl! I'm planning to review it by the end of the week. |
dicej
left a comment
dicej
left a comment
There was a problem hiding this comment.
Thanks for doing this! Looks like a good start; please see my comments inline.
| let op = &operands[0]; | ||
| self.interface_gen.add_future(self.func_name); | ||
|
|
||
| results.push(format!("{op}.Handle")); |
There was a problem hiding this comment.
FutureReader should probably have a TakeHandle() method that zeros out the handle field (and asserts that it wasn't already zero) before returning the original value so that the application won't accidentally try to use the no-longer-valid handle.
There was a problem hiding this comment.
I've done this, but not sure I understand in what situation it would be used.
There was a problem hiding this comment.
Sorry, I meant not only that we should add a FutureReader.TakeHandle() method but that we should use it here (instead of just reading the Handle field) for the Instruction::FutureLower { .. } case.
| .interface_fragments | ||
| .push(InterfaceFragment { | ||
| csharp_src: format!(r#" | ||
| public class FutureReader{future_type_name} : FutureReader |
There was a problem hiding this comment.
Have you considered making FutureReader and FutureWriter generic classes rather than generating separate classes for each payload type? That's what we do in Rust and in Go, for example. Note how we use "vtable"-style structure in both Rust and Go to specialize the implementations internally. Happy to discuss further if this isn't clear.
There was a problem hiding this comment.
Is there a test that exercises the generic types with more than one concrete implementation?
There was a problem hiding this comment.
nevermind, I've found what I was missing
Combine FutureReader and FutureWriter to AsyncSupport. Start the process of adding futures per type
2 participants
This PR adds enough code gen to support the simple-future wit runtime test. As for the async PR, this is pretty much the minimum PR in terms of future support. I've not tackled the typed canonical methods except to add a "void" implementation which is hard coded as the one to use.
Have followed the c test cases rather than the rust ones.
Also changed Export and Import in namespaces to be uppercase and moved resources and other methods to the appropriate import or export class. Some types are still produced from the import side, and have introduced a concept of a bidirectional type (enum, flags) that sit above the import/export split.
The current codegen produced is at https://github.com/yowl/wit-bindgen-simple-future