implement `TypeUuid` for primitives

[dis-da-mor]

Objective

• Fixes #5432

Solution

• move code responsible for generating the impl TypeUuid from type_uuid_derive into a new function, gen_impl_type_uuid.
• this allows the new proc macro, impl_type_uuid, to call the code for generation.
• added struct TypeUuidDef and implemented syn::Parse to allow parsing of the input for the new macro.
• finally, used the new macro impl_type_uuid to implement TypeUuid for the standard library (in crates/bevy_reflect/src/type_uuid_impl.rs).

[jakobhellermann]

Generic types should not have a single static UUID.

[dis-da-mor]

Generic types should not have a single static UUID.

I'm pretty sure they don't, this macro generates the same code as the derive, where a generic type's UUID will be a composite of their own uuid and their parameter's uuid.

[dis-da-mor]

does anyone know why compilation sometimes fails due to the smallvec import?

[MrGVSV]

does anyone know why compilation sometimes fails due to the smallvec import?

It's because smallvec is gated behind a feature.

[harudagondi]

Can you implement TypeUuid for arrays? Ideally [T; 1] and [T; 2] should have different TYPE_UUID.

[dis-da-mor]

Can you implement TypeUuid for arrays? Ideally [T; 1] and [T; 2] should have different TYPE_UUID.

I think it can be implemented for [T; N], by converting N to a u128 and then to a Uuid from that, and then compositing T::TYPE_UUID, a static uuid for all arrays, and N::TYPE_UUID. Does that make sense?

[MrGVSV]

On the topic of handling arrays, do we handle tuples as well? If not, that might need to be added for completeness (up to twelve fields to match Reflect and other std impls).

[dis-da-mor]

I've had to move the all_tuples macro outside of bevy_ecs in order to avoid a circular dependency. I've moved it into a new proc macro crate in bevy_utils called bevy_utils_macros. This seemed the most suitable place to me but lmk if there is a better place.

[soqb]

the name bevy_utils_macros is very confusing when we already have a crate named bevy_macro_utils. i agree that bevy_ecs is not the best place for the macro but i'm not settled on the name and perhaps this should be part of a separate pr.

[soqb]

i'm happy for you to revert the change to using all_tuples! for the tuple implementation. i had originally thought we already had access to it (in bevy_reflect) for implementing Reflect, but that uses a custom macro - my mistake.

[dis-da-mor]

well the only reason it needs to be in a separate crate is that it's a proc macro. I could move it as a sub-crate of bevy_macro_utils called bevy_macro_utils_proc. I've already done all the refactoring work and if it's just the name that's the issue that could change.

[soqb]

bevy_macro_utils is not the correct place for the macro imo. the macro utils crate is for crates like bevy_reflect_derive to use, not for a crate like bevy_reflect. i'm not really sure where the correct place for the macro is. bevy_utils seems like a sound fit but our current naming scheme of bevy_xxx_{macros, derive} doesn't fit very well here.

@alice-i-cecile - can you provide some guidance here?

[alice-i-cecile]

Hmm, I agree with your analysis @soqb.

bevy_macro_utils_proc

This seems fine for now. @mockersf may have better ideas: he's very good at this sort of organizational thinking.

[soqb]

i don't think it's correct to put all_tuples in bevy_macro_utils so perhaps bevy_utils_proc_macros?

[harudagondi]

LGTM!

considering the all_tuples! move this should have C-Breaking-Change.

Is all_tuples! public API?

[alice-i-cecile]

https://docs.rs/bevy/latest/bevy/ecs/macro.all_tuples.html

Apparently yes, although it has no docs.

[alice-i-cecile]

@dis-da-moe can you please rebase? This is worth including in the release.

[alice-i-cecile]

bors r+

[bors[bot]]

Pull request successfully merged into main.

Build succeeded:

• build-and-install-on-iOS
• build-android
• build (macos-latest)
• build (ubuntu-latest)
• build-wasm
• build (windows-latest)
• build-without-default-features (bevy)
• build-without-default-features (bevy_ecs)
• build-without-default-features (bevy_reflect)
• check-compiles
• check-doc
• check-missing-examples-in-docs
• ci
• markdownlint
• msrv
• run-examples
• run-examples-on-wasm
• run-examples-on-windows-dx12