Errors Produced in `try_lift` are difficult to Debug.

[oldwomanjosiah]

trafficstars

Recently I was working on adding support for sending [Uuid] across the FFI boundary as a String. Originally, I had introduced this conversion using a bare

use uuid::Uuid;

uniffi::custom_type!(Uuid, String, { remote });

This appeared to work on Android and iOS when converting from ParcelUuid and CBUUID respectively, but would periodically crash with just "invalid length: expected length 32 for simple format, found 4" when running on iOS. This message is coming from the error returned from Uuid::try_from(String), which was being lifted for a field of type Vec<Uuid>, and was being passed a short UUID as specified by Bluetooth 4.

I understand that this isn't necessarily this libraries responsibility, but it would be really nice if (when the ffi-trace feature is enabled) more context would be attached to the anyhow report to aid in debugging.

I'm thinking:

1. Unconditionally attach type names and source location information to custom_type!() invocations.
2. When ffi-trace is enabled:
   • Attach type name in try_lift
   • Attach field name in try_read_field