Add a procedural macro frontend

[jplatte]

This is a tracking issue for the proc-macro work, initially discussed in #385, on Matrix and recently in a video meeting.

Outline

• Introduce an attribute #[uniffi::export] that can go onto functions and impl blocks
  • Attributes like #[uniffi::default] will be used to express binding properties that can't be expressed in Rust directly¹
• Introduce a derive attribute uniffi::FfiConvertible to allow a custom type to be used in the FFI API²
  • Attributes like #[uniffi(default)] will be used to express binding properties that can't be expressed in Rust directly³

Progress

• Functions
  • Argument passing
  • Return value passing
  • Fallible (returning Result<T, E>)
  • Argument defaults
• Types
  • Primitives
  • Arc<_>
  • By-value structs and enums
    • Field defaults
  • Enums
  • External types
• Parsing #[doc = "…"] attributes
• impl blocks
  • Associated functions (static methods in some target languages)
  • (True) methods with self parameters
  • Recognize Self keyword
  • Constructors (#[uniffi::constructor])
• Traits
• Callback interfaces

¹ Using custom syntax like foo: u32 = 0 the parameter list would be possible, but it's undesireable because (a) it would be confusing and (b) it would degrade IDE functionality
² This could be handled by the same #[uniffi::export] attribute but that's undesireable for technical reasons
³ Syntax difference is warranted due to proc-macro peculiarities

I can elaborate on any of these footnotes if somebody wants to know more ^^

┆Issue is synchronized with this Jira Task
┆friendlyId: UNIFFI-168

[jplatte]

About the current status: Some things have their boxes ticked but don't have PRs yet. The reason for that is that most of the work I've been doing so far has not been under the assumption that we'll want to mix UDL and proc-macro interface definitions. However, recently I realized that this shouldn't be so hard and has a number of big advantages:

• Individual proc-macro bits can be tested and used ahead of achieving feature parity
  • This also means small PRs are possible, which makes collaboration on this much easier
• Incrementally porting an existing UDL-using codebase is possible

You can expect the first proc-macro PRs this week though 😉

[jplatte]

Also I have a question that I wasn't sure whether to ask here or on Matrix:

Why does the current scaffolding contain a separate FfiConverterTypeFooError instead of implementing RustBufferFfiConverter / FfiError for the user's FooError type directly?

[bendk]

Also I have a question that I wasn't sure whether to ask here or on Matrix:

Why does the current scaffolding contain a separate FfiConverterTypeFooError instead of implementing RustBufferFfiConverter / FfiError for the user's FooError type directly?

It's part of a general policy to not implement the trait on any user types, in case those types came from another crate. It doesn't make that much sense for error types, but I guess there's a chance.

Is this interfering with your work? Maybe we should try to tackle #1250 to simplify things.

[jplatte]

This issue has definitely served its purpose ^^