|
|
|
|
// Copyright 2014 The go-ethereum Authors
|
|
|
|
|
// This file is part of the go-ethereum library.
|
|
|
|
|
//
|
|
|
|
|
// The go-ethereum library is free software: you can redistribute it and/or modify
|
|
|
|
|
// it under the terms of the GNU Lesser General Public License as published by
|
|
|
|
|
// the Free Software Foundation, either version 3 of the License, or
|
|
|
|
|
// (at your option) any later version.
|
|
|
|
|
//
|
|
|
|
|
// The go-ethereum library is distributed in the hope that it will be useful,
|
|
|
|
|
// but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
|
// GNU Lesser General Public License for more details.
|
|
|
|
|
//
|
|
|
|
|
// You should have received a copy of the GNU Lesser General Public License
|
|
|
|
|
// along with the go-ethereum library. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
|
|
|
|
|
|
package rlp
|
|
|
|
|
|
|
|
|
|
import (
|
|
|
|
|
"fmt"
|
|
|
|
|
"reflect"
|
|
|
|
|
"strings"
|
|
|
|
|
"sync"
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
var (
|
|
|
|
|
typeCacheMutex sync.RWMutex
|
|
|
|
|
typeCache = make(map[typekey]*typeinfo)
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
type typeinfo struct {
|
|
|
|
|
decoder decoder
|
|
|
|
|
decoderErr error // error from makeDecoder
|
|
|
|
|
writer writer
|
|
|
|
|
writerErr error // error from makeWriter
|
|
|
|
|
}
|
|
|
|
|
|
rlp: improve nil pointer handling (#20064)
* rlp: improve nil pointer handling
In both encoder and decoder, the rules for encoding nil pointers were a
bit hard to understand, and didn't leave much choice. Since RLP allows
two empty values (empty list, empty string), any protocol built on RLP
must choose either of these values to represent the null value in a
certain context.
This change adds choice in the form of two new struct tags, "nilString"
and "nilList". These can be used to specify how a nil pointer value is
encoded. The "nil" tag still exists, but its implementation is now
explicit and defines exactly how nil pointers are handled in a single
place.
Another important change in this commit is how nil pointers and the
Encoder interface interact. The EncodeRLP method was previously called
even on nil values, which was supposed to give users a choice of how
their value would be handled when nil. It turns out this is a stupid
idea. If you create a network protocol containing an object defined in
another package, it's better to be able to say that the object should be
a list or string when nil in the definition of the protocol message
rather than defining the encoding of nil on the object itself.
As of this commit, the encoding rules for pointers now take precedence
over the Encoder interface rule. I think the "nil" tag will work fine
for most cases. For special kinds of objects which are a struct in Go
but strings in RLP, code using the object can specify the desired
encoding of nil using the "nilString" and "nilList" tags.
* rlp: propagate struct field type errors
If a struct contained fields of undecodable type, the encoder and
decoder would panic instead of returning an error. Fix this by
propagating type errors in makeStruct{Writer,Decoder} and add a test.
5 years ago
|
|
|
// tags represents struct tags.
|
|
|
|
|
type tags struct {
|
|
|
|
|
// rlp:"nil" controls whether empty input results in a nil pointer.
|
|
|
|
|
// nilKind is the kind of empty value allowed for the field.
|
rlp: improve nil pointer handling (#20064)
* rlp: improve nil pointer handling
In both encoder and decoder, the rules for encoding nil pointers were a
bit hard to understand, and didn't leave much choice. Since RLP allows
two empty values (empty list, empty string), any protocol built on RLP
must choose either of these values to represent the null value in a
certain context.
This change adds choice in the form of two new struct tags, "nilString"
and "nilList". These can be used to specify how a nil pointer value is
encoded. The "nil" tag still exists, but its implementation is now
explicit and defines exactly how nil pointers are handled in a single
place.
Another important change in this commit is how nil pointers and the
Encoder interface interact. The EncodeRLP method was previously called
even on nil values, which was supposed to give users a choice of how
their value would be handled when nil. It turns out this is a stupid
idea. If you create a network protocol containing an object defined in
another package, it's better to be able to say that the object should be
a list or string when nil in the definition of the protocol message
rather than defining the encoding of nil on the object itself.
As of this commit, the encoding rules for pointers now take precedence
over the Encoder interface rule. I think the "nil" tag will work fine
for most cases. For special kinds of objects which are a struct in Go
but strings in RLP, code using the object can specify the desired
encoding of nil using the "nilString" and "nilList" tags.
* rlp: propagate struct field type errors
If a struct contained fields of undecodable type, the encoder and
decoder would panic instead of returning an error. Fix this by
propagating type errors in makeStruct{Writer,Decoder} and add a test.
5 years ago
|
|
|
nilKind Kind
|
|
|
|
|
nilOK bool
|
|
|
|
|
|
|
|
|
|
// rlp:"optional" allows for a field to be missing in the input list.
|
|
|
|
|
// If this is set, all subsequent fields must also be optional.
|
|
|
|
|
optional bool
|
rlp: improve nil pointer handling (#20064)
* rlp: improve nil pointer handling
In both encoder and decoder, the rules for encoding nil pointers were a
bit hard to understand, and didn't leave much choice. Since RLP allows
two empty values (empty list, empty string), any protocol built on RLP
must choose either of these values to represent the null value in a
certain context.
This change adds choice in the form of two new struct tags, "nilString"
and "nilList". These can be used to specify how a nil pointer value is
encoded. The "nil" tag still exists, but its implementation is now
explicit and defines exactly how nil pointers are handled in a single
place.
Another important change in this commit is how nil pointers and the
Encoder interface interact. The EncodeRLP method was previously called
even on nil values, which was supposed to give users a choice of how
their value would be handled when nil. It turns out this is a stupid
idea. If you create a network protocol containing an object defined in
another package, it's better to be able to say that the object should be
a list or string when nil in the definition of the protocol message
rather than defining the encoding of nil on the object itself.
As of this commit, the encoding rules for pointers now take precedence
over the Encoder interface rule. I think the "nil" tag will work fine
for most cases. For special kinds of objects which are a struct in Go
but strings in RLP, code using the object can specify the desired
encoding of nil using the "nilString" and "nilList" tags.
* rlp: propagate struct field type errors
If a struct contained fields of undecodable type, the encoder and
decoder would panic instead of returning an error. Fix this by
propagating type errors in makeStruct{Writer,Decoder} and add a test.
5 years ago
|
|
|
|
|
|
|
|
// rlp:"tail" controls whether this field swallows additional list elements. It can
|
|
|
|
|
// only be set for the last field, which must be of slice type.
|
|
|
|
|
tail bool
|
rlp: improve nil pointer handling (#20064)
* rlp: improve nil pointer handling
In both encoder and decoder, the rules for encoding nil pointers were a
bit hard to understand, and didn't leave much choice. Since RLP allows
two empty values (empty list, empty string), any protocol built on RLP
must choose either of these values to represent the null value in a
certain context.
This change adds choice in the form of two new struct tags, "nilString"
and "nilList". These can be used to specify how a nil pointer value is
encoded. The "nil" tag still exists, but its implementation is now
explicit and defines exactly how nil pointers are handled in a single
place.
Another important change in this commit is how nil pointers and the
Encoder interface interact. The EncodeRLP method was previously called
even on nil values, which was supposed to give users a choice of how
their value would be handled when nil. It turns out this is a stupid
idea. If you create a network protocol containing an object defined in
another package, it's better to be able to say that the object should be
a list or string when nil in the definition of the protocol message
rather than defining the encoding of nil on the object itself.
As of this commit, the encoding rules for pointers now take precedence
over the Encoder interface rule. I think the "nil" tag will work fine
for most cases. For special kinds of objects which are a struct in Go
but strings in RLP, code using the object can specify the desired
encoding of nil using the "nilString" and "nilList" tags.
* rlp: propagate struct field type errors
If a struct contained fields of undecodable type, the encoder and
decoder would panic instead of returning an error. Fix this by
propagating type errors in makeStruct{Writer,Decoder} and add a test.
5 years ago
|
|
|
|
|
|
|
|
// rlp:"-" ignores fields.
|
|
|
|
|
ignored bool
|
|
|
|
|
}
|
|
|
|
|
|
rlp: improve nil pointer handling (#20064)
* rlp: improve nil pointer handling
In both encoder and decoder, the rules for encoding nil pointers were a
bit hard to understand, and didn't leave much choice. Since RLP allows
two empty values (empty list, empty string), any protocol built on RLP
must choose either of these values to represent the null value in a
certain context.
This change adds choice in the form of two new struct tags, "nilString"
and "nilList". These can be used to specify how a nil pointer value is
encoded. The "nil" tag still exists, but its implementation is now
explicit and defines exactly how nil pointers are handled in a single
place.
Another important change in this commit is how nil pointers and the
Encoder interface interact. The EncodeRLP method was previously called
even on nil values, which was supposed to give users a choice of how
their value would be handled when nil. It turns out this is a stupid
idea. If you create a network protocol containing an object defined in
another package, it's better to be able to say that the object should be
a list or string when nil in the definition of the protocol message
rather than defining the encoding of nil on the object itself.
As of this commit, the encoding rules for pointers now take precedence
over the Encoder interface rule. I think the "nil" tag will work fine
for most cases. For special kinds of objects which are a struct in Go
but strings in RLP, code using the object can specify the desired
encoding of nil using the "nilString" and "nilList" tags.
* rlp: propagate struct field type errors
If a struct contained fields of undecodable type, the encoder and
decoder would panic instead of returning an error. Fix this by
propagating type errors in makeStruct{Writer,Decoder} and add a test.
5 years ago
|
|
|
// typekey is the key of a type in typeCache. It includes the struct tags because
|
|
|
|
|
// they might generate a different decoder.
|
|
|
|
|
type typekey struct {
|
|
|
|
|
reflect.Type
|
|
|
|
|
tags
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
type decoder func(*Stream, reflect.Value) error
|
|
|
|
|
|
|
|
|
|
type writer func(reflect.Value, *encbuf) error
|
|
|
|
|
|
|
|
|
|
func cachedDecoder(typ reflect.Type) (decoder, error) {
|
|
|
|
|
info := cachedTypeInfo(typ, tags{})
|
|
|
|
|
return info.decoder, info.decoderErr
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func cachedWriter(typ reflect.Type) (writer, error) {
|
|
|
|
|
info := cachedTypeInfo(typ, tags{})
|
|
|
|
|
return info.writer, info.writerErr
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func cachedTypeInfo(typ reflect.Type, tags tags) *typeinfo {
|
|
|
|
|
typeCacheMutex.RLock()
|
|
|
|
|
info := typeCache[typekey{typ, tags}]
|
|
|
|
|
typeCacheMutex.RUnlock()
|
|
|
|
|
if info != nil {
|
|
|
|
|
return info
|
|
|
|
|
}
|
|
|
|
|
// not in the cache, need to generate info for this type.
|
|
|
|
|
typeCacheMutex.Lock()
|
|
|
|
|
defer typeCacheMutex.Unlock()
|
|
|
|
|
return cachedTypeInfo1(typ, tags)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func cachedTypeInfo1(typ reflect.Type, tags tags) *typeinfo {
|
|
|
|
|
key := typekey{typ, tags}
|
|
|
|
|
info := typeCache[key]
|
|
|
|
|
if info != nil {
|
|
|
|
|
// another goroutine got the write lock first
|
|
|
|
|
return info
|
|
|
|
|
}
|
|
|
|
|
// put a dummy value into the cache before generating.
|
|
|
|
|
// if the generator tries to lookup itself, it will get
|
|
|
|
|
// the dummy value and won't call itself recursively.
|
|
|
|
|
info = new(typeinfo)
|
|
|
|
|
typeCache[key] = info
|
|
|
|
|
info.generate(typ, tags)
|
|
|
|
|
return info
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
type field struct {
|
|
|
|
|
index int
|
|
|
|
|
info *typeinfo
|
|
|
|
|
optional bool
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// structFields resolves the typeinfo of all public fields in a struct type.
|
|
|
|
|
func structFields(typ reflect.Type) (fields []field, err error) {
|
|
|
|
|
var (
|
|
|
|
|
lastPublic = lastPublicField(typ)
|
|
|
|
|
anyOptional = false
|
|
|
|
|
)
|
|
|
|
|
for i := 0; i < typ.NumField(); i++ {
|
|
|
|
|
if f := typ.Field(i); f.PkgPath == "" { // exported
|
|
|
|
|
tags, err := parseStructTag(typ, i, lastPublic)
|
|
|
|
|
if err != nil {
|
|
|
|
|
return nil, err
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Skip rlp:"-" fields.
|
|
|
|
|
if tags.ignored {
|
|
|
|
|
continue
|
|
|
|
|
}
|
|
|
|
|
// If any field has the "optional" tag, subsequent fields must also have it.
|
|
|
|
|
if tags.optional || tags.tail {
|
|
|
|
|
anyOptional = true
|
|
|
|
|
} else if anyOptional {
|
|
|
|
|
return nil, fmt.Errorf(`rlp: struct field %v.%s needs "optional" tag`, typ, f.Name)
|
|
|
|
|
}
|
|
|
|
|
info := cachedTypeInfo1(f.Type, tags)
|
|
|
|
|
fields = append(fields, field{i, info, tags.optional})
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return fields, nil
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// anyOptionalFields returns the index of the first field with "optional" tag.
|
|
|
|
|
func firstOptionalField(fields []field) int {
|
|
|
|
|
for i, f := range fields {
|
|
|
|
|
if f.optional {
|
|
|
|
|
return i
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return len(fields)
|
|
|
|
|
}
|
|
|
|
|
|
rlp: improve nil pointer handling (#20064)
* rlp: improve nil pointer handling
In both encoder and decoder, the rules for encoding nil pointers were a
bit hard to understand, and didn't leave much choice. Since RLP allows
two empty values (empty list, empty string), any protocol built on RLP
must choose either of these values to represent the null value in a
certain context.
This change adds choice in the form of two new struct tags, "nilString"
and "nilList". These can be used to specify how a nil pointer value is
encoded. The "nil" tag still exists, but its implementation is now
explicit and defines exactly how nil pointers are handled in a single
place.
Another important change in this commit is how nil pointers and the
Encoder interface interact. The EncodeRLP method was previously called
even on nil values, which was supposed to give users a choice of how
their value would be handled when nil. It turns out this is a stupid
idea. If you create a network protocol containing an object defined in
another package, it's better to be able to say that the object should be
a list or string when nil in the definition of the protocol message
rather than defining the encoding of nil on the object itself.
As of this commit, the encoding rules for pointers now take precedence
over the Encoder interface rule. I think the "nil" tag will work fine
for most cases. For special kinds of objects which are a struct in Go
but strings in RLP, code using the object can specify the desired
encoding of nil using the "nilString" and "nilList" tags.
* rlp: propagate struct field type errors
If a struct contained fields of undecodable type, the encoder and
decoder would panic instead of returning an error. Fix this by
propagating type errors in makeStruct{Writer,Decoder} and add a test.
5 years ago
|
|
|
type structFieldError struct {
|
|
|
|
|
typ reflect.Type
|
|
|
|
|
field int
|
|
|
|
|
err error
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (e structFieldError) Error() string {
|
|
|
|
|
return fmt.Sprintf("%v (struct field %v.%s)", e.err, e.typ, e.typ.Field(e.field).Name)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
type structTagError struct {
|
|
|
|
|
typ reflect.Type
|
|
|
|
|
field, tag, err string
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (e structTagError) Error() string {
|
|
|
|
|
return fmt.Sprintf("rlp: invalid struct tag %q for %v.%s (%s)", e.tag, e.typ, e.field, e.err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func parseStructTag(typ reflect.Type, fi, lastPublic int) (tags, error) {
|
|
|
|
|
f := typ.Field(fi)
|
|
|
|
|
var ts tags
|
|
|
|
|
for _, t := range strings.Split(f.Tag.Get("rlp"), ",") {
|
|
|
|
|
switch t = strings.TrimSpace(t); t {
|
|
|
|
|
case "":
|
|
|
|
|
case "-":
|
|
|
|
|
ts.ignored = true
|
rlp: improve nil pointer handling (#20064)
* rlp: improve nil pointer handling
In both encoder and decoder, the rules for encoding nil pointers were a
bit hard to understand, and didn't leave much choice. Since RLP allows
two empty values (empty list, empty string), any protocol built on RLP
must choose either of these values to represent the null value in a
certain context.
This change adds choice in the form of two new struct tags, "nilString"
and "nilList". These can be used to specify how a nil pointer value is
encoded. The "nil" tag still exists, but its implementation is now
explicit and defines exactly how nil pointers are handled in a single
place.
Another important change in this commit is how nil pointers and the
Encoder interface interact. The EncodeRLP method was previously called
even on nil values, which was supposed to give users a choice of how
their value would be handled when nil. It turns out this is a stupid
idea. If you create a network protocol containing an object defined in
another package, it's better to be able to say that the object should be
a list or string when nil in the definition of the protocol message
rather than defining the encoding of nil on the object itself.
As of this commit, the encoding rules for pointers now take precedence
over the Encoder interface rule. I think the "nil" tag will work fine
for most cases. For special kinds of objects which are a struct in Go
but strings in RLP, code using the object can specify the desired
encoding of nil using the "nilString" and "nilList" tags.
* rlp: propagate struct field type errors
If a struct contained fields of undecodable type, the encoder and
decoder would panic instead of returning an error. Fix this by
propagating type errors in makeStruct{Writer,Decoder} and add a test.
5 years ago
|
|
|
case "nil", "nilString", "nilList":
|
|
|
|
|
ts.nilOK = true
|
rlp: improve nil pointer handling (#20064)
* rlp: improve nil pointer handling
In both encoder and decoder, the rules for encoding nil pointers were a
bit hard to understand, and didn't leave much choice. Since RLP allows
two empty values (empty list, empty string), any protocol built on RLP
must choose either of these values to represent the null value in a
certain context.
This change adds choice in the form of two new struct tags, "nilString"
and "nilList". These can be used to specify how a nil pointer value is
encoded. The "nil" tag still exists, but its implementation is now
explicit and defines exactly how nil pointers are handled in a single
place.
Another important change in this commit is how nil pointers and the
Encoder interface interact. The EncodeRLP method was previously called
even on nil values, which was supposed to give users a choice of how
their value would be handled when nil. It turns out this is a stupid
idea. If you create a network protocol containing an object defined in
another package, it's better to be able to say that the object should be
a list or string when nil in the definition of the protocol message
rather than defining the encoding of nil on the object itself.
As of this commit, the encoding rules for pointers now take precedence
over the Encoder interface rule. I think the "nil" tag will work fine
for most cases. For special kinds of objects which are a struct in Go
but strings in RLP, code using the object can specify the desired
encoding of nil using the "nilString" and "nilList" tags.
* rlp: propagate struct field type errors
If a struct contained fields of undecodable type, the encoder and
decoder would panic instead of returning an error. Fix this by
propagating type errors in makeStruct{Writer,Decoder} and add a test.
5 years ago
|
|
|
if f.Type.Kind() != reflect.Ptr {
|
|
|
|
|
return ts, structTagError{typ, f.Name, t, "field is not a pointer"}
|
|
|
|
|
}
|
|
|
|
|
switch t {
|
|
|
|
|
case "nil":
|
|
|
|
|
ts.nilKind = defaultNilKind(f.Type.Elem())
|
|
|
|
|
case "nilString":
|
|
|
|
|
ts.nilKind = String
|
|
|
|
|
case "nilList":
|
|
|
|
|
ts.nilKind = List
|
|
|
|
|
}
|
|
|
|
|
case "optional":
|
|
|
|
|
ts.optional = true
|
|
|
|
|
if ts.tail {
|
|
|
|
|
return ts, structTagError{typ, f.Name, t, `also has "tail" tag`}
|
|
|
|
|
}
|
|
|
|
|
case "tail":
|
|
|
|
|
ts.tail = true
|
|
|
|
|
if fi != lastPublic {
|
rlp: improve nil pointer handling (#20064)
* rlp: improve nil pointer handling
In both encoder and decoder, the rules for encoding nil pointers were a
bit hard to understand, and didn't leave much choice. Since RLP allows
two empty values (empty list, empty string), any protocol built on RLP
must choose either of these values to represent the null value in a
certain context.
This change adds choice in the form of two new struct tags, "nilString"
and "nilList". These can be used to specify how a nil pointer value is
encoded. The "nil" tag still exists, but its implementation is now
explicit and defines exactly how nil pointers are handled in a single
place.
Another important change in this commit is how nil pointers and the
Encoder interface interact. The EncodeRLP method was previously called
even on nil values, which was supposed to give users a choice of how
their value would be handled when nil. It turns out this is a stupid
idea. If you create a network protocol containing an object defined in
another package, it's better to be able to say that the object should be
a list or string when nil in the definition of the protocol message
rather than defining the encoding of nil on the object itself.
As of this commit, the encoding rules for pointers now take precedence
over the Encoder interface rule. I think the "nil" tag will work fine
for most cases. For special kinds of objects which are a struct in Go
but strings in RLP, code using the object can specify the desired
encoding of nil using the "nilString" and "nilList" tags.
* rlp: propagate struct field type errors
If a struct contained fields of undecodable type, the encoder and
decoder would panic instead of returning an error. Fix this by
propagating type errors in makeStruct{Writer,Decoder} and add a test.
5 years ago
|
|
|
return ts, structTagError{typ, f.Name, t, "must be on last field"}
|
|
|
|
|
}
|
|
|
|
|
if ts.optional {
|
|
|
|
|
return ts, structTagError{typ, f.Name, t, `also has "optional" tag`}
|
|
|
|
|
}
|
|
|
|
|
if f.Type.Kind() != reflect.Slice {
|
rlp: improve nil pointer handling (#20064)
* rlp: improve nil pointer handling
In both encoder and decoder, the rules for encoding nil pointers were a
bit hard to understand, and didn't leave much choice. Since RLP allows
two empty values (empty list, empty string), any protocol built on RLP
must choose either of these values to represent the null value in a
certain context.
This change adds choice in the form of two new struct tags, "nilString"
and "nilList". These can be used to specify how a nil pointer value is
encoded. The "nil" tag still exists, but its implementation is now
explicit and defines exactly how nil pointers are handled in a single
place.
Another important change in this commit is how nil pointers and the
Encoder interface interact. The EncodeRLP method was previously called
even on nil values, which was supposed to give users a choice of how
their value would be handled when nil. It turns out this is a stupid
idea. If you create a network protocol containing an object defined in
another package, it's better to be able to say that the object should be
a list or string when nil in the definition of the protocol message
rather than defining the encoding of nil on the object itself.
As of this commit, the encoding rules for pointers now take precedence
over the Encoder interface rule. I think the "nil" tag will work fine
for most cases. For special kinds of objects which are a struct in Go
but strings in RLP, code using the object can specify the desired
encoding of nil using the "nilString" and "nilList" tags.
* rlp: propagate struct field type errors
If a struct contained fields of undecodable type, the encoder and
decoder would panic instead of returning an error. Fix this by
propagating type errors in makeStruct{Writer,Decoder} and add a test.
5 years ago
|
|
|
return ts, structTagError{typ, f.Name, t, "field type is not slice"}
|
|
|
|
|
}
|
|
|
|
|
default:
|
|
|
|
|
return ts, fmt.Errorf("rlp: unknown struct tag %q on %v.%s", t, typ, f.Name)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return ts, nil
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func lastPublicField(typ reflect.Type) int {
|
|
|
|
|
last := 0
|
|
|
|
|
for i := 0; i < typ.NumField(); i++ {
|
|
|
|
|
if typ.Field(i).PkgPath == "" {
|
|
|
|
|
last = i
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return last
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (i *typeinfo) generate(typ reflect.Type, tags tags) {
|
|
|
|
|
i.decoder, i.decoderErr = makeDecoder(typ, tags)
|
|
|
|
|
i.writer, i.writerErr = makeWriter(typ, tags)
|
|
|
|
|
}
|
|
|
|
|
|
rlp: improve nil pointer handling (#20064)
* rlp: improve nil pointer handling
In both encoder and decoder, the rules for encoding nil pointers were a
bit hard to understand, and didn't leave much choice. Since RLP allows
two empty values (empty list, empty string), any protocol built on RLP
must choose either of these values to represent the null value in a
certain context.
This change adds choice in the form of two new struct tags, "nilString"
and "nilList". These can be used to specify how a nil pointer value is
encoded. The "nil" tag still exists, but its implementation is now
explicit and defines exactly how nil pointers are handled in a single
place.
Another important change in this commit is how nil pointers and the
Encoder interface interact. The EncodeRLP method was previously called
even on nil values, which was supposed to give users a choice of how
their value would be handled when nil. It turns out this is a stupid
idea. If you create a network protocol containing an object defined in
another package, it's better to be able to say that the object should be
a list or string when nil in the definition of the protocol message
rather than defining the encoding of nil on the object itself.
As of this commit, the encoding rules for pointers now take precedence
over the Encoder interface rule. I think the "nil" tag will work fine
for most cases. For special kinds of objects which are a struct in Go
but strings in RLP, code using the object can specify the desired
encoding of nil using the "nilString" and "nilList" tags.
* rlp: propagate struct field type errors
If a struct contained fields of undecodable type, the encoder and
decoder would panic instead of returning an error. Fix this by
propagating type errors in makeStruct{Writer,Decoder} and add a test.
5 years ago
|
|
|
// defaultNilKind determines whether a nil pointer to typ encodes/decodes
|
|
|
|
|
// as an empty string or empty list.
|
|
|
|
|
func defaultNilKind(typ reflect.Type) Kind {
|
|
|
|
|
k := typ.Kind()
|
|
|
|
|
if isUint(k) || k == reflect.String || k == reflect.Bool || isByteArray(typ) {
|
|
|
|
|
return String
|
|
|
|
|
}
|
|
|
|
|
return List
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func isUint(k reflect.Kind) bool {
|
|
|
|
|
return k >= reflect.Uint && k <= reflect.Uintptr
|
|
|
|
|
}
|
rlp: improve nil pointer handling (#20064)
* rlp: improve nil pointer handling
In both encoder and decoder, the rules for encoding nil pointers were a
bit hard to understand, and didn't leave much choice. Since RLP allows
two empty values (empty list, empty string), any protocol built on RLP
must choose either of these values to represent the null value in a
certain context.
This change adds choice in the form of two new struct tags, "nilString"
and "nilList". These can be used to specify how a nil pointer value is
encoded. The "nil" tag still exists, but its implementation is now
explicit and defines exactly how nil pointers are handled in a single
place.
Another important change in this commit is how nil pointers and the
Encoder interface interact. The EncodeRLP method was previously called
even on nil values, which was supposed to give users a choice of how
their value would be handled when nil. It turns out this is a stupid
idea. If you create a network protocol containing an object defined in
another package, it's better to be able to say that the object should be
a list or string when nil in the definition of the protocol message
rather than defining the encoding of nil on the object itself.
As of this commit, the encoding rules for pointers now take precedence
over the Encoder interface rule. I think the "nil" tag will work fine
for most cases. For special kinds of objects which are a struct in Go
but strings in RLP, code using the object can specify the desired
encoding of nil using the "nilString" and "nilList" tags.
* rlp: propagate struct field type errors
If a struct contained fields of undecodable type, the encoder and
decoder would panic instead of returning an error. Fix this by
propagating type errors in makeStruct{Writer,Decoder} and add a test.
5 years ago
|
|
|
|
|
|
|
|
func isByte(typ reflect.Type) bool {
|
|
|
|
|
return typ.Kind() == reflect.Uint8 && !typ.Implements(encoderInterface)
|
|
|
|
|
}
|
|
|
|
|
|
rlp: improve nil pointer handling (#20064)
* rlp: improve nil pointer handling
In both encoder and decoder, the rules for encoding nil pointers were a
bit hard to understand, and didn't leave much choice. Since RLP allows
two empty values (empty list, empty string), any protocol built on RLP
must choose either of these values to represent the null value in a
certain context.
This change adds choice in the form of two new struct tags, "nilString"
and "nilList". These can be used to specify how a nil pointer value is
encoded. The "nil" tag still exists, but its implementation is now
explicit and defines exactly how nil pointers are handled in a single
place.
Another important change in this commit is how nil pointers and the
Encoder interface interact. The EncodeRLP method was previously called
even on nil values, which was supposed to give users a choice of how
their value would be handled when nil. It turns out this is a stupid
idea. If you create a network protocol containing an object defined in
another package, it's better to be able to say that the object should be
a list or string when nil in the definition of the protocol message
rather than defining the encoding of nil on the object itself.
As of this commit, the encoding rules for pointers now take precedence
over the Encoder interface rule. I think the "nil" tag will work fine
for most cases. For special kinds of objects which are a struct in Go
but strings in RLP, code using the object can specify the desired
encoding of nil using the "nilString" and "nilList" tags.
* rlp: propagate struct field type errors
If a struct contained fields of undecodable type, the encoder and
decoder would panic instead of returning an error. Fix this by
propagating type errors in makeStruct{Writer,Decoder} and add a test.
5 years ago
|
|
|
func isByteArray(typ reflect.Type) bool {
|
|
|
|
|
return (typ.Kind() == reflect.Slice || typ.Kind() == reflect.Array) && isByte(typ.Elem())
|
|
|
|
|
}
|
