Rewrite a TODO as a note (#4218)

* Rewrite a TODO as a note

With WebAssembly/component-model#35 this is no longer a TODO

* typo

crates/wasmtime/src/component/func/typed.rs

@@ -1617,28 +1617,25 @@ where
     }
 
     fn lift(store: &StoreOpaque, options: &Options, src: &Self::Lower) -> Result<Self> {
-        // TODO: need to make a case that upper-bits are not validated to be
+        // Note that this implementation specifically isn't trying to actually
-        // zero.
+        // reinterpret or alter the bits of `lower` depending on which variant
+        // we're lifting. This ends up all working out because the value is
+        // stored in little-endian format.
         //
-        // * `Result<u32, u64>` flattens as `i32 i64`
+        // When stored in little-endian format the `{T,E}::Lower`, when each
-        // * This impl wants to say `0 u64::MAX` is a valid flattening of
+        // individual `ValRaw` is read, means that if an i64 value, extended
-        //   `Ok(u32::MAX)`.
+        // from an i32 value, was stored then when the i32 value is read it'll
-        // * Otherwise validation needs to be performed that, where necessary,
+        // automatically ignore the upper bits.
-        //   upper bits are zero.
-        // * Points in favor:
-        //   * `Result<u32, (u32, u32)>` flattens as `i32 i32 i32` and
-        //     `Ok(0)` doesn't  validate that the third `i32` is any
-        //     particular value.
-        //   * Padding bytes are ignored in the in-memory representation.
         //
-        // Otherwise I don't know how to implement the validation for now. This
+        // This "trick" allows us to seamlessly pass through the `Self::Lower`
-        // would need to, at compile time via the Rust trait system, figure out
+        // representation into the lifting/lowering without trying to handle
-        // the flatten lowering for `Result<T, E>` for `T` and `E` and then ask
+        // "join"ed types as per the canonical ABI. It just so happens that i64
-        // `T`'s lowered type to validate that it's valid within the context of
+        // bits will naturally be reinterpreted as f64. Additionally if the
-        // the the overall lowered type. This... is trait trickery that is
+        // joined type is i64 but only the lower bits are read that's ok and we
-        // beyond me but seems like it should be possible. Would be nice if we
+        // don't need to validate the upper bits.
-        // didn't have to do that though.
+        //
-
+        // This is largely enabled by WebAssembly/component-model#35 where no
+        // validation needs to be performed for ignored bits and bytes here.
         Ok(match src.tag.get_i32() {
             0 => Ok(unsafe { T::lift(store, options, &src.payload.ok)? }),
             1 => Err(unsafe { E::lift(store, options, &src.payload.err)? }),