feat(model)!: preserve unknown bitflag values #2089
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add static assertions for bitflag implementations and constant values, as well as tests for the serde implementations. The serde tests include a test for the (de)serialization of a variant and that unknown bits are truncated on deserialization.
Bitflags received from the Discord API are truncated when deserialized. However, we have recently taken a model of accepting "unknown information", with our recent reworks of enums the shining example. Instead of failing to deserialize / ignore "unknown variants" we have taken the step to treat unknown data as "first class", in that Twilight not necessarily registering known values is okay and users can manually handle variants as they need. We should apply the same logic to bitflags and not trim unknown data. This unfortunately makes use of unsafe code for constructing bitflags in tests, because `bitflags` has an unorthodox definition of what "unsafe" is for its `Bitflags::from_bits_unchecked` function. `bitflags` treats unknown bits as being "unsafe", and so the function to construct bitflags with possibly unknown variants is unsafe. I have added notes detailing this. This is a breaking change because unknown bits are no longer truncated. Blocks on PR #2088.
github-actions
bot
added
c-model
zeylahellyer
changed the title
Erk-
approved these changes
Jan 28, 2023
Co-authored-by: Erk <[email protected]>
vilgotf
approved these changes
Feb 5, 2023
| // <https://github.com/bitflags/bitflags/issues/262> | ||
| #[allow(unsafe_code)] | ||
| let value = unsafe { ChannelFlags::from_bits_unchecked(1 << 63) }; | ||
| serde_test::assert_de_tokens(&value, &[Token::U64(1 << 63)]); |
There was a problem hiding this comment.
Suggested change
| serde_test::assert_de_tokens(&value, &[Token::U64(1 << 63)]); | |
| serde_test::assert_tokens(&value, &[Token::U64(1 << 63)]); |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Bitflags received from the Discord API are truncated when deserialized. However, we have recently taken a model of accepting "unknown information", with our recent reworks of enums the shining example. Instead of failing to deserialize / ignore "unknown variants" we have taken the step to treat unknown data as "first class", in that Twilight not necessarily registering known values is okay and users can manually handle variants as they need. We should apply the same logic to bitflags and not trim unknown data.
This unfortunately makes use of unsafe code for constructing bitflags in tests and the Deserializer implementation for
Permissions, becausebitflagshas an unorthodox definition of what "unsafe" is for itsBitflags::from_bits_uncheckedfunction.bitflagstreats unknown bits as being "unsafe", and so the function to construct bitflags with possibly unknown variants is unsafe. I have added notes detailing this. Funnily enough,bitflags'Deserializeimplementation itself actually just throws the raw integer into the bitflag, effectively doing whatBitflags::from_bits_uncheckeddoes. So this way of going about things is, unfortunately, expected.As a side-effect, this allows us to remove our custom Deserialize and Serialize and derive them for all model bitflags except
Permissions.This is a breaking change because unknown bits are no longer truncated. This blocks on PR #2088 because it changes tests introduced in it, but will actually target
nextonce #2088 is merged.