6 Commits (9e3e46671e2c3b39208a536ceaab72f2e59f2def)

Author	SHA1	Message	Date
Felix Lange	909dd4a109	rlp/rlpgen: remove build tag (#28106) ... * rlp/rlpgen: remove build tag This tag was supposed to prevent unstable output when types reference each other. Imagine there are two struct types A and B, where a reference to type B is in A. If I run rlpgen on type B first, and then on type A, the generator will see the B.EncodeRLP method and call it. However, if I run rlpgen on type A first, it will inline the encoding of B. The solution I chose for the initial release of rlpgen was to just ignore methods generated by rlpgen using a build tag. But there is a problem with this: if any code in the package calls EncodeRLP explicitly, the package can't be loaded without errors anymore in rlpgen, because the loader ignores it. Would be nice if there was a way to just make it ignore invalid functions during type checking (they're not necessary for rlpgen), but golang.org/x/tools/go/packages does not provide a way of ignoring them. Luckily, the types we use rlpgen with do not reference each other right now, so we can just remove the build tags for now.	1 year ago
Justin Traglia	cce7f08438	rlp/rlpgen: fix error handling when target type not found (#25547) ... typ will be nil when lookupStructType returns an error. cfg.Type should be used instead.	2 years ago
Martin Holst Swende	a907d7e81a	all: more linters (#24783) ... This enables the following linters - typecheck - unused - staticcheck - bidichk - durationcheck - exportloopref - gosec WIth a few exceptions. - We use a deprecated protobuf in trezor. I didn't want to mess with that, since I cannot meaningfully test any changes there. - The deprecated TypeMux is used in a few places still, so the warning for it is silenced for now. - Using string type in context.WithValue is apparently wrong, one should use a custom type, to prevent collisions between different places in the hierarchy of callers. That should be fixed at some point, but may require some attention. - The warnings for using weak random generator are squashed, since we use a lot of random without need for cryptographic guarantees.	2 years ago
Felix Lange	9244d5cd61	all: update license headers and AUTHORS from git history (#24947)	3 years ago
Håvard Anda Estensen	07508ac0e9	all: replace uses of ioutil with io and os (#24869)	3 years ago
Felix Lange	9b93564e21	rlp/rlpgen: RLP encoder code generator (#24251) ... This change adds a code generator tool for creating EncodeRLP method implementations. The generated methods will behave identically to the reflect-based encoder, but run faster because there is no reflection overhead. Package rlp now provides the EncoderBuffer type for incremental encoding. This is used by generated code, but the new methods can also be useful for hand-written encoders. There is also experimental support for generating DecodeRLP, and some new methods have been added to the existing Stream type to support this. Creating decoders with rlpgen is not recommended at this time because the generated methods create very poor error reporting. More detail about package rlp changes: * rlp: externalize struct field processing / validation This adds a new package, rlp/internal/rlpstruct, in preparation for the RLP encoder generator. I think the struct field rules are subtle enough to warrant extracting this into their own package, even though it means that a bunch of adapter code is needed for converting to/from rlpstruct.Type. * rlp: add more decoder methods (for rlpgen) This adds new methods on rlp.Stream: - Uint64, Uint32, Uint16, Uint8, BigInt - ReadBytes for decoding into []byte - MoreDataInList - useful for optional list elements * rlp: expose encoder buffer (for rlpgen) This exposes the internal encoder buffer type for use in EncodeRLP implementations. The new EncoderBuffer type is a sort-of 'opaque handle' for a pointer to encBuffer. It is implemented this way to ensure the global encBuffer pool is handled correctly.	3 years ago