Motivation:
When setting the default actor isolation to 'MainActor', generated
protobuf code will fail to compile.
Modifications:
- Add 'nonisolated' to generated declaration
- Add a compile test
Result:
- Resolves https://github.com/apple/swift-protobuf/issues/1797
Motivation:
The generated code has explicit returns for computed properties in a
number of places.
Modifications:
- Removed explicit 'return' where possible
Result:
Generated code is ever-so-slightly smaller
This has no impact on the optimized+stripped release builds I was
testing, but in a debug build of our internal huge-proto example, this
shaves an additional ~750KB off a 32MB binary (2.3%!). Presumably this
comes from debug info, accessors that are no longer being generated,
etc.
The problem with the `ExpressibleByDictionaryLiteral` approach we're
using today is that its codegen is unpredictable. For what is really
just static data, the Swift compiler always generates sequences of
instructions in debug mode, and in release mode it may or may not be
outlined into global data depending on various things outside of the
author's control.
`StaticString`s, on the other hand, are super predictable since they
always become static read-only data (ignoring the oddball edge case
involving a single code point). So, why not do what some other languages
do and create blobs of binary data that we can process at runtime
instead?
The catch is that since `StaticString`s must be valid UTF-8, we have to
invent our own little bytecode format a bit, to avoid encodings that
might be invalid. The format is a stream of bytes as follows:
* Integers are represented as varints with 6-bit shifts and an always
cleared MSB. This is similar to protobuf's own 7-bit varints except we
lose a bit to ensure that continuation bytes are in the range 0x40–0x7F
instead of 0x80–0xFF.
* Strings are represented as null-terminated UTF-8.
* String arrays are represented by a count integer followed by that many
null-terminated UTF-8 strings.
* The stream always starts with an integer "version" number, which
future-proofs us if we want to change the encoding. Right now, it's
always zero.
Layered on top of the bytecode stream is an interpreter, which abstracts
"instructions" that are `RawRepresentable` as `UInt64`, and the
interpreter loop just reads the next instruction and invokes a callback
that is supposed to read and process the operands.
The bytecode is an "ABI" that we can add to, but never remove from (for
a particular major version of the runtime). For example, we could add
new instructions in the future to represent things differently, as long
as the runtime can still correctly interpret the bytecode from older
generated code.
### Motivation:
Swift 5.9 is no longer supported, we should bump the tools version
### Modifications:
* Bump the Swift tools version to Swift 5.10
* Remove unsupported versions from CI in build.yml
### Result:
Code reflects the expected support window.
For closed enums there no special `UNRECOGNIZED` case, so a plain Swift
`Int` enum with explicit values can be used directly.
This results in the generated `init?(rawValue:)` and `var rawValue`
functions not being needed, since the compiler will create them
automatically.
Make the proto namespace used more consistent and ensure they are scoped to this
project more clearly.
Delete files that don't seem to be use/validating anything.
On macOS this requires using a swift.org toolchain since the swift support in
Xcode doesn't include fuzz support.
Add a second stage to the 'build' CI workflow to ensure these targets stay
building also.
George Barnett
Tony Allevato
Rick Newton-Rogers
Nick Randall
Tim Kientzle
Gus Cairo
Takumi Muraishi
Zachary Waldowski