Add derive macros for Dispatch, ExtensionDispatch

[robin-nitrokey]

Please don’t look at the macro implementation yet, it’s quite messy at the moment. Instead look at the diff for tests/backend.rs and tests/serde_extensions.rs to see the derive macros in action. The current syntax is:

#[derive(Default, trussed::backend::Dispatch)]
#[dispatch(backend_id = "Backend")]
struct Dispatch {
    test: TestBackend,
}

#[derive(Default, ExtensionDispatch)]
#[dispatch(backend_id = "Backend", extension_id = "Extension")]
#[extensions(Test = "TestExtension", Sample = "SampleExtension")]  // maps the extension ID to the type
pub struct Backends {
    #[extensions("Test")]  // declares the extensions supported by this backend
    test: TestBackend,
    #[extensions("Test", "Sample")]
    sample: SampleBackend,
}

What do you think?

---

Missing features:

• providing different sets of extensions for the same backend with the different IDs
• having multiple extensions attributes to simplify conditional compilation
• warn if an extension is declared but not implemented

[robin-nitrokey]

@daringer @sosthene-nitrokey Any thoughts on the syntax? I think it would make it much easier to maintain the dispatch implementations.

[daringer]

This hides a lot of redundant code, I love it! especially here: https://github.com/trussed-dev/trussed/pull/98/files#diff-203bd1efad2e5b766e73f7058bc930bc35004df65aeb5088a6c5845f662bdd43L383 lot of boilerplate stuff just gone... +1

[sosthene-nitrokey]

My main concern is whether it can do what we do with the Manage extensions, that have a specific Backend ID to be used, so that an app with access to the StagingBackend or the Se050Backend cannot access it (and instead needs the StagingManage and Se050Manage backend Ids configured.

Other than that, i would put the extensions into the dispatch attribute so that only one "attribute namespace" is used.

#[derive(Default, trussed::backend::Dispatch)]
#[dispatch(backend_id = "Backend")]
struct Dispatch {
    test: TestBackend,
}

#[derive(Default, ExtensionDispatch)]
#[dispatch(backend_id = "Backend", extension_id = "Extension")]
#[dispatch(extensions(Test = "TestExtension", Sample = "SampleExtension"))]  // maps the extension ID to the type
pub struct Backends {
    #[dispatch(extensions("Test"))]  // declares the extensions supported by this backend
    test: TestBackend,
    #[dispatch(extensions("Test", "Sample"))]
    sample: SampleBackend,
}

[robin-nitrokey]

My main concern is whether it can do what we do with the Manage extensions, that have a specific Backend ID to be used, so that an app with access to the StagingBackend or the Se050Backend cannot access it

I don’t see a problem with that. We can just use fields with different names but the same type. I think something like this should already work with the current implementation:

#[derive(Default, ExtensionDispatch)]
#[dispatch(backend_id = "Backend", extension_id = "Extension")]
#[extensions(Test = "TestExtension", Special = "SpecialExtension", Sample = "SampleExtension")]
pub struct Backends {
    #[extensions("Test")]
    test: TestBackend,
    #[extensions("Test", "Special")]
    test_special: TestBackend,
    #[extensions("Test", "Sample")]
    sample: SampleBackend,
}

Other than that, i would put the extensions into the dispatch attribute so that only one "attribute namespace" is used.

I also thought about that, but on the other hand, it just adds more boilerplate code without real benefit. And looking at the most popular derive crates, using multiple attributes is quite common. For example, clap uses multiple attributes to group options logically.

[robin-nitrokey]

If we don’t want to duplicate the backend, we could probably use a special attribute like:

#[derive(Default, ExtensionDispatch)]
#[dispatch(backend_id = "Backend", extension_id = "Extension")]
#[extensions(Test = "TestExtension", Special = "SpecialExtension", Sample = "SampleExtension")]
pub struct Backends {
    #[extensions("Test")]
    test: TestBackend,

    #[extensions("Test", "Special")]
    #[dispatch(delegate_to = "test")]
    test_special: TestBackend,

    #[extensions("Test", "Sample")]
    sample: SampleBackend,
}

[sosthene-nitrokey]

If we don’t want to duplicate the backend, we could probably use a special attribute like:

#[derive(Default, ExtensionDispatch)]
#[dispatch(backend_id = "Backend", extension_id = "Extension")]
#[extensions(Test = "TestExtension", Special = "SpecialExtension", Sample = "SampleExtension")]
pub struct Backends {
    #[extensions("Test")]
    test: TestBackend,

    #[extensions("Test", "Special")]
    #[dispatch(delegate_to = "test")]
    test_special: TestBackend,

    #[extensions("Test", "Sample")]
    sample: SampleBackend,
}

Would that work for a #[derive] macro? I think test_special would still be a member of the struct at the end since derive macros can't change the struct definition itself.

[robin-nitrokey]

Hmm, then we could change the type to (). Anyway, I would suggest to first merge a version without duplicate backends. We can then add that feature in a second step.

[sosthene-nitrokey]

Yes

[robin-nitrokey]

Updated:

• Rebased onto main.
• Upated syn dependency to v2.
• Made the implementation more robust and improved error messages.
• Added examples.

[robin-nitrokey]

Updated:

• Made the extensions attribute optional for backends in ExtensionDispatch.
• Added an ExtensionId derive macro that implements From<T> for u8 and TryFrom<u8> for T.