Serializing enums explicitly references types unless nullable (issue … #1146
Conversation
|
@ssabdb – can you look at the failures? |
|
Looks like the test builds some example files which are diff'd and have changed to include the null assertion “bang” operator as an intended result of this PR. They will need to be regenerated so the test passes - I'll figure it out today or tomorrow. |
|
@kevmoo Done, I think. Pending maintainer approval to run the workflow. Apologies I missed the notification this had happened a few weeks ago. |
|
@ssabdb – the markdown failure is unrelated – I should likely get rid of that. |
ssabdb
force-pushed
the
master
branch
2 times, most recently
from
81a125f
to
ff128db
Compare
|
@kevmoo. Done. I also added a second unit test to test the branching logic was working properly for nullable enums, eg. in a List type. |
Before this change, serializing non-nullable enums in a subtype was incorrectly producing nullable string types. For example, serializing a class member of type Map<enum, String> produced a type Map<String?, dynamic> where Map<String, dynamic> should have been produced. Nullable enums should still produce nullable types, eg. serializing List<enum?> should produce List<String?> fixes 1145
|
Still need a changelog entry then I'll run CI and land! Thanks so much! |
|
No worries, I'd misunderstood changelog (I thought you were talking about the gitlog!) I'm on the road at the moment until late next week but will have a shot at getting round to it. |
Before this change, serializing non-nullable enums in a subtype was incorrectly producing nullable string types. For example, serializing a class member of type Map<enum, String> produced a type Map<String?, dynamic> where Map<String, dynamic> should have been produced. Nullable enums should still produce nullable types, eg. serializing List<enum?> should produce List<String?> fixes 1145
#1145 I've fixed the issue for my own purposes by inspecting the
targetType- if not nullable, I use the!operator to remove the nullable type outputted by directly indexing_$EnumTypeEnumMap.This includes a unit test which fails prior to the fix.
I considered doing something similar to introducing a helper function used in the enum deserialization (
$enumDecode), but this just seemed simpler - since the map_$EnumTypeEnumMapis generated from the possible values of the enum, it should never result in a null, unless the variable storing the enum itself is nullable - and if that happens I don't emit an!operator.It does change a number of other generated files though, which might be a concern.
resolves #1145