C# future simple codegen

[yowl]

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

[yowl]

cc @pavelsavara @dicej @jsturtevant

[dicej]

Thanks for doing this, @yowl! I'm planning to review it by the end of the week.

[dicej]

Thanks for doing this! Looks like a good start; please see my comments inline.

[dicej]

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.

[yowl]

I've done this, but not sure I understand in what situation it would be used.

[dicej]

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.

[dicej]

Suggested change

	results.push(format!("{op}.Handle"));
	results.push(format!("{op}.TakeHandle()"));

[yowl]

@dicej Hi, I think I've covered the points from the review now, was a bit of a change for the generic refactoring, sorry about that churn.

[dicej]

Thanks for continuing to iterate on this, @yowl, and sorry for the delayed review.

Looks good overall; just a few more comments inline.

[dicej]

Nit: consider naming this waitableSet or handle. The name waitable is a bit confusing since that term means something else in the component model.

[dicej]

Should check here to see if Handle is zero and throw an exception if so.

[dicej]

Should only call this if Handle != 0

[dicej]

Should throw exception if Handle == 0 here.

[dicej]

Should only call this if Handle != 0

[dicej]

Should throw exception if Handle == 0 here.

[dicej]

Should only call this if Handle != 0.

[dicej]

Suggested change

	//let ty = self.r#gentype_name(ty);
	//let ty = self.interface_gen.type_name(ty);

Or can we just get rid of this line?

[dicej]

Suggested change

	results.push(format!("{op}.Handle"));
	results.push(format!("{op}.TakeHandle()"));

[dicej]

If desired, you can return true here for any type that doesn't refer transitively to an exported resource. For Go, we use this function to determine whether the type can be shared or not.

[yowl]

Thanks for the tip, I had a go at this, no pun intended, but I have a question. Types are added from the import_types method, and that is where the resources are added in C#, is that where Go adds the resources as well? I ask because the `has_exported_resource`` function checks for the resource being in the export direction.

[dicej]

My recollection is that import_types is used for types imported at the world level, but that interface-level types are added in import_interface and export_interface, respectively:

wit-bindgen/crates/go/src/lib.rs

Lines 680 to 689 in 85369ad

	let mut data = {
	let mut generator = InterfaceGenerator::new(self, resolve, Some((id, name)), true);
	for (name, ty) in resolve.interfaces[id].types.iter() {
	if !generator.generator.types.contains(ty) {
	generator.generator.types.insert(*ty);
	generator.define_type(name, *ty);
	}
	}
	InterfaceData::from(generator)
	};

wit-bindgen/crates/go/src/lib.rs

Lines 730 to 751 in 85369ad

	for (type_name, ty) in &resolve.interfaces[id].types {
	let exported = matches!(resolve.types[*ty].kind, TypeDefKind::Resource)
	|| self.has_exported_resource(resolve, Type::Id(*ty));
	let mut generator = InterfaceGenerator::new(self, resolve, Some((id, name)), false);
	if exported || !generator.generator.types.contains(ty) {
	generator.generator.types.insert(*ty);
	generator.define_type(type_name, *ty);
	}
	let data = generator.into();
	if exported {
	&mut self.export_interfaces
	} else {
	&mut self.interfaces
	}
	.entry(interface_name(resolve, Some(name)))
	.or_default()
	.extend(data);
	}

Note the logic that sorts types according to has_exported_resource.

Anyway, don't worry about this for now; this PR is big enough as it is, so we can follow up with type sharing tweaks later.