ViewState::(enum) is an anonymous enum inside of a struct (ViewState). ViewState::Flags is a typedef for uint32_t, and the enum values are used to bitwise-construct and query a uint32_t containing several flags. For replay we still want to serialize ViewState with string names, since ViewState::Flags could change in the future and we don't want reordering the flags to break serialization. But, since the enum is un-named and ViewState::Flags is a uint32_t, the existing code will try to define new EncodingTraits specializations for uint32_t, which isn't allowed. To sidestep this, I'll generate a wrapper class for each framework, so multiple specializations can exist for the same underlying type. Cases like ViewState will use a new flag in the inputs file to opt-in to this code generation behavior. Sketch: enum class JSEnum { FooBar, BarBaz }; template <JSEnum EnumName, typename StorageType> class UncheckedJSEnum { public: UncheckedJSEnum(StorageType value) : m_value(value) { } StorageType m_value; }; template<> struct EncodingTraits<UncheckedJSEnum<JSEnum::FooBar,uint32_t>> { ... };
Even simpler: enum class WebEnums { FooBar, BarBaz }; struct ViewState { typedef uint32_t Flags; }; template <typename EnumType, EnumType tag> class Phantom { }; template<> struct EncodingTraits<Phantom<JSEnums,JSEnums::FooBar>> { typedef ViewState::Flags DecodedType; static EncodedValue encodeValue(const DecodedType&); static bool decodeValue(EncodedValue&, const DecodedType&); };
Created attachment 238625 [details] WIP
Closing web replay-related bugs until we resume working on the feature again.