feat(dart): add struct serializer support for unsigned integer types #3155
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Why?
While unsigned integer types (UInt8, UInt16, UInt32) were added to Fory in PR #3144 with their primitive serializers and wrapper classes, they were not integrated into the framework's type system for struct serialization. This meant users could serialize individual UInt values but could not use them as fields in structs annotated with
@ForyClass.For example:
UInt16 portfield would fail during code generationWhat does this PR do?
1. Registers Unsigned Integer Types in DartTypeEnum
Added UInt8, UInt16, and UInt32 to the type enumeration in
dart_type.dart:This enables the code generator to recognize unsigned types during static analysis and generate proper serialization metadata.
2. Integrates Serializers into SerializerPool
Registered the serializers in the framework initialization:
This ensures serializers are available when the framework starts and can be used for struct field serialization.
3. Adds Comprehensive Test Suite for Struct Serialization
Created test entity and test cases:
Test coverage:
Run tests:
Related issues
Completes the unsigned integer types support initiated in PR #3144.
Does this PR introduce any user-facing change?
Does this PR introduce any public API change?
@ForyClassstructsDoes this PR introduce any binary protocol compatibility change?
Benchmark
N/A, The serializers themselves were already implemented in #3144. This PR only adds registration overhead during framework initialization, which is negligible..