I wasn't expecting this sort of machinery to be required - we can't get away with implementing the DescriptorsRef methods on WasiPreview1Ctx? I can't intuit where the problem is in a more straightforward implementation, so if this is required, lets leave a comment on the struct definition explaining why.

I'll add a comment, but the biggest reasons why this is required are:

1. By far the biggest issue is bindgen generating host methods with &mut self receivers, preventing e.g. simultaneous lazy initialization of the descriptor table and calling a preview2 method using any data borrowed from that table, even looking up something like table().is_file is problematic
2. WasiPreview1Adapter (assuming that's what you meant by WasiPreview1Ctx) does not have access to preview2 functionality and/or the underlying table, so it cannot initialize itself using something like https://docs.rs/once_cell/latest/once_cell/sync/struct.Lazy.html . Lazily initializing the descriptor map requires access to both the WasiPreview1Adapter and wasi::preopens::Host, so the only place where this functionality could exist is in an extension trait (WasiPreview1ViewExt). Note that from within this trait, we can never return anything borrowed directly, because we'd first need to call adapter_mut() to get access to the state (which we may need to lazily initialize). And even if we had a way to return a borrowed descriptor table directly, it would not be possible to call any other method on self due to 1., since that would cause a double mutable borrow, which is not allowed.

In short, an alternative solution would be storing Option<Arc<Mutex<Descriptors>>> in the adapter and returning Arc<Mutex<Descriptors>> in the WasiPreview1AdapterExt::descriptors(&mut self) method, which IMO is way more awkward to work with and simply redundant complexity.
Overall, the DescriptorsRef is just a workaround for bindgen design drawbacks. I believe this could be simplified dramatically if host methods would just take &self

That makes sense. Thank you.

We should look into adding a bindgen option to enable &self receivers in the future, and then we may be able to unwind a bit of this complexity. For now, this is a fine implementation once it has a comment.

I've added a few comments and renamed the struct to Transaction so it's a bit more obvious what it actually is

this is still a todo!() - we can leave it to a follow up PR, but unreachable!() communicates to me that it is a bug in this code if it is reachable, while this is reachable from any guest program.

I took this directly from

and it was surprising to me as well.
It seems to me that the adapter has to implement rights handling, which the existing one does not do. I'll mark this as todo! and file an issue for rights handling follow-up

Oh, that is indeed a bug in the component adapter as well. unreachabable!() is just how we spell todo!() and panic!() and etc over there since we cant use std's macros.

In the legacy implementation, set_rights is a no-op, it only validates the fd. That is the correct behavior for both of these spots. Would you mind making this fix to the component adapter as well?

Let's take care of it as part of #6446 ?