Create a macro to replace the LoadTransformAndSave generic type.

[andriyDev]

Objective

• While writing the Bevy book docs for asset processing, I realized how painful it is to create even simple processors.
• When registering LoadTransformAndSave processors, you need to repeat the very long type usually twice. This type is also repeated within meta files (Make write_default_meta_file_for_path write the short type path instead of the long type path. #22208 and Allow using short type names for asset processors. #21339 made this shorter, but it's still long). It also makes the meta files have not very descriptive names.

Solution

• Create a (declarative) macro to create the processor based on a (fake) type definition.
  • We can bike shed this if we want - I went for what is hopefully intuitive and convenient to write, rather than what is actually correct (e.g., the fake type defines the loader as a field, even though the actual generated type hard-codes using the loader type (and no actual loader value).
  • Previously, I've heard some users thinking that LoadTransformAndSave is the asset processor API, and so users concluded the processing API is much more limited than it is. I think a macro that generates a new type will hopefully give the vibe that it's just a type and there's something more fundamental going on.
• Deprecate the LoadTransformAndSave.

Relying on a macro is a little gross, but that's the price of relying on type paths to identify items. The previous state highly discouraged expanding on processors (e.g., with generics), because it meant the type path would only get gnarlier.

An alternative could be to allow users to define aliases to processors, but I'm not super keen on that solution, since now we need to disambiguate between long type paths, short type paths, and aliases.

Testing

• Updated the tests.
• Ran the asset_processing example and it still works after updating its meta file.

---

Showcase

Now instead of:

app.register_asset_processor(
    LoadTransformAndSave::<MyLoader, _, _>::new(
        MyTransformer::new(),
        MySaver::new()
    )
)
.set_default_processor::<LoadTransformAndSave<MyLoader, MyTransformer, MySaver>>("myext");

You can instead write:

make_load_transform_and_save_processor!(
    struct MyProcessor {
        loader: MyLoader,
        transformer: MyTransformer,
        saver: MySaver,
    }

    struct MyProcessorSettings { .. }
);

app.register_asset_processor(
    MyProcessor::new(
        MyTransformer::new(),
        MySaver::new()
    )
)
.set_default_processor::<MyProcessor>("myext");

[Diddykonga]

LGTM
The contextual names will be nice, only thing to worry about is potential code dupe with overlapping processor abstractions, although I dont know how often that will happen in practice.

Normally not a fan of macros, except in two situations:

1. copy-pasta, when the impl is almost always the same, to get rid of repetition.
2. syntax/semantics support not provided by rust, bsn is a great example.

This falls cleanly into 1.

[JMS55]

I don't know that I like this. My gut reaction is that this is more confusing than just repeating the verbose bits.

What I think we should actually do is not require you to register LoadTransformAndSave<L, T, S> directly, but instead register each of those individual parts, and then Bevy should be automatically able to compose them when LoadTransformAndSave<L, T, S> is specified in the meta file.