bevy_reflect: Recursive registration

[MrGVSV]

Objective

Resolves #4154

Currently, registration must all be done manually:

#[derive(Reflect)]
struct Foo(Bar);

#[derive(Reflect)]
struct Bar(Baz);

#[derive(Reflect)]
struct Baz(usize);

fn main() {
  // ...
  app
    .register_type::<Foo>()
    .register_type::<Bar>()
    .register_type::<Baz>()
    // .register_type::<usize>() <- This one is handled by Bevy, thankfully
  // ...
}

This can grow really quickly and become very annoying to add, remove, and update as types change. It would be great if we could help reduce the number of types that a user must manually implement themselves.

Solution

As suggested in #4154, this PR adds automatic recursive registration. Essentially, when a type is registered, it may now also choose to register additional types along with it using the new GetTypeRegistration::register_type_dependencies trait method.

The Reflect derive macro now automatically does this for all fields in structs, tuple structs, struct variants, and tuple variants. This is also done for tuples, arrays, Vec<T>, HashMap<K, V>, and Option<T>.

This allows us to simplify the code above like:

#[derive(Reflect)]
struct Foo(Bar);

#[derive(Reflect)]
struct Bar(Baz);

#[derive(Reflect)]
struct Baz(usize);

fn main() {
  // ...
  app.register_type::<Foo>()
  // ...
}

This automatic registration only occurs if the type has not yet been registered. If it has been registered, we simply skip it and move to the next one. This reduces the cost of registration and prevents overwriting customized registrations.

Considerations

While this does improve ergonomics on one front, it's important to look at some of the arguments against adopting a PR like this.

Generic Bounds

Since we need to be able to register the fields individually, we need those fields to implement GetTypeRegistration. This forces users to then add this trait as a bound on their generic arguments. This annoyance could be relieved with something like #5772.

This is no longer a major issue as the Reflect derive now adds the GetTypeRegistration bound by default. This should technically be okay, since we already add the Reflect bound.

However, this can also be considered a breaking change for manual implementations that left out a GetTypeRegistration impl or for items that contain dynamic types (e.g. DynamicStruct) since those also do not implement GetTypeRegistration.

Registration Assumptions

By automatically registering fields, users might inadvertently be relying on certain types to be automatically registered. If Foo auto-registers Bar, but Foo is later removed from the code, then anywhere that previously used or relied on Bar's registration would now fail.

---

Changelog

• Added recursive type registration to structs, tuple structs, struct variants, tuple variants, tuples, arrays, Vec<T>, HashMap<K, V>, and Option<T>
• Added a new trait in the hidden bevy_reflect::__macro_exports module called RegisterForReflection
• Added GetTypeRegistration impl for bevy_render::render_asset::RenderAssetUsages

Migration Guide

All types that derive Reflect will now automatically add GetTypeRegistration as a bound on all (unignored) fields. This means that all reflected fields will need to also implement GetTypeRegistration.

If all fields derive Reflect or are implemented in bevy_reflect, this should not cause any issues. However, manual implementations of Reflect that excluded a GetTypeRegistration impl for their type will need to add one.

#[derive(Reflect)]
struct Foo<T: FromReflect> {
  data: MyCustomType<T>
}

// OLD
impl<T: FromReflect> Reflect for MyCustomType<T> {/* ... */}

// NEW
impl<T: FromReflect + GetTypeRegistration> Reflect for MyCustomType<T> {/* ... */}
impl<T: FromReflect + GetTypeRegistration> GetTypeRegistration for MyCustomType<T> {/* ... */}

[jakobhellermann]

I don't really like that GetTypeRegistration now becomes something people need to think about for generic type parameters. I thought about adding it as a supertrait to Reflect but DynamicX types don't implement it of course.
With bevyengine/rfcs#56 we can add it as a supertrait, right? (with a where Self: Sized bound to keep object safety)

[MrGVSV]

This is why I’d really like #5772 to get merged. It would combine all these core traits into one that does not need to worry about object-safety

[jakobhellermann]

But it still introduces another trait. It would be nice if T: Reflect just worked.

[MrGVSV]

Yeah but it means we keep it to two traits that a user must know (Reflect or Reflectable), even as we add more and more core traits.

Separating traits is also about readability imo so if we did combine everything then we'd eventually end up with a potentially massive trait

[MrGVSV]

We might actually be able to improve the usability here by adding GetTypeRegistration to the where clause of the impl like we do with Reflect 🤔

---

Tasks

• Do this

[alice-i-cecile]

@MrGVSV say the word and I'll merge this in :) @SkiFire13 or @soqb your review on the last batch of changes would be nice too.

[MrGVSV]

@MrGVSV say the word and I'll merge this in :) @SkiFire13 or @soqb your review on the last batch of changes would be nice too.

I mean I’m happy with it haha. We could maybe schedule it to be merged as part of the merge train tomorrow in case anyone has any last minute concerns?

[alice-i-cecile]

Great: removing the controversial label for now so I don't miss it 😅

[james7132]

One final thing that came to mind was maybe to annotate register_type_dependencies as #[inline(never)] to avoid excessive code generation at compile time.

[MrGVSV]

One final thing that came to mind was maybe to annotate register_type_dependencies as #[inline(never)] to avoid excessive code generation at compile time.

@james7132 Annotate just the default trait method or add it to the generated GetTypeRegistration impls?

[james7132]

@james7132 Annotate just the default trait method or add it to the generated GetTypeRegistration impls?

The empty default is fine, but the ones that have an actual body need to be annotated to avoid inlining the recursion.

[SkiFire13]

LGTM, although the #[inline(never)] feels like premature optimizations. Is it certain that LLVM will inline that method normally (and that this will actually be bad, since it seems it's only used in one function)?