Reflect auto registration

[eugineerd]

Objective

This PR adds automatic registration of non-generic types annotated with #[derive(Reflect)].
Manually registering all reflect types can be error-prone, failing to reflect during runtime if some type is not registered. #5781 fixed this for nested types, improving ergonomics of using reflection dramatically, but top-level types still need to be registered manually. This is especially painful when prototyping and using inspector to change values of components.

// from #5781
#[derive(Reflect)]
struct Foo(Bar);

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

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

fn main() {
  // ...
  app.register_type::<Foo>() // <- can still forget to add this
  // ...
}

Solution

Automatically register all types that derive Reflect. This works for all non-generic types, allowing users to just add #[derive(Reflect)] to any compatible type and not think about where to register it.

fn main() {
  // No need to manually call .register_type::<Foo>()
  App::new()
    .add_plugins(DefaultPlugins)
    .add_systems(Startup, setup)
    .run();
}

#[derive(Reflect)]
pub struct Foo {
  a: usize,
}

fn setup(type_registry: Res<AppTypeRegistry>) {
  let type_registry = type_registry.read();
  assert!(type_registry.contains(TypeId::of::<Foo>()));
}

Automatic registration can be opted-out of by adding #[reflect(no_auto_register)] reflect attribute to a type:

#[derive(Reflect)]
#[reflect(no_auto_register)]
pub struct Foo {
  a: usize,
}

Registration normally happens at app creation time, but TypeRegistry itself has a new register_derived_types method to register all collected types at any appropriate time:

#[derive(Reflect)]
struct Foo {
  name: Option<String>,
  value: i32
}

let mut type_registry = TypeRegistry::empty();
type_registry.register_derived_types();

assert!(type_registry.contains(TypeId::of::<Foo>()));

Testing

• Tested by running reflect example and removing explicit type registration, both on native and on wasm32-unknown-unknown.
• Added a doctest to register_derived_types

Impact on startup time is negligible: <40ms on debug wasm build and <25ms on debug native build for 1614 registered types .

Wasm binary size comparison. All sizes are in KB as reported by du on the modified reflection example.

	auto register, KiB	no auto register, KiB	abs diff, KiB	% diff
wasm-release && wasm-bindgen	27000	24224	2776	11.46%
wasm-opt -Oz	16376	15340	1036	6.75%
wasm-opt -Os	17728	16424	1304	7.94%
wasm-opt -Oz && gzip -c	5620	5364	256	4.77%

Considerations

While automatic type registration improves ergonomics quite a bit for projects that make heavy use of it, there are also some problems:

• Generic types can't be automatically registered. However, as long as top-level reflect types don't need generics, recursive registration can take care of the rest.
• Wasm bundle size increase is not insignificant. This is mostly due to registering various engine types that weren't registered before. Size overhead of automatic registration of types instead of manual is relatively small, as can be see from this (somewhat outdated but still relevant) table (see last 2 rows):

1000 simple structs with reflect wasm size comparison, no engine types

	auto register, KiB	no auto register, KiB	abs diff, KiB	% diff
wasm-release && wasm-bindgen	27944	21644	6300	22.55%
wasm-release && wasm-bindgen +register_type	28084	27764	320	1.14%
wasm-opt -Oz	15612	13928	1684	10.79%
wasm-opt -Oz +register_type	15676	15580	96	0.61%
wasm-release && wasm-bindgen (manual vs auto)	27944	27764	180	0.64%
wasm-opt -Oz (manual vs auto)	15612	15580	32	0.2%

[alice-i-cecile]

Wasm bundle size increase is not insignificant

Is this compared to the equivalent manual registration? Can / should we feature flag this for authors who particularly care?

[github-actions]

You added a new feature but didn't update the readme. Please run cargo run -p build-templated-pages -- update features to update it, and commit the file change.

[eugineerd]

Is this compared to the equivalent manual registration

As far as I understand it, wasm-init works by exporting a bunch of symbols to final wasm and calling them from outside when wasm_init() is called for the first time. I think most of the size increase is due to these exports, but I'm not sure. In the table I just built the modified registration example and compared the .wasm file sizes using du. As the number of registered types from type_registry.iter() differs (445 without, 614 with), it is not the same as manually registering types.

[eugineerd]

Managed to reduce wasm size considerably by removing closures from automatic type registration:

All sizes are in KB as reported by du on reflection example.

	wasm-release && wasm-bindgen	wasm-opt -Oz	wasm-opt -Os	wasm-opt -Oz && gzip -c
+reflect_auto_register	22560	14332	15352	5044
default	21716	13968	14896	4944
diff	+3.7%	+2.5%	+3%	+2%

I'm not very familiar with all the internal reflection machinery, maybe this can be optimized even further?

Update: Disregard that, I misunderstood how reflection works and missed registering type data.

[BenjaminBrienen]

I like this! I like that you updated examples, but can you also add some unit tests?

[eugineerd]

Added a basic test for no_auto_register, there is also a doctest that should cover most of auto register functionality.

but can you also add some unit tests?

What other tests do you have in mind? I'm not really sure what else should be tested here, so If you have any ideas I'd love to hear them.

[bushrat011899]

I'll do a more thorough review tonight, but at first glance I believe this is compatible with my no_std work for non-wasm platforms. On wasm, I will need to replace that RwLock with something else (probably spin::RwLock). However, no action needs to be taken here from a no_std perspective, I'll update my PR if this gets merged first, or provide a change-request in the reverse.

[MrGVSV]

Just a few comments. Overall looks really clean!

[MrGVSV]

Looks great! I think this is a good compromise between fully automatic registration and fully manual registration. It's completely opt-in via a feature flag and even opt-in on a per-registry basis.

I do think we should recommend libraries—including Bevy—manually register their types whenever possible to make it easier for downstream users to opt-out of this behavior.

But overall, this is going to make things a lot cleaner and easier for our users!

[github-actions]

You added a new example but didn't add metadata for it. Please update the root Cargo.toml file.