-
Notifications
You must be signed in to change notification settings - Fork 624
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
cbor: check inline value classes if marked as @ByteString (fixes #2187) #2466
Conversation
6838fd8
to
dfee01c
Compare
@@ -636,6 +639,11 @@ private fun SerialDescriptor.isByteString(index: Int): Boolean { | |||
return getElementAnnotations(index).find { it is ByteString } != null | |||
} | |||
|
|||
private fun SerialDescriptor.isInlineByteString(): Boolean { | |||
// inline item classes should only have 1 item | |||
return isInline && isByteString(0) |
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.
Yes, this is a correct way to do it
@@ -278,6 +280,7 @@ internal open class CborReader(private val cbor: Cbor, protected val decoder: Cb | |||
@Suppress("UNCHECKED_CAST") | |||
decoder.nextByteString() as T | |||
} else { | |||
decodeByteArrayAsByteString = decodeByteArrayAsByteString || deserializer.descriptor.isInlineByteString() |
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.
This looks a bit suspicious. If the current descriptor is not a ByteArraySerializer().descriptor and not a value class over @ByteString ByteArray
, why we should still try to decode it as ByteArray?
If this is to support cases when value class property is not annotated itself, like this:
@Serializable data class Outer(@ByteString val i: InnerValue)
@Serializable
@JvmInline value class InnerValue(val b: ByteArray)
Then I don't see tests for it.
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.
oh good point, yes that was the intended outcome! I'm not sure if that is wanted, but I can see how it might be unwanted? I guess I could probably expose it as an option in the serializer?
I will add the tests anyhow :)
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.
Tests added
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.
I'm not sure if that is wanted
I'm also unsure because I didn't see any requests for that. At the first look, it sounds reasonable, but I do not use byte strings that often
35e57ef
to
6292f2c
Compare
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.
Thank you!
This fixed inline value classes not being processed as a ByteString, by checking inside
encodeSerializableValue
anddecodeSerializableValue
to see if the current descriptor is marked as inline and with@ByteString
this is as far as I understand the most viable way to do it