PROST! a Protocol Buffers implementation for the Rust Language

Related tags

rust protobuf
Overview

continuous integration Documentation Crate Dependency Status

PROST!

prost is a Protocol Buffers implementation for the Rust Language. prost generates simple, idiomatic Rust code from proto2 and proto3 files.

Compared to other Protocol Buffers implementations, prost

  • Generates simple, idiomatic, and readable Rust types by taking advantage of Rust derive attributes.
  • Retains comments from .proto files in generated Rust code.
  • Allows existing Rust types (not generated from a .proto) to be serialized and deserialized by adding attributes.
  • Uses the bytes::{Buf, BufMut} abstractions for serialization instead of std::io::{Read, Write}.
  • Respects the Protobuf package specifier when organizing generated code into Rust modules.
  • Preserves unknown enum values during deserialization.
  • Does not include support for runtime reflection or message descriptors.

Using prost in a Cargo Project

First, add prost and its public dependencies to your Cargo.toml:

[dependencies]
prost = "0.7"
# Only necessary if using Protobuf well-known types:
prost-types = "0.7"

The recommended way to add .proto compilation to a Cargo project is to use the prost-build library. See the prost-build documentation for more details and examples.

Generated Code

prost generates Rust code from source .proto files using the proto2 or proto3 syntax. prost's goal is to make the generated code as simple as possible.

Packages

All .proto files used with prost must contain a package specifier. prost will translate the Protobuf package into a Rust module. For example, given the package specifier:

package foo.bar;

All Rust types generated from the file will be in the foo::bar module.

Messages

Given a simple message declaration:

// Sample message.
message Foo {
}

prost will generate the following Rust struct:

/// Sample message.
#[derive(Clone, Debug, PartialEq, Message)]
pub struct Foo {
}

Fields

Fields in Protobuf messages are translated into Rust as public struct fields of the corresponding type.

Scalar Values

Scalar value types are converted as follows:

Protobuf Type Rust Type
double f64
float f32
int32 i32
int64 i64
uint32 u32
uint64 u64
sint32 i32
sint64 i64
fixed32 u32
fixed64 u64
sfixed32 i32
sfixed64 i64
bool bool
string String
bytes Vec<u8>

Enumerations

All .proto enumeration types convert to the Rust i32 type. Additionally, each enumeration type gets a corresponding Rust enum type, with helper methods to convert i32 values to the enum type. The enum type isn't used directly as a field, because the Protobuf spec mandates that enumerations values are 'open', and decoding unrecognized enumeration values must be possible.

Field Modifiers

Protobuf scalar value and enumeration message fields can have a modifier depending on the Protobuf version. Modifiers change the corresponding type of the Rust field:

.proto Version Modifier Rust Type
proto2 optional Option<T>
proto2 required T
proto3 default T
proto2/proto3 repeated Vec<T>

Map Fields

Map fields are converted to a Rust HashMap with key and value type converted from the Protobuf key and value types.

Message Fields

Message fields are converted to the corresponding struct type. The table of field modifiers above applies to message fields, except that proto3 message fields without a modifier (the default) will be wrapped in an Option. Typically message fields are unboxed. prost will automatically box a message field if the field type and the parent type are recursively nested in order to avoid an infinite sized struct.

Oneof Fields

Oneof fields convert to a Rust enum. Protobuf oneofs types are not named, so prost uses the name of the oneof field for the resulting Rust enum, and defines the enum in a module under the struct. For example, a proto3 message such as:

message Foo {
  oneof widget {
    int32 quux = 1;
    string bar = 2;
  }
}

generates the following Rust[1]:

pub struct Foo {
    pub widget: Option<foo::Widget>,
}
pub mod foo {
    pub enum Widget {
        Quux(i32),
        Bar(String),
    }
}

oneof fields are always wrapped in an Option.

[1] Annotations have been elided for clarity. See below for a full example.

Services

prost-build allows a custom code-generator to be used for processing service definitions. This can be used to output Rust traits according to an application's specific needs.

Generated Code Example

Example .proto file:

syntax = "proto3";
package tutorial;

message Person {
  string name = 1;
  int32 id = 2;  // Unique ID number for this person.
  string email = 3;

  enum PhoneType {
    MOBILE = 0;
    HOME = 1;
    WORK = 2;
  }

  message PhoneNumber {
    string number = 1;
    PhoneType type = 2;
  }

  repeated PhoneNumber phones = 4;
}

// Our address book file is just one of these.
message AddressBook {
  repeated Person people = 1;
}

and the generated Rust code (tutorial.rs):

#[derive(Clone, Debug, PartialEq, Message)]
pub struct Person {
    #[prost(string, tag="1")]
    pub name: String,
    /// Unique ID number for this person.
    #[prost(int32, tag="2")]
    pub id: i32,
    #[prost(string, tag="3")]
    pub email: String,
    #[prost(message, repeated, tag="4")]
    pub phones: Vec<person::PhoneNumber>,
}
pub mod person {
    #[derive(Clone, Debug, PartialEq, Message)]
    pub struct PhoneNumber {
        #[prost(string, tag="1")]
        pub number: String,
        #[prost(enumeration="PhoneType", tag="2")]
        pub type_: i32,
    }
    #[derive(Clone, Copy, Debug, PartialEq, Eq, Enumeration)]
    pub enum PhoneType {
        Mobile = 0,
        Home = 1,
        Work = 2,
    }
}
/// Our address book file is just one of these.
#[derive(Clone, Debug, PartialEq, Message)]
pub struct AddressBook {
    #[prost(message, repeated, tag="1")]
    pub people: Vec<Person>,
}

Accessing the protoc FileDescriptorSet

The prost_build::Config::file_descriptor_set_path option can be used to emit a file descriptor set during the build & code generation step. When used in conjunction with the std::include_bytes macro and the prost_types::FileDescriptorSet type, applications and libraries using Prost can implement introspection capabilities requiring details from the original .proto files.

Using prost in a no_std Crate

prost is compatible with no_std crates. To enable no_std support, disable the std features in prost and prost-types:

[dependencies]
prost = { version = "0.6", default-features = false, features = ["prost-derive"] }
# Only necessary if using Protobuf well-known types:
prost-types = { version = "0.6", default-features = false }

Additionally, configure prost-buid to output BTreeMaps instead of HashMaps for all Protobuf map fields in your build.rs:

let mut config = prost_build::Config::new();
config.btree_map(&["."]);

When using edition 2015, it may be necessary to add an extern crate core; directive to the crate which includes prost-generated code.

Serializing Existing Types

prost uses a custom derive macro to handle encoding and decoding types, which means that if your existing Rust type is compatible with Protobuf types, you can serialize and deserialize it by adding the appropriate derive and field annotations.

Currently the best documentation on adding annotations is to look at the generated code examples above.

Tag Inference for Existing Types

Prost automatically infers tags for the struct.

Fields are tagged sequentially in the order they are specified, starting with 1.

You may skip tags which have been reserved, or where there are gaps between sequentially occurring tag values by specifying the tag number to skip to with the tag attribute on the first field after the gap. The following fields will be tagged sequentially starting from the next number.

use prost;
use prost::{Enumeration, Message};

#[derive(Clone, PartialEq, Message)]
struct Person {
    #[prost(string, tag = "1")]
    pub id: String, // tag=1
    // NOTE: Old "name" field has been removed
    // pub name: String, // tag=2 (Removed)
    #[prost(string, tag = "6")]
    pub given_name: String, // tag=6
    #[prost(string)]
    pub family_name: String, // tag=7
    #[prost(string)]
    pub formatted_name: String, // tag=8
    #[prost(uint32, tag = "3")]
    pub age: u32, // tag=3
    #[prost(uint32)]
    pub height: u32, // tag=4
    #[prost(enumeration = "Gender")]
    pub gender: i32, // tag=5
    // NOTE: Skip to less commonly occurring fields
    #[prost(string, tag = "16")]
    pub name_prefix: String, // tag=16  (eg. mr/mrs/ms)
    #[prost(string)]
    pub name_suffix: String, // tag=17  (eg. jr/esq)
    #[prost(string)]
    pub maiden_name: String, // tag=18
}

#[derive(Clone, Copy, Debug, PartialEq, Eq, Enumeration)]
pub enum Gender {
    Unknown = 0,
    Female = 1,
    Male = 2,
}

FAQ

  1. Could prost be implemented as a serializer for Serde?

Probably not, however I would like to hear from a Serde expert on the matter. There are two complications with trying to serialize Protobuf messages with Serde:

  • Protobuf fields require a numbered tag, and curently there appears to be no mechanism suitable for this in serde.
  • The mapping of Protobuf type to Rust type is not 1-to-1. As a result, trait-based approaches to dispatching don't work very well. Example: six different Protobuf field types correspond to a Rust Vec<i32>: repeated int32, repeated sint32, repeated sfixed32, and their packed counterparts.

But it is possible to place serde derive tags onto the generated types, so the same structure can support both prost and Serde.

  1. I get errors when trying to run cargo test on MacOS

If the errors are about missing autoreconf or similar, you can probably fix them by running

brew install automake
brew install libtool

License

prost is distributed under the terms of the Apache License (Version 2.0).

See LICENSE for details.

Copyright 2017 Dan Burkert

Issues
  • Make prost a `no_std` compatible library, and prost-build able to gen…

    Make prost a `no_std` compatible library, and prost-build able to gen…

    …erate no_std code

    The alternative is to get collections types from core and alloc. In the no_std mode in prost_build, we force it to always use BTreeMap since HashMap was not stabilized in alloc::collections library.

    The functionality is identical and the only incompatibilities in the interface are that we cannot use std::error::Error or std::io::Error in no_std mode because these types have not been moved to alloc and there is no alternative.

    opened by garbageslam 44
  • Don't invoke the bundled protoc binary on non-gnu Linux hosts

    Don't invoke the bundled protoc binary on non-gnu Linux hosts

    Revisiting the problem reported in #182. Unfortunately, it percolates to builds that use tower-grpc-build and troubleshooting clues are currently less than ideal.

    Is it possible to avoid running the bundled protoc on non-glibc (e.g. musl) Linux host environment and report that a binary needs to be supplied? Notably this is different from the build target.

    opened by mzabaluev 24
  • Suggestion for enumerations

    Suggestion for enumerations

    Hello

    I'm still a bit unhappy about the fact enumerations are i32 values, for two reasons:

    • Handling them is cumbersome. I can't just access the field, I have to convert it first…
    • They are interchangeable. Let's say I have enums enum Direction { Unspecified = 0, In = 1, Out = 2 } and enum Proto { Unspecified = 0, Udp = 1, Tcp = 2 }. I can do message.proto = Direction::Out as i32 and it will work. I can do Direction::from_i32(message.proto) and it'll work. And I like Rust's strict type system keeping an eye on me.

    So I was wondering if there could be more convenient and safer alternative. What about:

    • Create the enum as it is now, eg enum Direction { Unspecified = 0, In = 1, Out = 2 }
    • Also create a companion struct DirectionRaw(pub i32)

    This way, we can have conversion methods on both of them to each other, but not with i32 directly (type safety). The fact the conversion methods would be on the DirectionRaw would make it more discoverable.

    Furthermore, I think the conversion method would be something like fn enum(&self) -> Option<Direction> ‒ this way it is possible to both know if the input was valid/known and call unwrap_or_default() on it to get the appropriate default.

    Does that make sense? Or does it have some downsides I don't see?

    I would be willing to implement it, but I wanted to check first if it makes sense.

    opened by vorner 22
  • Experiment with using `bytes::Bytes` to back bytes and string fields

    Experiment with using `bytes::Bytes` to back bytes and string fields

    This PR uses bytes::Bytes as the type for bytes and a new type BytesString as the type for string (rather than Vec<u8> and String). BytesStringis a wrapper around Bytes in the same way that String is a wrapper around Vec<u8>. Obviously this is a severe breaking change.

    This idea has been discussed in #31 and #35.

    This PR improves performance by 25% (!) on Mac OS, 9% on Ubuntu, and 2% on CentOS. This was tested using a fairly realistic benchmark dervied from TiKV, however, the bytes and string values were all quite small. I expect the performance improvements would be smaller for larger values. I also tested a multi-threaded version of the benchmark on Ubuntu, there the average improvement was only 1.5%, however, the worst-performing thread improved by 14%, so the overall time to completion was significantly improved.

    If we should go forward with this PR, then I think there are few open questions, but I thought I'd post early to get feedback about whether it was possible to land at all, given the back-compat situation.

    If we do land, I think we can probably get rid of the BytesMutString type and just use BytesString - I didn't see any performance benefit or usability benefit in using the BytesMut version.

    One option might be to land the change to bytes but not to string. I feel like that is a less invasive change but will get a decent benefit for some users.

    @danburkert what do you think?

    opened by nrc 20
  • Prost should not require user to include a `bytes` dependency.

    Prost should not require user to include a `bytes` dependency.

    By doing extern crate bytes in the generated derive, Prost requires the user to add a bytes dependency.

    Instead, the prost crate should re-export bytes. I have done this in the past by having a hidden codegen module w/ the re-exports. Example.

    opened by carllerche 16
  • Please release v0.6.2

    Please release v0.6.2

    opened by kuznero 15
  • Implement a recursion limit

    Implement a recursion limit

    This PR implements a recursion limit, which can be disabled by not setting a Cargo feature (which is on by default). This change is technically not backwards compatible, but in practice very few programs should hit the recursion limit.

    Although adding a context argument complicates the API somewhat, most clients would not implement or use the methods with the added argument and would instead only use decode, which is not changed.

    Fixes #176

    r? @danburkert

    opened by nrc 14
  • Permit using `FileDescriptorSet` as an intermediate compilation artifact

    Permit using `FileDescriptorSet` as an intermediate compilation artifact

    Currently based on #147.

    Motivation for doing this is so we can pre-compile the FileDescriptorSet and also so that the set can be inspected to find the package name and thus the name of the generated file.

    opened by nrc 14
  • Allow building prost-build without requiring curl & OpenSSL

    Allow building prost-build without requiring curl & OpenSSL

    For a variety of reasons, including improving the build time of my project, I would like to build prost-build without downloading and building curl and its dependencies, particularly OpenSSL. In particular, I would like to avoid the build failure I get:

    error: failed to run custom build command for `openssl-sys v0.9.26`
    process didn't exit successfully: `/home/m/go/src/github.com/runconduit/conduit/target/debug/build/openssl-sys-6bc9b54748dee815/build-script-build` (exit code: 101)
    --- stdout
    cargo:rerun-if-env-changed=X86_64_UNKNOWN_LINUX_GNU_OPENSSL_LIB_DIR
    cargo:rerun-if-env-changed=OPENSSL_LIB_DIR
    cargo:rerun-if-env-changed=X86_64_UNKNOWN_LINUX_GNU_OPENSSL_INCLUDE_DIR
    cargo:rerun-if-env-changed=OPENSSL_INCLUDE_DIR
    cargo:rerun-if-env-changed=X86_64_UNKNOWN_LINUX_GNU_OPENSSL_DIR
    cargo:rerun-if-env-changed=OPENSSL_DIR
    run pkg_config fail: "Failed to run `\"pkg-config\" \"--libs\" \"--cflags\" \"openssl\"`: No such file or directory (os error 2)"
    
    --- stderr
    thread 'main' panicked at '
    
    Could not find directory of OpenSSL installation, and this `-sys` crate cannot
    proceed without this knowledge. If OpenSSL is installed and this crate had
    trouble finding it,  you can set the `OPENSSL_DIR` environment variable for the
    compilation process.
    
    If you're in a situation where you think the directory *should* be found
    automatically, please open a bug at https://github.com/sfackler/rust-openssl
    and include information about your system as well as this message.
    
        $HOST = x86_64-unknown-linux-gnu
        $TARGET = x86_64-unknown-linux-gnu
        openssl-sys = 0.9.26
    
    
    It looks like you're compiling on Linux and also targeting Linux. Currently this
    requires the `pkg-config` utility to find OpenSSL but unfortunately `pkg-config`
    could not be found. If you have OpenSSL installed you can likely fix this by
    installing `pkg-config`.
    
    ', /home/m/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-sys-0.9.26/build.rs:213:5
    note: Run with `RUST_BACKTRACE=1` for a backtrace.
    
    warning: build failed, waiting for other jobs to finish...
    error: build failed
    

    I don't want to require users to install pkg_config or do any manual configuration.

    In fact, we already require protoc for the Go code in our project, so it would be ideal for us if we could download protoc ourselves and build prost-build without any downloading logic included at all.

    If it's not acceptable to provide a way to completely avoid the downloading logic then maybe #27 might help? However, since our project is security-sensitive it would also be important to verify the SHA-256 checksums of the downloaded files, instead of just relying on HTTPS, so I think additional work would be necessary.

    opened by briansmith 12
  • Optional support for bytes::Bytes type backing bytes field.

    Optional support for bytes::Bytes type backing bytes field.

    This is an attempt to support bytes::Bytes as a backing type for bytes fields. This is opt-in, the default remains Vec<u8>. The configuration at build time is similar to BTreeMap opt-in.

    ~For bytes fields with this feature enabled, no memory copying should take place when decoding from buffers backed by Bytes. Encoding will still copy data regardless of the backing type.~

    This does not address zero-copying, which would require specialisation or additional support in the Buf trait.

    opened by rolftimmermans 11
  • Add struct attributes from proto file

    Add struct attributes from proto file

    Issue #431

    opened by cemoktra 2
  • Clarify maintenance expectations

    Clarify maintenance expectations

    First of all, thank you very much for this library!

    There are currently some smaller but useful PRs that have no review or comments for weeks. Additionally, the last commit to master was a month ago. Can we help the maintainers scale in any way?

    It would be great to know what expectations contributors should have for PR merging and new releases so we can plan appropriately.

    opened by LegNeato 0
  • How to read protobuf text format data to generated prost code

    How to read protobuf text format data to generated prost code

    I am using tonic gRPC library which uses prost to generate the underlying protobuf rust structs. Now I have a protobuf text format file which I want to load its data to a generate strcut. Can I do this? Do I need to use some other libraries?

    opened by zyddnys 2
  • Manual include generated files

    Manual include generated files

    Hello,

    Include generated files using macro is not clear for IDE (intellijy idea) So I have no IDE hints.

    It could be easily fixed by including generated files in a common way like use proto::*

    But generated file names contains dot like some.items.rs that breaks all rust syntax

    Thanks for any help

    opened by incker 1
  • Question: Parsing Source File as `FileDescriptorProto`

    Question: Parsing Source File as `FileDescriptorProto`

    Hey, I want to do more advanced codegen than prost-build currently provides with ServiceGenerator. I want to be able to generate a second configuration that is more Rust friendly, and I want to be able to set attributes based on what the names, types, and values of the different messages and fields are.

    FileDescriptorProto has this information, however it doesn't like there is a public way to get FileDescriptorProto from a source .proto file. Would it be possible to have a public way to parse Protobuf source files?

    opened by XAMPPRocky 0
  • Add attributes just to messages.

    Add attributes just to messages.

    This add attributes just to Rust structs.

    opened by jozn 0
  • Extended field/type attributes

    Extended field/type attributes

    I wanted to have the ability to serialize a protobuf document with serde while using the protobuf field ids as keys.

    As an example, a message based on the following protobuf definition

    message test {
        int32 int_field = 1;
        string string_field = 2;
    }
    

    should be serialized as

    {
        "1": 123,
        "2": "asd"
    }
    

    To allow for this, I would need access to the field id when adding a new field/type attribute. In this Pull Request I've created one possible implementation of this. While working on this, I noticed that 79f0dfd seems to have removed/broken the ability to add multiple attributes to a single field/type.

    EDIT:

    I've not yet added any tests or documentation because I would first like to get some feedback, of whether the way I've implemented this is acceptable or if this should be implemented another way.

    opened by Xervon 0
  • Update outdated dependencies

    Update outdated dependencies

    opened by koushiro 0
  • Add dependabot

    Add dependabot

    opened by koushiro 0
  • Merging does not reset fields in case of default values

    Merging does not reset fields in case of default values

    merge is a nice way to avoid unnecessary allocations when reading messages from a buffer. Unfortunately, when merging from a buffer, fields do not get reset on the merged object when the fields on the Protobuf objects encoded in the buffer had their default values. This results in surprising special cases as seen below:

    message ProstMessage {
      uint32 int_value = 1;
      bytes byte_value = 2;
    }
    
    #[test]
    fn test_prost_merge() {
        let mut reused_msg = ProstMessage {
            int_value: 1,
            byte_value: b"value".to_vec(),
        };
    
        let msg_with_default_values = ProstMessage {
            int_value: 2,
            byte_value: Vec::new(),
        };
    
        let mut buf = Vec::new();
        msg_with_default_values.encode(&mut buf).unwrap();
    
        // `reused_msg.int_value` now contains 2 while `byte_value` has not been reset and still contains b"value".
        reused_msg.merge(buf.as_slice()).unwrap();
        assert_eq!(reused_msg, msg_with_default_values);
    }
    

    prost version: 0.7.0 Thank you for your work on Prost!

    opened by roncohen 1
Releases(v0.7.0)
  • v0.7.0(Dec 27, 2020)

    PROST! is a Protocol Buffers implementation for the Rust Language. prost generates simple, idiomatic Rust code from proto2 and proto3 files.

    prost 0.7.0 includes breaking changes:

    • The minimum-supported Rust version (MSRV) is now 1.46.0.
    • The bytes public dependency version is now 1.0.
    • The bundled protoc version is now 3.14.0.

    As well as many new (non-breaking) features and improvements:

    • @hockeybuggy added support for deprecated field annotations.
    • @garbageslam and @dflemstr added no_std support.
    • @joseph-wakeling-frequenz fixed a bug in Timestamp <-> SystemTime conversions.
    • @rolftimmermans added support for generating Rust bytes::Bytes fields from protobuf bytes fields. When deserializing from a Bytes instance, this enables zero-copy deserialization for bytes fields!
    • @olix0r bumped the bytes dependency to 0.6, which included most of the heavy lifting for the subsequent move to bytes 1.0.
    • @danburkert added support for the experimental proto3 optional field presence feature.

    and numerous smaller fixes. Many thanks to the generous contributors who have helped out since 0.6.1:

    • [email protected] Dunlap
    • @Max-Meldrum
    • @Veetaha
    • @dan-fritchman
    • @danburkert
    • @dflemstr
    • @dfreese
    • @gabrielrussoc
    • @garbageslam
    • @hockeybuggy
    • @jen20
    • @joseph-wakeling-frequenz
    • @olix0r
    • @oll3
    • @repi
    • @rolftimmermans
    • @vorot93
    • @wchargin
    Source code(tar.gz)
    Source code(zip)
  • v0.6.1(Jan 16, 2020)

    PROST! is a Protocol Buffers implementation for the Rust Language. prost generates simple, idiomatic Rust code from proto2 and proto3 files.

    prost 0.6.1 fixes a bug in which decoding untrusted input could overflow the stack. The bug was reported by @dbrgn in #267 (with an attached repro!), and fixed by @danburkert. The fix extended the same recursion limits introduced in #186 by @nrc (released in 0.6.0) to the logic which skips unknown fields during decoding, which became recursive when support was added for decoding groups (also released in 0.6.0). The 0.6.0 release of the prost crates has been yanked from crates.io.

    Additionally, @koushiro updated the private dependencies of all prost crates to the latest versions.

    Many thanks to the generous contributors who have helped out since 0.6.0:

    • Dan Burkert
    • Danilo Bargen
    • Qinxuan Chen
    Source code(tar.gz)
    Source code(zip)
  • v0.6.0(Jan 12, 2020)

    PROST! is a Protocol Buffers implementation for the Rust Language. prost generates simple, idiomatic Rust code from proto2 and proto3 files.

    prost 0.6.0 includes breaking changes:

    • The minimum-supported Rust version (MSRV) is now 1.39.0.
    • The bytes public dependency version is now 0.5.
    • The prost-types Timestamp and Duration types now impl TryFrom for their std::time equivalents. The old inherent try_from methods have been removed.
    • Deeply nested messages now fail decoding with an error, instead of potentially resulting in a stack overflow. The limit is set to a nesting depth of 100, and the limit can be disabled using a new no-recursion-limit Cargo feature.

    As well as many new (non-breaking) features and improvements:

    • @hanya added support for protobuf Group types.
    • @danburkert improved the benchmark suite, including adding support for the full set of upstream message encoding and decoding benchmarks.
    • @nrc implemented a series of micro-optimizations which result in faster message encoding and decoding.
    • @dunmatt improved the method docs on generated types.
    • @lukaslueg removed the dependency on byteorder.
    • @parasyte added the ServiceGenerator::finalize_package, which is useful for advanced service generators.
    • @joelgallant improved the error message that occurs when attempting to compile .proto files without a package specifier.
    • @LucioFranco removed the direct dependency of generated types on the bytes crate, which means applications which use prost code generation are no longer required to declare a bytes dependency.
    • @ErichDonGubler and @hobofan bumped the syn, quote, and proc-macro2 to stable versions.
    • @Timmmm improved prost-build so that it no longer writes .rs files when they are unchanged, which improves working with tools like cargo watch in codebases with prost code generation.
    • @Hirevo replaced usage of failure with anyhow.
    • @danburkert bumped the packaged protoc version to 3.11.2.

    Many thanks to the generous contributors who have helped out since 0.5.0:

    • Dan Burkert
    • Erich Gubler
    • FujiApple
    • Hanya
    • Jay Oster
    • Joel Gallant
    • koushiro
    • Lucio Franco
    • Luffbee
    • lukaslueg
    • [email protected] Dunlap
    • Maximilian Goisser
    • Mikhail Zabaluev
    • Nick Cameron
    • Nicolas Polomack
    • Stephan Wolski
    • Tim Hutt
    Source code(tar.gz)
    Source code(zip)
  • v0.5.0(Mar 10, 2019)

    PROST! is a Protocol Buffers implementation for the Rust Language. prost generates simple, idiomatic Rust code from proto2 and proto3 files.

    prost 0.5.0 should be mostly source-compatible with version 0.4.0, with one exception: prost 0.4.0 escapes field and message names which are Rust keyword by appending a suffix underscore; prost 0.5.0 does not escape field or message names, instead using the new raw-identifier feature. In addition, the minimum rustc version has been bumped to 1.32.0.

    0.5.0 ships with new features and bug fixes:

    • @adeschamps fixed a bug which caused enum fields with a default value whose prefix is stripped to be incorrectly generated.
    • @danburkert added an option for overriding the code-generation output directory with a new prost_build::Config::out_dir() method.
    • @danburkert added a re-export of prost-derive types in prost. As a result, it should no longer be necessary for applications to depend directly on the prost-derive crate.
    • @ebkalderon, @trha, and @danburkert added support to the code generator for referencing prost generated types in external crates with a new prost_build::Config::extern_path() method.
    • @jeffparsons made code generation more robust by always fully-qualifying standard library types.
    • @nrc added support for generating edition-2018 compatible code.

    Many thanks to the generous contributors who have helped out since 0.4.0:

    • Anthony Deschamps
    • Dan Burkert
    • Eliza Weisman
    • Eyal Kalderon
    • Jeff Parsons
    • Nick Cameron
    • Sebastian Hahn
    • Timothy Hobbs
    • Trinh Hoang Anh
    Source code(tar.gz)
    Source code(zip)
  • v0.4.0(Jun 13, 2018)

    PROST! is a Protocol Buffers implementation for the Rust Language. prost generates simple, idiomatic Rust code from proto2 and proto3 files.

    prost 0.4.0 contains new features, bug-fixes, and one breaking change since 0.3.0:

    • @briansmith cleaned up the project dependencies and build scripts, resulting in faster and more robust builds for all prost users.
    • @kestred added tag inference on fields in types which derive Message. Tag inference reduces the number annotations necessary when manually writing message structs.
    • @warrenfalk added logic to strip the enum name from enum variants which include the enum name as a prefix. This style is common with Protobuf (since it's heavily tied to C++ name resolution), however it's non-idiomatic in Rust. To restore the previous behavior a new Config option is provided: retain_enum_prefix. This is a breaking change.
    • @danburkert added helper methods for working with length delimiters independently of message encoding and decoding.
    • And many more bug fixes.

    Many thanks to the generous contributors who have helped out since 0.3.0:

    • Brian Smith
    • Dan Burkert
    • Gergely Nagy
    • Ivan Mironov
    • Kevin Stenerson
    • Warren Falk
    • YetAnotherMinion
    • hcpl
    Source code(tar.gz)
    Source code(zip)
  • v0.3.0(Jan 28, 2018)

    PROST! is a Protocol Buffers implementation for the Rust Language. prost generates simple, idiomatic Rust code from proto2 and proto3 files.

    prost 0.3.0 contains new features, bug-fixes, and one breaking change since 0.2.0:

    • @vorner added an important new feature to prost-build which allows custom attributes to be added to generated types. This allows applications to derive traits for generated types, such as SerDe support.
    • @vorner changed the Debug implementation for enumeration fields to be more helpful.
    • The prost_build::ServiceGenerator and prost_build::Config APIs have been changed to take &mut self instead of &self in order to simplify writing stateful service generators.

    Many thanks to the wonderful contributors who have pitched-in since 0.2.0:

    • Dan Burkert
    • Fabrice Desré
    • Michal 'vorner' Vaner
    • Oliver Gould
    Source code(tar.gz)
    Source code(zip)
  • v0.2.0(Sep 10, 2017)

    PROST! is a Protocol Buffers implementation for the Rust Language. prost generates simple, idiomatic Rust code from proto2 and proto3 files.

    prost 0.2.0 includes many improvements over the previous version, including:

    • The prost-codegen crate has been removed, and its functionality has been combined into prost-build.
    • A new crate, prost-types, containing Protobuf well-known types has been added. The code generator will automatically use prost-types when well-known types are encountered during .proto.rs code generation.
    • Field accessors for proto2 optional fields and enum fields have been made more ergonomic.
    • prost-build has a new builder API (prost_build::Config), which can be used to specify custom code generation options. Current options include:
      • Using BTreeMap instead of HashMap for map fields.
      • Custom code generation for protobuf service definitions.
    • New prost-specific error types, prost::EncodeError and prost::DecodeError for encoding and decoding results.
    • The prost::Message trait has been made more flexible, and more ergonomic.
    • varint encoding and decoding has been optimized, see the following commit messages for results:
      • a655f2b00c29c7
      • 107857f443e4d6
      • 8a8c5ddbb646a8
    • Default values are now preserved during code generation (bugfix).
    • New Message::clear method.
    Source code(tar.gz)
    Source code(zip)
Owner
Dan Burkert
Dan Burkert
Rust implementation of Google protocol buffers

rust-protobuf Protobuf implementation in Rust. Written in pure rust Generate rust code Has runtime library for generated code (Coded{Input|Output}Stre

Stepan Koltsov 1.6k Jun 14, 2021
Cap'n Proto for Rust

Cap'n Proto for Rust documentation blog Introduction Cap'n Proto is a type system for distributed systems. With Cap'n Proto, you describe your data an

Cap'n Proto 1.2k Jun 11, 2021
A Gecko-oriented implementation of the Encoding Standard in Rust

encoding_rs encoding_rs an implementation of the (non-JavaScript parts of) the Encoding Standard written in Rust and used in Gecko (starting with Fire

Henri Sivonen 205 Jun 5, 2021
rust-jsonnet - The Google Jsonnet( operation data template language) for rust

rust-jsonnet ==== Crate rust-jsonnet - The Google Jsonnet( operation data template language) for rust Google jsonnet documet: (http://google.github.io

Qihoo 360 23 Feb 15, 2021
Rusty Object Notation

Rusty Object Notation RON is a simple readable data serialization format that looks similar to Rust syntax. It's designed to support all of Serde's da

ron-rs 1.6k Jun 15, 2021
MessagePack implementation for Rust / msgpack.org[Rust]

RMP - Rust MessagePack RMP is a pure Rust MessagePack implementation. This repository consists of three separate crates: the RMP core and two implemen

Evgeny Safronov 580 Jun 14, 2021
Implementation of Bencode encoding written in rust

Rust Bencode Implementation of Bencode encoding written in rust. Project Status Not in active developement due to lack of time and other priorities. I

Arjan Topolovec 30 May 6, 2021
A fast, performant implementation of skip list in Rust.

Subway A fast, performant implementation of skip list in Rust. A skip list is probabilistic data structure that provides O(log N) search and insertion

Sushrut 15 Mar 13, 2021
proc-macro for accessing struct field names at runtime

field_names field_names is a Rust crate to expose a field or variant names from source code as strings at runtime. Example Consider a simple struct su

Ted Driggs 11 Mar 2, 2021
Rust implementation of CRC(16, 32, 64) with support of various standards

crc Rust implementation of CRC(16, 32, 64). MSRV is 1.46. Usage Add crc to Cargo.toml [dependencies] crc = "2.0" Compute CRC use crc::{Crc, Algorithm,

Rui Hu 81 May 27, 2021
Pure Rust port of CRFsuite: a fast implementation of Conditional Random Fields (CRFs)

crfs-rs Pure Rust port of CRFsuite: a fast implementation of Conditional Random Fields (CRFs) Currently only support prediction, model training is not

messense 15 May 22, 2021
FlatBuffers compiler (flatc) as API (with focus on transparent `.fbs` to `.rs` code-generation via Cargo build scripts integration)

FlatBuffers flatc API for Rust This crate provides a programmatical way to invoke flatc command (e.g. from build.rs) to generate Rust (or, in fact, an

Vlad Frolov 63 May 7, 2021
Crate to parse and emit EDN

edn-rs Near Stable no breaking changes expected. Crate to parse and emit EDN This lib does not make effort to conform the EDN received to EDN Spec. Th

Julia Naomi 35 May 28, 2021
Character encoding support for Rust

Encoding 0.3.0-dev Character encoding support for Rust. (also known as rust-encoding) It is based on WHATWG Encoding Standard, and also provides an ad

Kang Seonghoon 231 Jun 2, 2021