bebop v0.2.3

Adjust struct tags comments to use colons over equals as separators: #14

bebop v0.2.2

Changelog:

• Support defining struct tags in comments preceding fields: #14

bebop v0.2.1

Changelog:

Several changes for compatibility with upstream, specifically comparing against TypeScript generated code:

• Deprecated message fields are no longer written. They can still be parsed. (https://github.com/RainwayApp/bebop/wiki/Writing-Bops:-The-Bebop-Schema-Language#the-deprecated-attribute)
• Union sizes previously included the discriminator byte. They no longer do. (https://github.com/RainwayApp/bebop/wiki/Wire-format#unions)
• Generated code no longer writes opcodes, they only offer them as values for users to write if they would like to write them. (from misleading graphic: https://github.com/RainwayApp/bebop/wiki/Writing-Bops:-The-Bebop-Schema-Language#opcodes)

There is a remaining failure in compatibility with typescript that is a known problem with the upstream: betwixt-labs/bebop#148

Other Changes:

• When a const exceeds the limits of what can be stored in a variable in Go, instead of erroring out we now offer a warning.

bebop v0.2.0

This adds import support in two operating modes-

1. By default, generate each .bop file to a single .go file, with a const go_package hint for where those files should be found
2. Optionally, instead generate a single file containing all definitions in the entire import tree. This is what https://github.com/RainwayApp/bebop does, and may be necessary if working with a file you can't change to add a package hint.

We offer (1) instead because (2) is infeasible for a complex system. If you had a large app built on bebop structures you would either need a single place that stored every definition used in the app, which would eventually fail as file sizes increased and would have a bad developer experience, or you'd need to have partial definitions throughout the codebase, which would get confusing and an additional import added somewhere could cause a cascading file size bloat.

In addition,

• This fixes a bug where unions could not be fields of Structs or Messages
• Duplicate const names will now cause an error in the compiler.
• iohelp.ErrTooShort has been superceded by io.ErrUnexpectedEOF
• Unions and Messages will no longer read their full bodies up front when reading from a io.Reader.
• iohelp.ErrorReader.Read will now wait until the complete payload it expects is available to read.
• Code and template duplication in generation has been significantly reduced, fixing some inconsistencies.

bebop v0.1.4

Changelog:

• Bumped library to Go 1.17
• Adds const declaration support
• Modifies test suites to document compatibility with https://github.com/RainwayApp/bebop
  -- These tests cover compilation compatibility, not wire format compatibility, yet.
• Empty enum definitions will no longer generate an empty const block.
• Negative field numbers for messages and unions will be caught at compile time as errors.
• Fixed a bug with line and column numbers output by the compiler in error strings.
• Enums can now use hex integers.

bebop v0.1.3

This release

• Drops nested union support (see betwixt-labs/bebop#137).
• Fixes some comment generation and formatting bugs for unions and messages.
• Ensures that union fields are generated in a consistent order.

bebop v0.1.2

This release

• Adds Size() int to bebop.Record
• Changes MarshalBebopTo([]byte) to return int of bytes written
• Adds SharedMemoryStrings generation option to unmarshal functions, removing string allocations but sharing memory with the unmarshalling byte slice.

bebop v0.1.1

This release

• Fixes the generated size of unions
• Fixes UnmarshalBebop functions on messages and unions
• Enforces in some places that unions have one single populated field
• Adds additional test cases for the above

bebop v0.1.0

This release fixes code generation for messages containing dates.

bebop v0.0.9

This release

• Adds parsing and generation support for union types.
• Does not add validation support for union types, yet.