-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Merged by Bors] - bevy_reflect: Remove ReflectSerialize
and ReflectDeserialize
registrations from most glam types
#6580
Conversation
This only affects glam types that are treated as structs
This feels like it might break semver... Are we sure it's OK to do in a patch release? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we add more tests to catch this sort of issue better in the future?
Yes! I actually meant to create an issue for this but forgot lol. Basically we should probably have a more "real world" scene that contains usages of That should be its own PR, though. |
I’m not sure what does or doesn't break semver tbh. Why might this be problematic? Isn't fixing an unintended behavior okay for a patch release? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Edit: And this doesn't break semver since we're pre-1.0. I know cargo doesn't care, but imo that's cargo's problem, not ours. And even if we overlook that, this changes a broken feature into a working one, which imo is worth it.
bors r+ |
…strations from most glam types (#6580) # Objective > Part of #6573 When serializing a `DynamicScene` we end up treating almost all non-value types as though their type data doesn't exist. This is because when creating the `DynamicScene` we call `Reflect::clone_value` on the components, which generates a Dynamic type for all non-value types. What this means is that the `glam` types are treated as though their `ReflectSerialize` registrations don't exist. However, the deserializer _does_ pick up the registration and attempts to use that instead. This results in the deserializer trying to operate on "malformed" data, causing this error: ``` WARN bevy_asset::asset_server: encountered an error while loading an asset: Expected float ``` ## Solution Ideally, we should better handle the serialization of possibly-Dynamic types. However, this runs into issues where the `ReflectSerialize` expects the concrete type and not a Dynamic representation, resulting in a panic: https://github.com/bevyengine/bevy/blob/0aa4147af6d583c707863484d6a8ad50ed0ed984/crates/bevy_reflect/src/type_registry.rs#L402-L413 Since glam types are so heavily used in Bevy (specifically in `Transform` and `GlobalTransform`), it makes sense to just a quick fix in that enables them to be used properly in scenes while a proper solution is found. This PR simply removes all `ReflectSerialize` and `ReflectDeserialize` registrations from the glam types that are reflected as structs. --- ## Changelog - Remove `ReflectSerialize` and `ReflectDeserialize` registrations from most glam types ## Migration Guide This PR removes `ReflectSerialize` and `ReflectDeserialize` registrations from most glam types. This means any code relying on either of those type data existing for those glam types will need to not do that. This also means that some serialized glam types will need to be updated. For example, here is `Affine3A`: ```rust // BEFORE ( "glam::f32::affine3a::Affine3A": (1.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0), // AFTER "glam::f32::affine3a::Affine3A": ( matrix3: ( x_axis: ( x: 1.0, y: 0.0, z: 0.0, ), y_axis: ( x: 0.0, y: 1.0, z: 0.0, ), z_axis: ( x: 0.0, y: 0.0, z: 1.0, ), ), translation: ( x: 0.0, y: 0.0, z: 0.0, ), ) ) ```
Build failed: |
bors retry |
…strations from most glam types (#6580) # Objective > Part of #6573 When serializing a `DynamicScene` we end up treating almost all non-value types as though their type data doesn't exist. This is because when creating the `DynamicScene` we call `Reflect::clone_value` on the components, which generates a Dynamic type for all non-value types. What this means is that the `glam` types are treated as though their `ReflectSerialize` registrations don't exist. However, the deserializer _does_ pick up the registration and attempts to use that instead. This results in the deserializer trying to operate on "malformed" data, causing this error: ``` WARN bevy_asset::asset_server: encountered an error while loading an asset: Expected float ``` ## Solution Ideally, we should better handle the serialization of possibly-Dynamic types. However, this runs into issues where the `ReflectSerialize` expects the concrete type and not a Dynamic representation, resulting in a panic: https://github.com/bevyengine/bevy/blob/0aa4147af6d583c707863484d6a8ad50ed0ed984/crates/bevy_reflect/src/type_registry.rs#L402-L413 Since glam types are so heavily used in Bevy (specifically in `Transform` and `GlobalTransform`), it makes sense to just a quick fix in that enables them to be used properly in scenes while a proper solution is found. This PR simply removes all `ReflectSerialize` and `ReflectDeserialize` registrations from the glam types that are reflected as structs. --- ## Changelog - Remove `ReflectSerialize` and `ReflectDeserialize` registrations from most glam types ## Migration Guide This PR removes `ReflectSerialize` and `ReflectDeserialize` registrations from most glam types. This means any code relying on either of those type data existing for those glam types will need to not do that. This also means that some serialized glam types will need to be updated. For example, here is `Affine3A`: ```rust // BEFORE ( "glam::f32::affine3a::Affine3A": (1.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0), // AFTER "glam::f32::affine3a::Affine3A": ( matrix3: ( x_axis: ( x: 1.0, y: 0.0, z: 0.0, ), y_axis: ( x: 0.0, y: 1.0, z: 0.0, ), z_axis: ( x: 0.0, y: 0.0, z: 1.0, ), ), translation: ( x: 0.0, y: 0.0, z: 0.0, ), ) ) ```
ReflectSerialize
and ReflectDeserialize
registrations from most glam typesReflectSerialize
and ReflectDeserialize
registrations from most glam types
…strations from most glam types (bevyengine#6580) # Objective > Part of bevyengine#6573 When serializing a `DynamicScene` we end up treating almost all non-value types as though their type data doesn't exist. This is because when creating the `DynamicScene` we call `Reflect::clone_value` on the components, which generates a Dynamic type for all non-value types. What this means is that the `glam` types are treated as though their `ReflectSerialize` registrations don't exist. However, the deserializer _does_ pick up the registration and attempts to use that instead. This results in the deserializer trying to operate on "malformed" data, causing this error: ``` WARN bevy_asset::asset_server: encountered an error while loading an asset: Expected float ``` ## Solution Ideally, we should better handle the serialization of possibly-Dynamic types. However, this runs into issues where the `ReflectSerialize` expects the concrete type and not a Dynamic representation, resulting in a panic: https://github.com/bevyengine/bevy/blob/0aa4147af6d583c707863484d6a8ad50ed0ed984/crates/bevy_reflect/src/type_registry.rs#L402-L413 Since glam types are so heavily used in Bevy (specifically in `Transform` and `GlobalTransform`), it makes sense to just a quick fix in that enables them to be used properly in scenes while a proper solution is found. This PR simply removes all `ReflectSerialize` and `ReflectDeserialize` registrations from the glam types that are reflected as structs. --- ## Changelog - Remove `ReflectSerialize` and `ReflectDeserialize` registrations from most glam types ## Migration Guide This PR removes `ReflectSerialize` and `ReflectDeserialize` registrations from most glam types. This means any code relying on either of those type data existing for those glam types will need to not do that. This also means that some serialized glam types will need to be updated. For example, here is `Affine3A`: ```rust // BEFORE ( "glam::f32::affine3a::Affine3A": (1.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0), // AFTER "glam::f32::affine3a::Affine3A": ( matrix3: ( x_axis: ( x: 1.0, y: 0.0, z: 0.0, ), y_axis: ( x: 0.0, y: 1.0, z: 0.0, ), z_axis: ( x: 0.0, y: 0.0, z: 1.0, ), ), translation: ( x: 0.0, y: 0.0, z: 0.0, ), ) ) ```
…strations from most glam types (#6580) # Objective > Part of #6573 When serializing a `DynamicScene` we end up treating almost all non-value types as though their type data doesn't exist. This is because when creating the `DynamicScene` we call `Reflect::clone_value` on the components, which generates a Dynamic type for all non-value types. What this means is that the `glam` types are treated as though their `ReflectSerialize` registrations don't exist. However, the deserializer _does_ pick up the registration and attempts to use that instead. This results in the deserializer trying to operate on "malformed" data, causing this error: ``` WARN bevy_asset::asset_server: encountered an error while loading an asset: Expected float ``` ## Solution Ideally, we should better handle the serialization of possibly-Dynamic types. However, this runs into issues where the `ReflectSerialize` expects the concrete type and not a Dynamic representation, resulting in a panic: https://github.com/bevyengine/bevy/blob/0aa4147af6d583c707863484d6a8ad50ed0ed984/crates/bevy_reflect/src/type_registry.rs#L402-L413 Since glam types are so heavily used in Bevy (specifically in `Transform` and `GlobalTransform`), it makes sense to just a quick fix in that enables them to be used properly in scenes while a proper solution is found. This PR simply removes all `ReflectSerialize` and `ReflectDeserialize` registrations from the glam types that are reflected as structs. --- ## Changelog - Remove `ReflectSerialize` and `ReflectDeserialize` registrations from most glam types ## Migration Guide This PR removes `ReflectSerialize` and `ReflectDeserialize` registrations from most glam types. This means any code relying on either of those type data existing for those glam types will need to not do that. This also means that some serialized glam types will need to be updated. For example, here is `Affine3A`: ```rust // BEFORE ( "glam::f32::affine3a::Affine3A": (1.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0), // AFTER "glam::f32::affine3a::Affine3A": ( matrix3: ( x_axis: ( x: 1.0, y: 0.0, z: 0.0, ), y_axis: ( x: 0.0, y: 1.0, z: 0.0, ), z_axis: ( x: 0.0, y: 0.0, z: 1.0, ), ), translation: ( x: 0.0, y: 0.0, z: 0.0, ), ) ) ```
…strations from most glam types (bevyengine#6580) # Objective > Part of bevyengine#6573 When serializing a `DynamicScene` we end up treating almost all non-value types as though their type data doesn't exist. This is because when creating the `DynamicScene` we call `Reflect::clone_value` on the components, which generates a Dynamic type for all non-value types. What this means is that the `glam` types are treated as though their `ReflectSerialize` registrations don't exist. However, the deserializer _does_ pick up the registration and attempts to use that instead. This results in the deserializer trying to operate on "malformed" data, causing this error: ``` WARN bevy_asset::asset_server: encountered an error while loading an asset: Expected float ``` ## Solution Ideally, we should better handle the serialization of possibly-Dynamic types. However, this runs into issues where the `ReflectSerialize` expects the concrete type and not a Dynamic representation, resulting in a panic: https://github.com/bevyengine/bevy/blob/0aa4147af6d583c707863484d6a8ad50ed0ed984/crates/bevy_reflect/src/type_registry.rs#L402-L413 Since glam types are so heavily used in Bevy (specifically in `Transform` and `GlobalTransform`), it makes sense to just a quick fix in that enables them to be used properly in scenes while a proper solution is found. This PR simply removes all `ReflectSerialize` and `ReflectDeserialize` registrations from the glam types that are reflected as structs. --- ## Changelog - Remove `ReflectSerialize` and `ReflectDeserialize` registrations from most glam types ## Migration Guide This PR removes `ReflectSerialize` and `ReflectDeserialize` registrations from most glam types. This means any code relying on either of those type data existing for those glam types will need to not do that. This also means that some serialized glam types will need to be updated. For example, here is `Affine3A`: ```rust // BEFORE ( "glam::f32::affine3a::Affine3A": (1.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0), // AFTER "glam::f32::affine3a::Affine3A": ( matrix3: ( x_axis: ( x: 1.0, y: 0.0, z: 0.0, ), y_axis: ( x: 0.0, y: 1.0, z: 0.0, ), z_axis: ( x: 0.0, y: 0.0, z: 1.0, ), ), translation: ( x: 0.0, y: 0.0, z: 0.0, ), ) ) ```
Objective
When serializing a
DynamicScene
we end up treating almost all non-value types as though their type data doesn't exist. This is because when creating theDynamicScene
we callReflect::clone_value
on the components, which generates a Dynamic type for all non-value types.What this means is that the
glam
types are treated as though theirReflectSerialize
registrations don't exist. However, the deserializer does pick up the registration and attempts to use that instead. This results in the deserializer trying to operate on "malformed" data, causing this error:Solution
Ideally, we should better handle the serialization of possibly-Dynamic types. However, this runs into issues where the
ReflectSerialize
expects the concrete type and not a Dynamic representation, resulting in a panic:bevy/crates/bevy_reflect/src/type_registry.rs
Lines 402 to 413 in 0aa4147
Since glam types are so heavily used in Bevy (specifically in
Transform
andGlobalTransform
), it makes sense to just a quick fix in that enables them to be used properly in scenes while a proper solution is found.This PR simply removes all
ReflectSerialize
andReflectDeserialize
registrations from the glam types that are reflected as structs.Changelog
ReflectSerialize
andReflectDeserialize
registrations from most glam typesMigration Guide
This PR removes
ReflectSerialize
andReflectDeserialize
registrations from most glam types. This means any code relying on either of those type data existing for those glam types will need to not do that.This also means that some serialized glam types will need to be updated. For example, here is
Affine3A
: