Giter VIP home page Giter VIP logo

rust-protobuf's Introduction

rust-protobuf

crates.io version docs.rs GitHub Workflow Status License

Protobuf implementation in Rust.

  • Written in pure rust
  • Generates rust code
  • Has runtime library support for generated code (Coded{Input|Output}Stream impl)
  • Supports both Protobuf versions 2 and 3
  • and more

Where is documentation

Documentation is hosted on docs.rs.

Versions and branches

Version 3

Version 3 is current stable version. Compared to version 2 it implements:

  • runtime reflection
  • JSON and text format parsing and printing
  • dynamic messages (messages which can be created from .proto file on the fly without code generation)

Version 2

Version 2 is previous stable version. Only most critical bugfixes will be applied to 2.x version, otherwise it won't be maintained.

Help

The crate needs help:

  • a new maintainer, but also
  • testing
  • documentation
  • examples to be used as documentation
  • feedback on API design
  • feedback on implementation
  • pull requests

Changelog

See CHANGELOG.md for a list of changes and compatility issues between versions.

Related projects

  • prost — another protobuf implementation in Rust, also has gRPC implementation
  • quick-protobuf — alternative protobuf implementation in Rust
  • grpc-rs — another gRPC implementation for Rust
  • grpc-rust — incomplete implementation of gRPC based on this library

rust-protobuf's People

Contributors

appaquet avatar bacek avatar benesch avatar blei avatar bonifaido avatar borntyping avatar busyjay avatar calavera avatar chinedufn avatar danburkert avatar dixeran avatar ealasu avatar erickt avatar hansjorg avatar jansegre avatar king6cong avatar martinvonz avatar meh avatar overvenus avatar rajatgoel avatar rcorre avatar robn avatar scottlamb avatar stepancheg avatar syakhmi avatar tamird avatar texitoi avatar thijsc avatar timandres avatar tommilligan avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

rust-protobuf's Issues

Enum variant collisions

A protobuf file like this:

message MessageA {
  enum EnumA { FOO = 0; }
}
message MessageB {
  enum EnumB { FOO = 0; }
}

generates Rust like:

#[deriving(Clone,Eq,Show)]
pub enum MessageA_EnumA {
    FOO = 0,
}

#[deriving(Clone,Eq,Show)]
pub enum MessageB_EnumB {
    FOO = 0,
}

Since Rust doesn't have scoped enums (and won't until after 1.0), a workaround for this might be to place protobuf messages into their own Rust modules. protoc enforces that enum values must be unique within messages, e.g. this:

message MessageA {
  enum EnumA { FOO = 0; }
  enum EnumB { FOO = 0; }
}

fails to compile with:

foo.proto:3:18: "FOO" is already defined in "MessageA".
foo.proto:3:18: Note that enum values use C++ scoping rules, meaning that enum values are siblings of their type, not children of it.  Therefore, "FOO" must be unique within "MessageA", not just within "EnumB".

Using modules instead of snake style naming for nested types

I would like to suggest using modules to create a cleaner output of complicated proto definitions.

The current approach is to use snake formatting on the names for nested types, carrying the hierarchy within the name.

For example when defining the following proto:

message Parent {
    optional Child child = 1;

    message Child {
        optional string name = 1;
    }
}

the current implementation generates the following Rust code:

// leaving impl and derivings out for conciseness 
pub struct Message {
    child: ::std::option::Option<Message_Child>
}

pub struct Message_Child {
    name: ::std::option::Option<::protobuf::SingularField<::std::string::String>>
}

I recommend the following structure instead:

pub struct Message {
    child: ::std::option::Option<Message::Child>
}

pub mod Message {
    pub struct Child {
        name: ::std::option::Option<::protobuf::SingularField<::std::string::String>>
    }
}

Make IO methods non-fatal.

Currently all major IO operations in this code-base just fail!() on an IO error. Which is highly impractical in real application use. It would be a lot more practical if they returned an IoResult instead, either with a set of alternative methods or just a rewrite of the current ones.

Transferring ownership of fields

Say type T has a field u of type U and field v of type V.
T and U are both ::protobuf::Message.

I have the following function:

fn foo(t: T) -> Result<U> {
    // look into t.v and return Err based on same value
    // return Ok(t.u) 
}

Even though it seems like I have ownership over t, I can't deconstruct a Message and pass on ownership of the field u.

I recommend adding something similar to the following two extra functions per field

    // same as existing
    pub fn mut_field(&'a mut self) -> &'a mut T {
        if self.status.is_none() {
            self.field.set_default();
        };
        self.field.as_mut().unwrap()
    }

    // same as existing
    pub fn get_field(&'a self) -> &'a T {
        self.field.as_ref().unwrap_or_else(|| T::default_instance())
    }

    // new, the idea is to take the field away from the enclosing message
    // ownership is transferred to the caller
    pub fn take_field(&mut self) -> T {
        // perhaps we should leave a tombstone behind 
        // the current impl of take refill the value with default
        self.field.take().unwrap() 
    }

    // the original message's life ends here, 
    // ownership of the field is passed on
    pub fn unwrap_field(self) -> T {
        self.field.unwrap()
    }

With the new semantics I can now implement my method by:

fn foo(t: T) -> Result<U> {
    let v = t.take_v();
    if v.w { Err("Error...") }
    else { Ok ( t.unwrap_u() ) }
}

I don't know if this is the correct way of solving the use case, but it makes it possible to implement.

Another option is...

A possible breaking change given that this needs to be implemented for each field is to have a single get_field that returns Field<T> and have that wrapper trait surface take(), unwrap(), as_ref(), and as_mut() (perhaps clone() if T : Clone). I know this is a subset of SingularField and SingularPtrField backing the internal Message.

Honestly, I've seen all those functions being used throughout the std and other crates, I'm not sure if it's worth bringing it up with the Rust devs but having 4 unique traits that represent each of those operations might clean up a lot of code and allow for certain generic macro sugaring. If I'm not mistaken, Deref and DerefMut cover the signatures for as_ref and as_mut as operator overloads which is what is currently available with get_field and get_mut_field. I'm not sure if the borrow module is more applicable.

Impossible to re-use protobuf instances with repeated fields

hello,

i've hit a nasty issue on re-using a protobuf instance (for performance reasons) which i tried to demonstrated here:

https://github.com/xitep/rust-protobuf-problem/blob/master/src/main.rs#L23

it seems that ::protobuf::RepeatedField::push_default() is the culprit here, as it correctly puts the new item into the next "free" slot in the underlying vector, but always returns a reference to the "last" slot, which might not always correspond to the slot the newly "pushed" item was placed to. read_repeated_message_into then incorrectly populates the wrong message.

unfortunately, i don't feel confident enough to fix this myself :(

Doesn't compile on 04-Jan-2015 nightly

Trying to build on today's rust nightly and failing at d831452 (same output on travis-ci, feel free to just close this if you want):

$ cargo test --verbose
   Compiling protobuf v0.0.8 (file:///Users/ajf/git/rust-protobuf)
     Running `rustc src/lib/protobuf.rs --crate-name protobuf --crate-type lib -g -C metadata=25ae144562462795 -C extra-filename=-25ae144562462795 --out-dir /Users/ajf/git/rust-protobuf/target --emit=dep-info,link -L /Users/ajf/git/rust-protobuf/target -L /Users/ajf/git/rust-protobuf/target/deps`
     Running `rustc src/lib/protobuf.rs --crate-name protobuf --crate-type lib -g --test -C metadata=99431cebf2a671d2 -C extra-filename=-99431cebf2a671d2 --out-dir /Users/ajf/git/rust-protobuf/target --emit=dep-info,link -L /Users/ajf/git/rust-protobuf/target -L /Users/ajf/git/rust-protobuf/target/deps`
src/lib/hex.rs:44:38: 44:39 error: expected one of `(`, `+`, `::`, `;`, or `]`, found `,`
src/lib/hex.rs:44:38: 44:39 error: expected one of `(`, `+`, `::`, `;`, or `]`, found `,`
src/lib/hex.rs:44 fn encode_hex_byte(byte: u8) -> [char, ..2] {
src/lib/hex.rs:44 fn encode_hex_byte(byte: u8) -> [char, ..2] {
                                                       ^
                                                       ^
Build failed, waiting for other jobs to finish...
Could not compile `protobuf`.

Caused by:
  Process didn't exit successfully: `rustc src/lib/protobuf.rs --crate-name protobuf --crate-type lib -g --test -C metadata=99431cebf2a671d2 -C extra-filename=-99431cebf2a671d2 --out-dir /Users/ajf/git/rust-protobuf/target --emit=dep-info,link -L /Users/ajf/git/rust-protobuf/target -L /Users/ajf/git/rust-protobuf/target/deps` (status=101)

Version:

$ rustc --version
rustc 0.13.0-nightly (c6c786671 2015-01-04 00:50:59 +0000)

Release new crate of protobuf

The current protobuf crate fails to compile with:

/Users/erickt/.multirust/toolchains/nightly/cargo/registry/src/github.com-0a35038f75765ae4/protobuf-1.0.1/src/lib/core.rs:138:55: 138:57 error: missing lifetime specifier [E0106]
/Users/erickt/.multirust/toolchains/nightly/cargo/registry/src/github.com-0a35038f75765ae4/protobuf-1.0.1/src/lib/core.rs:138 pub fn message_down_cast<M : Message>(m: &Message) -> &M {
                                                                                                                                                                                    ^~
/Users/erickt/.multirust/toolchains/nightly/cargo/registry/src/github.com-0a35038f75765ae4/protobuf-1.0.1/src/lib/core.rs:138:55: 138:57 help: run `rustc --explain E0106` to see a detailed explanation
/Users/erickt/.multirust/toolchains/nightly/cargo/registry/src/github.com-0a35038f75765ae4/protobuf-1.0.1/src/lib/core.rs:138:55: 138:57 help: this function's return type contains a borrowed value, but the signature does not say which one of `m`'s 2 elided lifetimes it is borrowed from

This has been fixed in the git repository though. Could a new version of the crate be released that has this fixed?

imported enums are not brought into scope

moriarty:/tmp/tryout(master)$ cat base.proto 
package My;

enum Base {
 VALUE_A = 1;
 VALUE_B = 2;
};

message Some {
}
moriarty:/tmp/tryout(master)$ cat user.proto
package My;

import "base.proto";

message Test {
 required int32 id = 1;
 required Base value = 2;
 required Some value2 = 3;
};

And this is the content of the generated user.rs:

// This file is generated. Do not edit

#![allow(dead_code)]
#![allow(non_camel_case_types)]
#![allow(non_upper_case_globals)]
#![allow(unused_imports)]

use super::base::Some;

#[deriving(Clone,PartialEq,Default)]
pub struct Test {
    id: ::std::option::Option<i32>,
    value: ::std::option::Option<Base>,
    value2: ::protobuf::SingularPtrField<Some>,
    unknown_fields: ::protobuf::UnknownFields,
}
....

Note the second field in Test structure - the enum name is not brought into user.rs's scope. The third field (message from the same base file) is correctly imported, though.

Add a LICENSE file

I saw that in src/lib/protobuf.rs you specify the license is BSD, but can you add a toplevel license file to make it clear whether or not the whole project is covered by a BSD license?

mutating transmuted &mut T from &T may cause undefined behavior

17:36 $ rustc --version
rustc 1.0.0 (a59de37e9 2015-05-13) (built 2015-05-14)

.cargo/git/checkouts/rust-protobuf-ed1e2bca5258dbce/master/src/lib/lazy.rs:19:17: 19:57 error: mutating transmuted &mut T from &T may cause undefined behavior,consider instead using an UnsafeCell, #[deny(mutable_transmutes)] on by default
.cargo/git/checkouts/rust-protobuf-ed1e2bca5258dbce/master/src/lib/lazy.rs:19 mem::transmute::<&Lazy, &mut Lazy>(self).ptr = ptr;
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.cargo/git/checkouts/rust-protobuf-ed1e2bca5258dbce/master/src/lib/maybe_owned_slice.rs:22:61: 22:75 error: mutating transmuted &mut T from &T may cause undefined behavior,consider instead using an UnsafeCell, #[deny(mutable_transmutes)] on by default
.cargo/git/checkouts/rust-protobuf-ed1e2bca5258dbce/master/src/lib/maybe_owned_slice.rs:22 MaybeOwnedSlice::Ref(ref mut slice) => unsafe { mem::transmute(slice.as_ref()) }

I would try to fix it, but unfortunately my rust is way to rusty.
Adding in #![allow(mutable_transmutes)] in those two files allows it to compile for now, but I suppose this is an error that warrants a code change.

Eliminate @-boxes

I'm trying to use rust-protobuf in embedded code I'm calling from outside of Rust, and the usage of @-boxes is causing issues (since my code isn't running inside of a Rust task).

Any chance we could get them removed?

usable with Cargo

Such that one can add [dependencies.protobuf] git = "https://github.com/stepancheg/rust-protobuf"

method `as_slice` is not a member of trait `Slice

Hello! I tried to build rust-protobuf with cargo and got the error:

src/lib/repeated.rs:282:5: 284:6 error: method `as_slice` is not a member of trait `Slice`
src/lib/repeated.rs:282     fn as_slice<'a>(&'a self) -> &'a [T] {
src/lib/repeated.rs:283         self.vec.slice_to(self.len)
src/lib/repeated.rs:284     }

I have the newest version of Rust:

rustc 0.12.0-nightly (060623488 2014-10-08 01:02:10 +0000)

dependencies between protobufs not at crate root

Currently, dependencies are imported via "use ::*;". But if you have a lot of protobufs and put them in a subdirectory this doesn't work because imports are not relative but always from the crate root.

My fix is "use super::::*;".

Packed repeated fields do not decode correctly

message Test4 {
repeated int32 d = 4 [packed=true];
}

msg = "\x22\x06\x03\x8e\x02\x9e\xa7\x05";

Receive: task '

' failed at 'at EOF', lib/core.rs:165
Expected 'd' to be an array of: 3, 270, 86942

Problem with repeated enum

input file:

message Relation {
  enum MemberType {
    NODE = 0;
    WAY = 1;
  } 
   repeated MemberType types = 10 [packed = true];
}

After generation, trying to compile the generated file gives

     Running `rustc /home/texitoi/dev/osmreader-rs/src/lib.rs --crate-name osmreader-rs --crate-type lib -g -C metadata=7d9f23b7d487a759 -C extra-filename=-7d9f23b7d487a759 --out-dir /home/texitoi/dev/osmreader-rs/target --dep-info /home/texitoi/dev/osmreader-rs/target/.fingerprint/osmreader-rs-7d9f23b7d487a759/dep-lib-osmreader-rs -L /home/texitoi/dev/osmreader-rs/target -L /home/texitoi/dev/osmreader-rs/target/deps --extern protobuf=/home/texitoi/dev/osmreader-rs/target/deps/libprotobuf-36a283ad76a0868a.rlib`
/home/texitoi/dev/osmreader-rs/src/test.rs:97:24: 97:62 error: the trait `protobuf::rt::ProtobufVarint` is not implemented for the type `test::Relation_MemberType`
/home/texitoi/dev/osmreader-rs/src/test.rs:97             my_size += ::protobuf::rt::vec_packed_varint_size(10, self.types.as_slice());
                                                                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/texitoi/dev/osmreader-rs/src/test.rs:97:24: 97:62 note: the trait `protobuf::rt::ProtobufVarint` must be implemented because it is required by `protobuf::rt::vec_packed_varint_size`
/home/texitoi/dev/osmreader-rs/src/test.rs:97             my_size += ::protobuf::rt::vec_packed_varint_size(10, self.types.as_slice());
                                                                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/texitoi/dev/osmreader-rs/src/test.rs:110:40: 110:83 error: the trait `protobuf::rt::ProtobufVarint` is not implemented for the type `test::Relation_MemberType`
/home/texitoi/dev/osmreader-rs/src/test.rs:110             try!(os.write_raw_varint32(::protobuf::rt::vec_packed_varint_data_size(self.types.as_slice())));
                                                                                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<std macros>:1:1: 8:2 note: in expansion of try!
/home/texitoi/dev/osmreader-rs/src/test.rs:110:13: 110:109 note: expansion site
/home/texitoi/dev/osmreader-rs/src/test.rs:110:40: 110:83 note: the trait `protobuf::rt::ProtobufVarint` must be implemented because it is required by `protobuf::rt::vec_packed_varint_data_size`
/home/texitoi/dev/osmreader-rs/src/test.rs:110             try!(os.write_raw_varint32(::protobuf::rt::vec_packed_varint_data_size(self.types.as_slice())));
                                                                                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<std macros>:1:1: 8:2 note: in expansion of try!
/home/texitoi/dev/osmreader-rs/src/test.rs:110:13: 110:109 note: expansion site
error: aborting due to 2 previous errors
Could not compile `osmreader-rs`.

Caused by:
  Process didn't exit successfully: `rustc /home/texitoi/dev/osmreader-rs/src/lib.rs --crate-name osmreader-rs --crate-type lib -g -C metadata=7d9f23b7d487a759 -C extra-filename=-7d9f23b7d487a759 --out-dir /home/texitoi/dev/osmreader-rs/target --dep-info /home/texitoi/dev/osmreader-rs/target/.fingerprint/osmreader-rs-7d9f23b7d487a759/dep-lib-osmreader-rs -L /home/texitoi/dev/osmreader-rs/target -L /home/texitoi/dev/osmreader-rs/target/deps --extern protobuf=/home/texitoi/dev/osmreader-rs/target/deps/libprotobuf-36a283ad76a0868a.rlib` (status=101)

Compilation exited abnormally with code 101 at Tue Nov 18 00:33:42

Versions:

  • rust-protobuf version: 1d9ed54
  • protoc version: libprotoc 2.6.1
  • rustc 0.13.0-dev (0b48001c2 2014-11-07 15:26:26 +0000)
  • cargo 0.0.1-pre (e2ef57d 2014-11-07 16:52:47 +0000)

./rebuild.sh fails with rustc error: "error: expected type, found token BINOP(OR)"

Following the install instructions, running ./rebuild.sh fails. Specifically:

➜  src git:(master) ./rebuild.sh 
+ ./clean.sh
+ find . -name '*.dylib' -o -name '*.dSYM' -o -name '*.bin' -o -name '*.so'
+ xargs rm -rf
+ rustc lib/protobuf.rs
lib/core.rs:379:45: 379:46 error: expected type, found token BINOP(OR)
lib/core.rs:379     fn with_coded_output_stream<T>(self, cb: |&mut CodedOutputStream| -> T) -> T;

This is with rust 0.8 on x86_64 Linux (Archlinux AUR pkgbuild)

➜  src git:(master) rustc -v          
rustc 0.8
host: x86_64-unknown-linux-gnu

Field called type causes reflect to panic

I have a simple message that contains a single field named type.
Any attempt to print it using debugging format causes the reflection code to crash.
I guess it is because it attempts to access field type, which has been renamed to field_type
by codegen.

message Test {
    required uint32 type = 1;
}
let mut m = Test::new();
m.set_field_type(4);
println!("{:?}", m); // panic here
thread '<main>' panicked at 'called `Option::unwrap()` on a `None` value', /Users/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-mac/build/src/libcore/option.rs:362
stack backtrace:
   1:        0x104d1373f - sys::backtrace::write::hc8a4ac867687625dies
   2:        0x104d16c04 - panicking::on_panic::h8a20ee230368976dxuw
   3:        0x104d0ed35 - rt::unwind::begin_unwind_inner::hdec022e876757f01gcw
   4:        0x104d0f41c - rt::unwind::begin_unwind_fmt::h6ffe61c334a81630mbw
   5:        0x104d164bc - rust_begin_unwind
   6:        0x104d35205 - panicking::panic_fmt::hc0cb216b0f898facEJy
   7:        0x104d35154 - panicking::panic::h5c352fa81b4f5cf8bIy
   8:        0x104c92478 - option::Option<T>::unwrap::h12820952555303311384
   9:        0x104c916f8 - reflect::MessageDescriptor::new::closure.4648
  10:        0x104c915d7 - iter::Map<I, F>.Iterator::next::closure.4644
  11:        0x104c9149e - option::Option<T>::map::h12179503210630204013
  12:        0x104c91404 - iter::Map<I, F>.Iterator::next::h12575282655155023275
  13:        0x104c91393 - iter::_&'a mut I.Iterator::next::h17189323014514060804
  14:        0x104c91304 - iter::Take<I>.Iterator::next::h2206481008204609051
  15:        0x104c902c3 - vec::Vec<T>.FromIterator<T>::from_iter::h12574294513805214255
  16:        0x104c90030 - iter::Iterator::collect::h6603589765976519801
  17:        0x104c7b04e - reflect::MessageDescriptor::new::h11062906760305917723
  18:        0x104c74c14 - msg::Test...protobuf..MessageStatic::descriptor_static::closure.3891
  19:        0x104c71979 - lazy::Lazy<T>::get::closure.3833
  20:        0x104c717eb - sync::once::Once::call_once::h7754093350322956144
  21:        0x104c7167d - lazy::Lazy<T>::get::h74979825192033724
  22:        0x104c715cf - msg::Test...protobuf..MessageStatic::descriptor_static::ha116929cd4f9ae48uia
  23:        0x104c71578 - msg::Test...protobuf..Message::descriptor::h099d4e1312c73cdb7ha
  24:        0x104cf3985 - text_format::print_to::hf9a33b7fd8039c13omx
  25:        0x104cf654e - text_format::print_to_string::hb9b9173032ac65d4vux
  26:        0x104cc2149 - text_format::fmt::h156c8e0962acd3f2Qux
  27:        0x104c8ff07 - msg::Test...std..fmt..Debug::fmt::h78214780a5514a771ja
  28:        0x104d3814d - fmt::write::h7aca274ef3902e05xHJ
  29:        0x104d11b49 - io::stdio::Stdout.Write::write_fmt::h82d82a8be2155cd2UOg
  30:        0x104d1274c - io::stdio::_print::h97cc25fb41ad3e58yUg
  31:        0x104ca09b3 - main::h70973f5aca5402cd9ma
  32:        0x104d18508 - rust_try_inner
  33:        0x104d184f5 - rust_try
  34:        0x104d17410 - rt::lang_start::hbc0f1b2e8eb249ce2ow
  35:        0x104ca0a6e - main

Idea: API for generating code on a cargo build script.

Cargo has updated the way build scripts work, with the latest changes it makes sense to have a simple function for use on a build.rs that given a .proto file will generate the .rs file on build time.

Usage would be something like this, inside build.rs:

let protos_dir = Path::new(os::getenv("CARGO_MANIFEST_DIR").unwrap()).join("my_protos");
let out_dir = Path::new(os::getenv("OUT_DIR").unwrap());
protobuf::build::generate(protos_dir.join("foo.proto"), out_dir);

Main advantage would be no need for either versioning generated .rs files or depending on on protoc.
The drawback would be doubled dependency on this crate, as a dependency and build-dependency, which could probably be solved by splitting protobuf on something like protobuf-gen and protobuf-runtime.

This looks fairly simple to implement and naturally it would be completely optional to use it that way. However I wanted to share the idea before trying to implement, partially because I'm having little time to spare lately and partially because I'd like to hear what other people think about it.

Doesn't compile with rust 1.0.0-nightly (build 2015-03-27)

Hi,

'cargo build' cannot compile the master branch.

/.cargo/git/checkouts/rust-protobuf-ed1e2bca5258dbce/master/src/lib/codegen.rs:106:27: 106:44 error: box pattern syntax is experimental
/.cargo/git/checkouts/rust-protobuf-ed1e2bca5258dbce/master/src/lib/codegen.rs:106 RustType::Ref(box RustType::Str) => """".to_string(),

Hope that helps ;-)
Cheers,
Philipp

Support namespaced enums

Now that namespaced enums have landed in Rust the generated code can rely on them to avoid collisions. That is, this:

message MessageA {
  enum EnumA { FOO = 0; }
}
message MessageB {
  enum EnumB { FOO = 0; }
}

can now generate:

pub enum MessageA_EnumA {
    FOO = 0,
}
pub enum MessageB_EnumB {
    FOO = 0,
}

without issue.

cc #21

the type of this value must be known in this context

rebuild.sh fails with:

rustc 0.10-pre (e63b2d3 2014-03-30 21:11:40 -0700)

lib/hex.rs:46:41: 46:46 error: the type of this value must be known in this context
lib/hex.rs:46         str::from_chars(encode_hex_byte(*byte))
                                                      ^~~~~

protobuf3 support

  • Store scalar values without option, do not serialize zeros (implemented in master)
  • Maps
  • text format
  • Any

Error compiling with rust 1.0

.../rust-protobuf-7a0a851bef232540/master/src/lib/stream.rs:2:5: 2:18 error: unresolved import std::num::Int. There is no Int in std::num
.../rust-protobuf-7a0a851bef232540/master/src/lib/stream.rs:2 use std::num::Int;
^~~~~~~~~~~~~
.../rust-protobuf-7a0a851bef232540/master/src/lib/rt.rs:4:5: 4:32 error: unresolved import std::iter::AdditiveIterator. There is no AdditiveIterator in std::iter
.../rust-protobuf-7a0a851bef232540/master/src/lib/rt.rs:4 use std::iter::AdditiveIterator;

Does RepeatedField need a len field?

I'm a bit confused by the implementation of RepeatedField. It seems to me that for all means and purposes it could be a newtype:

struct RepeatedField<T>(Vec<T>);

impl<T> Deref for RepeatedField<T> {
    type Target = Vec<T>;
    fn deref(&self) -> &Vec<T> { &self.0 }
}

impl<T> DerefMut for RepeatedField<T> {
    fn deref_mut(&mut self) -> &mut Vec<T> { &mut self.0 }
}

with Deref and DerefMut implementations for Vec rather than [T](so as to forward method calls like .push, .extend etc to the inner vec).

I'm sure I'm missing some clever trick with the len field, could anyone explain why it's implemented the way it is?

Fields named "type" inside oneofs cause syntax errors

Given this proto file:

syntax = "proto3";

message Test {
  oneof type {
    string foo = 1;
    string bar = 2;
  }
}

The following Rust is generated:

#[derive(Clone,Default)]
pub struct Test {
    // message fields
    // message oneof groups
    type: ::std::option::Option<Test_oneof_type>,
    // special fields
    unknown_fields: ::protobuf::UnknownFields,
    cached_size: ::std::cell::Cell<u32>,
}

This is a syntax error because a struct cannot have a field named with the keyword type. I know this is worked around for normal message fields by renaming the field to "field_type" but it doesn't seem to do that when the field is in a oneof. I tried it with both proto3 and proto2 and had the same results.

On the topic, something I am curious about: is it sufficient to simply rename the field "field_type" in the Rust code? Will it still be serialized as "type"?

I tried a simple test where the field was actually named "field_type" in the proto file and the only thing that seemed to change in the generated Rust file was the contents of the static file_descriptor_proto_data array, which makes me think rust-protobuf is smart enough not to call the field "field_type" in the serialized format when it was only renamed to avoid the syntax error. I'd appreciate if that could be confirmed, though.

Here's the output of the diff, in case it's helpful:

$ diff test_with_type.rs test_with_field_type.rs
43c43
<     // optional string type = 1;

---
>     // optional string field_type = 1;
199,208c199,209
<     0x0a, 0x0a, 0x74, 0x65, 0x73, 0x74, 0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x22, 0x14, 0x0a, 0x04,
<     0x54, 0x65, 0x73, 0x74, 0x12, 0x0c, 0x0a, 0x04, 0x74, 0x79, 0x70, 0x65, 0x18, 0x01, 0x20, 0x01,
<     0x28, 0x09, 0x4a, 0x70, 0x0a, 0x06, 0x12, 0x04, 0x00, 0x00, 0x04, 0x01, 0x0a, 0x08, 0x0a, 0x01,
<     0x0c, 0x12, 0x03, 0x00, 0x00, 0x12, 0x0a, 0x0a, 0x0a, 0x02, 0x04, 0x00, 0x12, 0x04, 0x02, 0x00,
<     0x04, 0x01, 0x0a, 0x0a, 0x0a, 0x03, 0x04, 0x00, 0x01, 0x12, 0x03, 0x02, 0x08, 0x0c, 0x0a, 0x0b,
<     0x0a, 0x04, 0x04, 0x00, 0x02, 0x00, 0x12, 0x03, 0x03, 0x02, 0x12, 0x0a, 0x0d, 0x0a, 0x05, 0x04,
<     0x00, 0x02, 0x00, 0x04, 0x12, 0x04, 0x03, 0x02, 0x02, 0x0e, 0x0a, 0x0c, 0x0a, 0x05, 0x04, 0x00,
<     0x02, 0x00, 0x05, 0x12, 0x03, 0x03, 0x02, 0x08, 0x0a, 0x0c, 0x0a, 0x05, 0x04, 0x00, 0x02, 0x00,
<     0x01, 0x12, 0x03, 0x03, 0x09, 0x0d, 0x0a, 0x0c, 0x0a, 0x05, 0x04, 0x00, 0x02, 0x00, 0x03, 0x12,
<     0x03, 0x03, 0x10, 0x11, 0x62, 0x06, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x33,

---
>     0x0a, 0x0a, 0x74, 0x65, 0x73, 0x74, 0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x22, 0x1a, 0x0a, 0x04,
>     0x54, 0x65, 0x73, 0x74, 0x12, 0x12, 0x0a, 0x0a, 0x66, 0x69, 0x65, 0x6c, 0x64, 0x5f, 0x74, 0x79,
>     0x70, 0x65, 0x18, 0x01, 0x20, 0x01, 0x28, 0x09, 0x4a, 0x70, 0x0a, 0x06, 0x12, 0x04, 0x00, 0x00,
>     0x04, 0x01, 0x0a, 0x08, 0x0a, 0x01, 0x0c, 0x12, 0x03, 0x00, 0x00, 0x12, 0x0a, 0x0a, 0x0a, 0x02,
>     0x04, 0x00, 0x12, 0x04, 0x02, 0x00, 0x04, 0x01, 0x0a, 0x0a, 0x0a, 0x03, 0x04, 0x00, 0x01, 0x12,
>     0x03, 0x02, 0x08, 0x0c, 0x0a, 0x0b, 0x0a, 0x04, 0x04, 0x00, 0x02, 0x00, 0x12, 0x03, 0x03, 0x02,
>     0x18, 0x0a, 0x0d, 0x0a, 0x05, 0x04, 0x00, 0x02, 0x00, 0x04, 0x12, 0x04, 0x03, 0x02, 0x02, 0x0e,
>     0x0a, 0x0c, 0x0a, 0x05, 0x04, 0x00, 0x02, 0x00, 0x05, 0x12, 0x03, 0x03, 0x02, 0x08, 0x0a, 0x0c,
>     0x0a, 0x05, 0x04, 0x00, 0x02, 0x00, 0x01, 0x12, 0x03, 0x03, 0x09, 0x13, 0x0a, 0x0c, 0x0a, 0x05,
>     0x04, 0x00, 0x02, 0x00, 0x03, 0x12, 0x03, 0x03, 0x16, 0x17, 0x62, 0x06, 0x70, 0x72, 0x6f, 0x74,
>     0x6f, 0x33,

Messages encoded with a numeric field set are only partially encoded

When I encode a message with a numeric field set it is only partially encoded, and an identical stream of bytes are written that encoding a message without that field set writes. This happens for sint64, int64, float and double fields.

It does not seem to happen when only a numeric field is sent, though I haven't attempted to decode such a message.

I've reproduced the issue in this gist:
https://gist.github.com/borntyping/ae4b2436b668ebc8e774

{str: "hello world"} -> [104, 101, 108, 108, 111, 32, 119, 111, 114, 108, 100]
{num_int64: 64 str: "hello world"} -> [104, 101, 108, 108, 111, 32, 119, 111, 114, 108, 100]

update crates.io

Now that rust-protobuf is stable compliant, it can be great to have a stable compliant version on crates.io, as this version should compile forever.

A large number of messages cannot be processed quickly in succession.

When handling a lot of messages, of the same type in succession, each instance is constructed from scratch and destroyed placing heavy load on the memory allocator. If the message/allocated memory could be reused, like in C++, it would be ideal. The C++ version can handle millions of messages per second (Thinkpad x230) the Rust version is in the tens of thousands per second.

task 'core::test::test_output_stream_write_double_no_tag' has overflowed its stack

With #32 applied

rustc 0.12.0-nightly (740905042 2014-09-29 23:52:21 +0000)
running 49 tests
test core::test::test_input_stream_limits ... ok
test core::test::test_input_stream_read_raw_byte ... ok
test core::test::test_input_stream_read_double ... ok
test core::test::test_input_stream_read_varint ... ok
test core::test::test_input_stream_skip_raw_bytes ... ok
test core::test::test_output_input_stream_read_float ... ok
task 'core::test::test_output_stream_write_double_no_tag' has overflowed its stack
task 'core::test::test_output_stream_write_float_no_tag' has overflowed its stack

Cannot include generated code

Hi,

following cargo's documentation I've tried to generate my protobufs at build time (through a build.rs script) and include them in my main.rs using:

...
mod model {
    include!(concat!(env!("OUT_DIR"), "/model.rs"));
}
...

However, the (rustc) compilation then fails with:

.../target/debug/build/pubmonitor-42b07ea6e237e2f6/out/model.rs:3:3: 3:4 error: an inner attribute is not permitted in this context
.../target/debug/build/pubmonitor-42b07ea6e237e2f6/out/model.rs:3 #![allow(dead_code)]
                                                                    ^
.../target/debug/build/pubmonitor-42b07ea6e237e2f6/out/model.rs:3:3: 3:4 help: place inner attribute at the top of the module or block
...

It seems that module level attributes (e.g. #![allow(dead_code)] here) are not allowed in included content. Would there be a way to avoid these in the generated code by turning them into item-level attributes where needed?

Many thanks,
P.

Cannot import files that are generated from proto files with dots in their name

Example: my.test.file.proto generates my.test.file.rs. Rust is not able to import those directly, but this problem can be worked around by using #[path="my.test.file.rs"] mod my_test_file;. Unfortunately, this doesn't work if the file is included in another auto-generated proto file, as that generates mod my.test.file; which doesn't compile.

Two possible fixes:

  • Generate mods using #[path]: this expects the user to also use that workaround
  • Generate files without dots in them: this has the problem that we might generate conflicts if the same file is present once with dots and once without

Feature request: Support mutable method chaining.

Thanks for the awesome work on this! I think a builder style API for protos (without an actual separate builder type) would be great for ergonomics.

I think being able to do something like:

message
    .set_foo("abc")
    .set_bar(123)
    .mut_baz()
        .clear_frob()
        .set_frick(2);

would be very nice and easy to implement: -> &mut Self for set_ and clear_ methods.

Bonus
For ergonomics, a push_foo(x) method for repeated fields which does mut_foo().push(x) but returns &mut Self, allowing message.push_foo(1).push_foo(2).push_foo(3).

What do you think?

What's the point of RepeatedField?

Some repeated types are implemented with Vec, and some are implemented with RepeatedField. RepeatedField seems to be just using a Vec as a growable capacity, but Vec already does this internally. Is there a plan to replace all remaining RepeatedField with Vec at some point?

type `~[descriptor::FieldDescriptorProto]` does not implement any method in scope named `flat_map`

./rebuild.sh fails with:

rustc 0.10-pre (e63b2d3 2014-03-30 21:11:40 -0700)

lib/codegen.rs:185:21: 190:15 error: type `~[descriptor::FieldDescriptorProto]` does not implement any method in scope named `flat_map`
lib/codegen.rs:185             fields: proto_message.field.flat_map(|field| {
lib/codegen.rs:186                 match Field::parse(field, pkg) {
lib/codegen.rs:187                     Some(field) => ~[field],
lib/codegen.rs:188                     None => ~[]
lib/codegen.rs:189                 }
lib/codegen.rs:190             }),

example projects

Hi there,

Are there projects out there that use rust-protobuf ? The library usage is a bit hard to infer from just the compiled output.

Cheers!

  • pyr

namespace collision in generated rust code

If two submodules in protobuf contain the same local message name and they get imported into another module, they will clash in the generated rust code:

$ cat main.proto
import "subA.proto";
import "subB.proto";
$ cat subA.proto
package subA;
message Foo {}
$ cat subB.proto
package subB;
message Foo {}

leads to:

main.rs:13:5: 13:21 error: a type named `Foo` has already been imported in this module [E0252]
main.rs:13 use super::subB::Foo;
main.rs:12:1: 12:22 note: previous import of `Foo` here
main.rs:12 use super::subA::Foo;
use protobuf::Message as Message_imported_for_functions;
use protobuf::ProtobufEnum as ProtobufEnum_imported_for_functions;
use super::subA::Foo;
use super::subB::Foo;

Using the full qualified name instead of using the submodules would do the trick I guess.

type `&[u8]` does not implement any method in scope named `map`

./rebuild.sh fails with:

rustc 0.10-pre (e63b2d3 2014-03-30 21:11:40 -0700)

lib/hex.rs:45:6: 47:7 error: type `&[u8]` does not implement any method in scope named `map`
lib/hex.rs:45     (bytes.map(|byte| {
lib/hex.rs:46         str::from_chars(encode_hex_byte(*byte))
lib/hex.rs:47     })).connect(" ")

Negative protobuf field numbers cause task to panic

Steps to reproduce:

foo.proto:

message Bar {
  optional string name = 1;
}

main.rs:

extern crate protobuf;
use protobuf::core::parse_from_bytes;

mod foo;
use foo::Bar;

fn main() {
  let bar: Bar = parse_from_bytes(&[1, 2, 3]).ok().unwrap();
  println!("{:?}", bar);
}

Expected:

  • parse_from_bytes returns a Result with an Err(ProtobufError::WireError(...))

Actual:

  • The task panics:

    thread '<main>' panicked at 'field number must be positive', /home/dflemstr/.cargo/git/checkouts/rust-protobuf-ed1e2bca5258dbce/master/src/lib/stream.rs:86
    An unknown error occurred
    

Doesn't compile with 1.0.0 beta.

src/lib/protobuf.rs:2:1: 2:33 error: unstable feature
src/lib/protobuf.rs:2 #![feature(box_patterns, alloc)]
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
note: this feature may not be used in the beta release channel
src/lib/protobuf.rs:5:1: 5:25 error: unstable feature
src/lib/protobuf.rs:5 #![feature(collections)]
^~~~~~~~~~~~~~~~~~~~~~~~
note: this feature may not be used in the beta release channel
src/lib/protobuf.rs:6:1: 6:21 error: unstable feature
src/lib/protobuf.rs:6 #![feature(convert)]
^~~~~~~~~~~~~~~~~~~~
note: this feature may not be used in the beta release channel
src/lib/protobuf.rs:7:1: 7:18 error: unstable feature
src/lib/protobuf.rs:7 #![feature(core)]
^~~~~~~~~~~~~~~~~
note: this feature may not be used in the beta release channel
src/lib/protobuf.rs:8:1: 8:22 error: unstable feature
src/lib/protobuf.rs:8 #![feature(str_char)]
^~~~~~~~~~~~~~~~~~~~~
note: this feature may not be used in the beta release channel
error: aborting due to 5 previous errors
Could not compile protobuf.

Doesn't compile on 2014-12-15 nightly

src/lib/repeated.rs:214:29: 214:45 error: the trait `core::ops::Fn<(&T, &T), core::cmp::Ordering>` is not implemented for the type `|&T, &T| -> core::cmp::Ordering`
src/lib/repeated.rs:214         self.as_mut_slice().sort_by(compare)
                                                    ^~~~~~~~~~~~~~~~
src/lib/singular.rs:124:58: 124:64 error: the trait `core::ops::Fn<(T,), _>` is not implemented for the type `|T| -> U`
src/lib/singular.rs:124         SingularPtrField::from_option(self.into_option().map(f))
                                                                                 ^~~~~~
src/lib/singular.rs:291:58: 291:64 error: the trait `core::ops::Fn<(T,), _>` is not implemented for the type `|T| -> U`
src/lib/singular.rs:291         SingularPtrField::from_option(self.into_option().map(f))
                                                                                 ^~~~~~
src/lib/reflect/accessor.rs:359:5: 365:6 error: the parameter type `M` may not live long enough
src/lib/reflect/accessor.rs:359     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:360         name: name,
src/lib/reflect/accessor.rs:361         fns: FieldAccessorFunctions::Singular {
src/lib/reflect/accessor.rs:362             has: has,
src/lib/reflect/accessor.rs:363             get: SingularGet::U32(get),
src/lib/reflect/accessor.rs:364         },
                                ...
src/lib/reflect/accessor.rs:359:5: 365:6 help: consider adding an explicit lifetime bound `M: 'static`...
src/lib/reflect/accessor.rs:359     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:360         name: name,
src/lib/reflect/accessor.rs:361         fns: FieldAccessorFunctions::Singular {
src/lib/reflect/accessor.rs:362             has: has,
src/lib/reflect/accessor.rs:363             get: SingularGet::U32(get),
src/lib/reflect/accessor.rs:364         },
                                ...
src/lib/reflect/accessor.rs:359:5: 365:6 note: ...so that the declared lifetime parameter bounds are satisfied
src/lib/reflect/accessor.rs:359     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:360         name: name,
src/lib/reflect/accessor.rs:361         fns: FieldAccessorFunctions::Singular {
src/lib/reflect/accessor.rs:362             has: has,
src/lib/reflect/accessor.rs:363             get: SingularGet::U32(get),
src/lib/reflect/accessor.rs:364         },
                                ...
src/lib/reflect/accessor.rs:374:5: 380:6 error: the parameter type `M` may not live long enough
src/lib/reflect/accessor.rs:374     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:375         name: name,
src/lib/reflect/accessor.rs:376         fns: FieldAccessorFunctions::Singular {
src/lib/reflect/accessor.rs:377             has: has,
src/lib/reflect/accessor.rs:378             get: SingularGet::I32(get),
src/lib/reflect/accessor.rs:379         },
                                ...
src/lib/reflect/accessor.rs:374:5: 380:6 help: consider adding an explicit lifetime bound `M: 'static`...
src/lib/reflect/accessor.rs:374     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:375         name: name,
src/lib/reflect/accessor.rs:376         fns: FieldAccessorFunctions::Singular {
src/lib/reflect/accessor.rs:377             has: has,
src/lib/reflect/accessor.rs:378             get: SingularGet::I32(get),
src/lib/reflect/accessor.rs:379         },
                                ...
src/lib/reflect/accessor.rs:374:5: 380:6 note: ...so that the declared lifetime parameter bounds are satisfied
src/lib/reflect/accessor.rs:374     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:375         name: name,
src/lib/reflect/accessor.rs:376         fns: FieldAccessorFunctions::Singular {
src/lib/reflect/accessor.rs:377             has: has,
src/lib/reflect/accessor.rs:378             get: SingularGet::I32(get),
src/lib/reflect/accessor.rs:379         },
                                ...
src/lib/reflect/accessor.rs:389:5: 395:6 error: the parameter type `M` may not live long enough
src/lib/reflect/accessor.rs:389     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:390         name: name,
src/lib/reflect/accessor.rs:391         fns: FieldAccessorFunctions::Singular {
src/lib/reflect/accessor.rs:392             has: has,
src/lib/reflect/accessor.rs:393             get: SingularGet::U64(get),
src/lib/reflect/accessor.rs:394         },
                                ...
src/lib/reflect/accessor.rs:389:5: 395:6 help: consider adding an explicit lifetime bound `M: 'static`...
src/lib/reflect/accessor.rs:389     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:390         name: name,
src/lib/reflect/accessor.rs:391         fns: FieldAccessorFunctions::Singular {
src/lib/reflect/accessor.rs:392             has: has,
src/lib/reflect/accessor.rs:393             get: SingularGet::U64(get),
src/lib/reflect/accessor.rs:394         },
                                ...
src/lib/reflect/accessor.rs:389:5: 395:6 note: ...so that the declared lifetime parameter bounds are satisfied
src/lib/reflect/accessor.rs:389     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:390         name: name,
src/lib/reflect/accessor.rs:391         fns: FieldAccessorFunctions::Singular {
src/lib/reflect/accessor.rs:392             has: has,
src/lib/reflect/accessor.rs:393             get: SingularGet::U64(get),
src/lib/reflect/accessor.rs:394         },
                                ...
src/lib/reflect/accessor.rs:404:5: 410:6 error: the parameter type `M` may not live long enough
src/lib/reflect/accessor.rs:404     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:405         name: name,
src/lib/reflect/accessor.rs:406         fns: FieldAccessorFunctions::Singular {
src/lib/reflect/accessor.rs:407             has: has,
src/lib/reflect/accessor.rs:408             get: SingularGet::I64(get),
src/lib/reflect/accessor.rs:409         },
                                ...
src/lib/reflect/accessor.rs:404:5: 410:6 help: consider adding an explicit lifetime bound `M: 'static`...
src/lib/reflect/accessor.rs:404     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:405         name: name,
src/lib/reflect/accessor.rs:406         fns: FieldAccessorFunctions::Singular {
src/lib/reflect/accessor.rs:407             has: has,
src/lib/reflect/accessor.rs:408             get: SingularGet::I64(get),
src/lib/reflect/accessor.rs:409         },
                                ...
src/lib/reflect/accessor.rs:404:5: 410:6 note: ...so that the declared lifetime parameter bounds are satisfied
src/lib/reflect/accessor.rs:404     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:405         name: name,
src/lib/reflect/accessor.rs:406         fns: FieldAccessorFunctions::Singular {
src/lib/reflect/accessor.rs:407             has: has,
src/lib/reflect/accessor.rs:408             get: SingularGet::I64(get),
src/lib/reflect/accessor.rs:409         },
                                ...
src/lib/reflect/accessor.rs:419:5: 425:6 error: the parameter type `M` may not live long enough
src/lib/reflect/accessor.rs:419     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:420         name: name,
src/lib/reflect/accessor.rs:421         fns: FieldAccessorFunctions::Singular {
src/lib/reflect/accessor.rs:422             has: has,
src/lib/reflect/accessor.rs:423             get: SingularGet::F32(get),
src/lib/reflect/accessor.rs:424         },
                                ...
src/lib/reflect/accessor.rs:419:5: 425:6 help: consider adding an explicit lifetime bound `M: 'static`...
src/lib/reflect/accessor.rs:419     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:420         name: name,
src/lib/reflect/accessor.rs:421         fns: FieldAccessorFunctions::Singular {
src/lib/reflect/accessor.rs:422             has: has,
src/lib/reflect/accessor.rs:423             get: SingularGet::F32(get),
src/lib/reflect/accessor.rs:424         },
                                ...
src/lib/reflect/accessor.rs:419:5: 425:6 note: ...so that the declared lifetime parameter bounds are satisfied
src/lib/reflect/accessor.rs:419     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:420         name: name,
src/lib/reflect/accessor.rs:421         fns: FieldAccessorFunctions::Singular {
src/lib/reflect/accessor.rs:422             has: has,
src/lib/reflect/accessor.rs:423             get: SingularGet::F32(get),
src/lib/reflect/accessor.rs:424         },
                                ...
src/lib/reflect/accessor.rs:434:5: 440:6 error: the parameter type `M` may not live long enough
src/lib/reflect/accessor.rs:434     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:435         name: name,
src/lib/reflect/accessor.rs:436         fns: FieldAccessorFunctions::Singular {
src/lib/reflect/accessor.rs:437             has: has,
src/lib/reflect/accessor.rs:438             get: SingularGet::F64(get),
src/lib/reflect/accessor.rs:439         },
                                ...
src/lib/reflect/accessor.rs:434:5: 440:6 help: consider adding an explicit lifetime bound `M: 'static`...
src/lib/reflect/accessor.rs:434     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:435         name: name,
src/lib/reflect/accessor.rs:436         fns: FieldAccessorFunctions::Singular {
src/lib/reflect/accessor.rs:437             has: has,
src/lib/reflect/accessor.rs:438             get: SingularGet::F64(get),
src/lib/reflect/accessor.rs:439         },
                                ...
src/lib/reflect/accessor.rs:434:5: 440:6 note: ...so that the declared lifetime parameter bounds are satisfied
src/lib/reflect/accessor.rs:434     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:435         name: name,
src/lib/reflect/accessor.rs:436         fns: FieldAccessorFunctions::Singular {
src/lib/reflect/accessor.rs:437             has: has,
src/lib/reflect/accessor.rs:438             get: SingularGet::F64(get),
src/lib/reflect/accessor.rs:439         },
                                ...
src/lib/reflect/accessor.rs:449:5: 455:6 error: the parameter type `M` may not live long enough
src/lib/reflect/accessor.rs:449     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:450         name: name,
src/lib/reflect/accessor.rs:451         fns: FieldAccessorFunctions::Singular {
src/lib/reflect/accessor.rs:452             has: has,
src/lib/reflect/accessor.rs:453             get: SingularGet::Bool(get),
src/lib/reflect/accessor.rs:454         },
                                ...
src/lib/reflect/accessor.rs:449:5: 455:6 help: consider adding an explicit lifetime bound `M: 'static`...
src/lib/reflect/accessor.rs:449     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:450         name: name,
src/lib/reflect/accessor.rs:451         fns: FieldAccessorFunctions::Singular {
src/lib/reflect/accessor.rs:452             has: has,
src/lib/reflect/accessor.rs:453             get: SingularGet::Bool(get),
src/lib/reflect/accessor.rs:454         },
                                ...
src/lib/reflect/accessor.rs:449:5: 455:6 note: ...so that the declared lifetime parameter bounds are satisfied
src/lib/reflect/accessor.rs:449     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:450         name: name,
src/lib/reflect/accessor.rs:451         fns: FieldAccessorFunctions::Singular {
src/lib/reflect/accessor.rs:452             has: has,
src/lib/reflect/accessor.rs:453             get: SingularGet::Bool(get),
src/lib/reflect/accessor.rs:454         },
                                ...
src/lib/reflect/accessor.rs:464:5: 470:6 error: the parameter type `M` may not live long enough
src/lib/reflect/accessor.rs:464     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:465         name: name,
src/lib/reflect/accessor.rs:466         fns: FieldAccessorFunctions::Singular {
src/lib/reflect/accessor.rs:467             has: has,
src/lib/reflect/accessor.rs:468             get: SingularGet::String(get),
src/lib/reflect/accessor.rs:469         },
                                ...
src/lib/reflect/accessor.rs:464:5: 470:6 help: consider adding an explicit lifetime bound `M: 'static`...
src/lib/reflect/accessor.rs:464     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:465         name: name,
src/lib/reflect/accessor.rs:466         fns: FieldAccessorFunctions::Singular {
src/lib/reflect/accessor.rs:467             has: has,
src/lib/reflect/accessor.rs:468             get: SingularGet::String(get),
src/lib/reflect/accessor.rs:469         },
                                ...
src/lib/reflect/accessor.rs:464:5: 470:6 note: ...so that the declared lifetime parameter bounds are satisfied
src/lib/reflect/accessor.rs:464     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:465         name: name,
src/lib/reflect/accessor.rs:466         fns: FieldAccessorFunctions::Singular {
src/lib/reflect/accessor.rs:467             has: has,
src/lib/reflect/accessor.rs:468             get: SingularGet::String(get),
src/lib/reflect/accessor.rs:469         },
                                ...
src/lib/reflect/accessor.rs:479:5: 485:6 error: the parameter type `M` may not live long enough
src/lib/reflect/accessor.rs:479     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:480         name: name,
src/lib/reflect/accessor.rs:481         fns: FieldAccessorFunctions::Singular {
src/lib/reflect/accessor.rs:482             has: has,
src/lib/reflect/accessor.rs:483             get: SingularGet::Bytes(get),
src/lib/reflect/accessor.rs:484         },
                                ...
src/lib/reflect/accessor.rs:479:5: 485:6 help: consider adding an explicit lifetime bound `M: 'static`...
src/lib/reflect/accessor.rs:479     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:480         name: name,
src/lib/reflect/accessor.rs:481         fns: FieldAccessorFunctions::Singular {
src/lib/reflect/accessor.rs:482             has: has,
src/lib/reflect/accessor.rs:483             get: SingularGet::Bytes(get),
src/lib/reflect/accessor.rs:484         },
                                ...
src/lib/reflect/accessor.rs:479:5: 485:6 note: ...so that the declared lifetime parameter bounds are satisfied
src/lib/reflect/accessor.rs:479     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:480         name: name,
src/lib/reflect/accessor.rs:481         fns: FieldAccessorFunctions::Singular {
src/lib/reflect/accessor.rs:482             has: has,
src/lib/reflect/accessor.rs:483             get: SingularGet::Bytes(get),
src/lib/reflect/accessor.rs:484         },
                                ...
src/lib/reflect/accessor.rs:494:5: 502:6 error: the parameter type `M` may not live long enough
src/lib/reflect/accessor.rs:494     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:495         name: name,
src/lib/reflect/accessor.rs:496         fns: FieldAccessorFunctions::Singular {
src/lib/reflect/accessor.rs:497             has: has,
src/lib/reflect/accessor.rs:498             get: SingularGet::Enum(
src/lib/reflect/accessor.rs:499                 box GetSingularEnumImpl { get: get },
                                ...
src/lib/reflect/accessor.rs:494:5: 502:6 help: consider adding an explicit lifetime bound `M: 'static`...
src/lib/reflect/accessor.rs:494     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:495         name: name,
src/lib/reflect/accessor.rs:496         fns: FieldAccessorFunctions::Singular {
src/lib/reflect/accessor.rs:497             has: has,
src/lib/reflect/accessor.rs:498             get: SingularGet::Enum(
src/lib/reflect/accessor.rs:499                 box GetSingularEnumImpl { get: get },
                                ...
src/lib/reflect/accessor.rs:494:5: 502:6 note: ...so that the declared lifetime parameter bounds are satisfied
src/lib/reflect/accessor.rs:494     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:495         name: name,
src/lib/reflect/accessor.rs:496         fns: FieldAccessorFunctions::Singular {
src/lib/reflect/accessor.rs:497             has: has,
src/lib/reflect/accessor.rs:498             get: SingularGet::Enum(
src/lib/reflect/accessor.rs:499                 box GetSingularEnumImpl { get: get },
                                ...
src/lib/reflect/accessor.rs:511:5: 519:6 error: the parameter type `M` may not live long enough
src/lib/reflect/accessor.rs:511     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:512         name: name,
src/lib/reflect/accessor.rs:513         fns: FieldAccessorFunctions::Singular {
src/lib/reflect/accessor.rs:514             has: has,
src/lib/reflect/accessor.rs:515             get: SingularGet::Message(
src/lib/reflect/accessor.rs:516                 box GetSingularMessageImpl { get: get },
                                ...
src/lib/reflect/accessor.rs:511:5: 519:6 help: consider adding an explicit lifetime bound `M: 'static`...
src/lib/reflect/accessor.rs:511     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:512         name: name,
src/lib/reflect/accessor.rs:513         fns: FieldAccessorFunctions::Singular {
src/lib/reflect/accessor.rs:514             has: has,
src/lib/reflect/accessor.rs:515             get: SingularGet::Message(
src/lib/reflect/accessor.rs:516                 box GetSingularMessageImpl { get: get },
                                ...
src/lib/reflect/accessor.rs:511:5: 519:6 note: ...so that the declared lifetime parameter bounds are satisfied
src/lib/reflect/accessor.rs:511     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:512         name: name,
src/lib/reflect/accessor.rs:513         fns: FieldAccessorFunctions::Singular {
src/lib/reflect/accessor.rs:514             has: has,
src/lib/reflect/accessor.rs:515             get: SingularGet::Message(
src/lib/reflect/accessor.rs:516                 box GetSingularMessageImpl { get: get },
                                ...
src/lib/reflect/accessor.rs:529:5: 532:6 error: the parameter type `M` may not live long enough
src/lib/reflect/accessor.rs:529     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:530         name: name,
src/lib/reflect/accessor.rs:531         fns: FieldAccessorFunctions::Repeated(RepeatedGet::U32(get)),
src/lib/reflect/accessor.rs:532     }
src/lib/reflect/accessor.rs:529:5: 532:6 help: consider adding an explicit lifetime bound `M: 'static`...
src/lib/reflect/accessor.rs:529     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:530         name: name,
src/lib/reflect/accessor.rs:531         fns: FieldAccessorFunctions::Repeated(RepeatedGet::U32(get)),
src/lib/reflect/accessor.rs:532     }
src/lib/reflect/accessor.rs:529:5: 532:6 note: ...so that the declared lifetime parameter bounds are satisfied
src/lib/reflect/accessor.rs:529     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:530         name: name,
src/lib/reflect/accessor.rs:531         fns: FieldAccessorFunctions::Repeated(RepeatedGet::U32(get)),
src/lib/reflect/accessor.rs:532     }
src/lib/reflect/accessor.rs:540:5: 543:6 error: the parameter type `M` may not live long enough
src/lib/reflect/accessor.rs:540     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:541         name: name,
src/lib/reflect/accessor.rs:542         fns: FieldAccessorFunctions::Repeated(RepeatedGet::I32(get)),
src/lib/reflect/accessor.rs:543     }
src/lib/reflect/accessor.rs:540:5: 543:6 help: consider adding an explicit lifetime bound `M: 'static`...
src/lib/reflect/accessor.rs:540     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:541         name: name,
src/lib/reflect/accessor.rs:542         fns: FieldAccessorFunctions::Repeated(RepeatedGet::I32(get)),
src/lib/reflect/accessor.rs:543     }
src/lib/reflect/accessor.rs:540:5: 543:6 note: ...so that the declared lifetime parameter bounds are satisfied
src/lib/reflect/accessor.rs:540     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:541         name: name,
src/lib/reflect/accessor.rs:542         fns: FieldAccessorFunctions::Repeated(RepeatedGet::I32(get)),
src/lib/reflect/accessor.rs:543     }
src/lib/reflect/accessor.rs:551:5: 554:6 error: the parameter type `M` may not live long enough
src/lib/reflect/accessor.rs:551     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:552         name: name,
src/lib/reflect/accessor.rs:553         fns: FieldAccessorFunctions::Repeated(RepeatedGet::U64(get)),
src/lib/reflect/accessor.rs:554     }
src/lib/reflect/accessor.rs:551:5: 554:6 help: consider adding an explicit lifetime bound `M: 'static`...
src/lib/reflect/accessor.rs:551     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:552         name: name,
src/lib/reflect/accessor.rs:553         fns: FieldAccessorFunctions::Repeated(RepeatedGet::U64(get)),
src/lib/reflect/accessor.rs:554     }
src/lib/reflect/accessor.rs:551:5: 554:6 note: ...so that the declared lifetime parameter bounds are satisfied
src/lib/reflect/accessor.rs:551     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:552         name: name,
src/lib/reflect/accessor.rs:553         fns: FieldAccessorFunctions::Repeated(RepeatedGet::U64(get)),
src/lib/reflect/accessor.rs:554     }
src/lib/reflect/accessor.rs:562:5: 565:6 error: the parameter type `M` may not live long enough
src/lib/reflect/accessor.rs:562     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:563         name: name,
src/lib/reflect/accessor.rs:564         fns: FieldAccessorFunctions::Repeated(RepeatedGet::I64(get)),
src/lib/reflect/accessor.rs:565     }
src/lib/reflect/accessor.rs:562:5: 565:6 help: consider adding an explicit lifetime bound `M: 'static`...
src/lib/reflect/accessor.rs:562     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:563         name: name,
src/lib/reflect/accessor.rs:564         fns: FieldAccessorFunctions::Repeated(RepeatedGet::I64(get)),
src/lib/reflect/accessor.rs:565     }
src/lib/reflect/accessor.rs:562:5: 565:6 note: ...so that the declared lifetime parameter bounds are satisfied
src/lib/reflect/accessor.rs:562     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:563         name: name,
src/lib/reflect/accessor.rs:564         fns: FieldAccessorFunctions::Repeated(RepeatedGet::I64(get)),
src/lib/reflect/accessor.rs:565     }
src/lib/reflect/accessor.rs:573:5: 576:6 error: the parameter type `M` may not live long enough
src/lib/reflect/accessor.rs:573     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:574         name: name,
src/lib/reflect/accessor.rs:575         fns: FieldAccessorFunctions::Repeated(RepeatedGet::F32(get)),
src/lib/reflect/accessor.rs:576     }
src/lib/reflect/accessor.rs:573:5: 576:6 help: consider adding an explicit lifetime bound `M: 'static`...
src/lib/reflect/accessor.rs:573     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:574         name: name,
src/lib/reflect/accessor.rs:575         fns: FieldAccessorFunctions::Repeated(RepeatedGet::F32(get)),
src/lib/reflect/accessor.rs:576     }
src/lib/reflect/accessor.rs:573:5: 576:6 note: ...so that the declared lifetime parameter bounds are satisfied
src/lib/reflect/accessor.rs:573     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:574         name: name,
src/lib/reflect/accessor.rs:575         fns: FieldAccessorFunctions::Repeated(RepeatedGet::F32(get)),
src/lib/reflect/accessor.rs:576     }
src/lib/reflect/accessor.rs:584:5: 587:6 error: the parameter type `M` may not live long enough
src/lib/reflect/accessor.rs:584     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:585         name: name,
src/lib/reflect/accessor.rs:586         fns: FieldAccessorFunctions::Repeated(RepeatedGet::F64(get)),
src/lib/reflect/accessor.rs:587     }
src/lib/reflect/accessor.rs:584:5: 587:6 help: consider adding an explicit lifetime bound `M: 'static`...
src/lib/reflect/accessor.rs:584     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:585         name: name,
src/lib/reflect/accessor.rs:586         fns: FieldAccessorFunctions::Repeated(RepeatedGet::F64(get)),
src/lib/reflect/accessor.rs:587     }
src/lib/reflect/accessor.rs:584:5: 587:6 note: ...so that the declared lifetime parameter bounds are satisfied
src/lib/reflect/accessor.rs:584     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:585         name: name,
src/lib/reflect/accessor.rs:586         fns: FieldAccessorFunctions::Repeated(RepeatedGet::F64(get)),
src/lib/reflect/accessor.rs:587     }
src/lib/reflect/accessor.rs:595:5: 598:6 error: the parameter type `M` may not live long enough
src/lib/reflect/accessor.rs:595     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:596         name: name,
src/lib/reflect/accessor.rs:597         fns: FieldAccessorFunctions::Repeated(RepeatedGet::Bool(get)),
src/lib/reflect/accessor.rs:598     }
src/lib/reflect/accessor.rs:595:5: 598:6 help: consider adding an explicit lifetime bound `M: 'static`...
src/lib/reflect/accessor.rs:595     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:596         name: name,
src/lib/reflect/accessor.rs:597         fns: FieldAccessorFunctions::Repeated(RepeatedGet::Bool(get)),
src/lib/reflect/accessor.rs:598     }
src/lib/reflect/accessor.rs:595:5: 598:6 note: ...so that the declared lifetime parameter bounds are satisfied
src/lib/reflect/accessor.rs:595     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:596         name: name,
src/lib/reflect/accessor.rs:597         fns: FieldAccessorFunctions::Repeated(RepeatedGet::Bool(get)),
src/lib/reflect/accessor.rs:598     }
src/lib/reflect/accessor.rs:606:5: 609:6 error: the parameter type `M` may not live long enough
src/lib/reflect/accessor.rs:606     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:607         name: name,
src/lib/reflect/accessor.rs:608         fns: FieldAccessorFunctions::Repeated(RepeatedGet::String(get)),
src/lib/reflect/accessor.rs:609     }
src/lib/reflect/accessor.rs:606:5: 609:6 help: consider adding an explicit lifetime bound `M: 'static`...
src/lib/reflect/accessor.rs:606     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:607         name: name,
src/lib/reflect/accessor.rs:608         fns: FieldAccessorFunctions::Repeated(RepeatedGet::String(get)),
src/lib/reflect/accessor.rs:609     }
src/lib/reflect/accessor.rs:606:5: 609:6 note: ...so that the declared lifetime parameter bounds are satisfied
src/lib/reflect/accessor.rs:606     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:607         name: name,
src/lib/reflect/accessor.rs:608         fns: FieldAccessorFunctions::Repeated(RepeatedGet::String(get)),
src/lib/reflect/accessor.rs:609     }
src/lib/reflect/accessor.rs:617:5: 620:6 error: the parameter type `M` may not live long enough
src/lib/reflect/accessor.rs:617     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:618         name: name,
src/lib/reflect/accessor.rs:619         fns: FieldAccessorFunctions::Repeated(RepeatedGet::Bytes(get)),
src/lib/reflect/accessor.rs:620     }
src/lib/reflect/accessor.rs:617:5: 620:6 help: consider adding an explicit lifetime bound `M: 'static`...
src/lib/reflect/accessor.rs:617     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:618         name: name,
src/lib/reflect/accessor.rs:619         fns: FieldAccessorFunctions::Repeated(RepeatedGet::Bytes(get)),
src/lib/reflect/accessor.rs:620     }
src/lib/reflect/accessor.rs:617:5: 620:6 note: ...so that the declared lifetime parameter bounds are satisfied
src/lib/reflect/accessor.rs:617     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:618         name: name,
src/lib/reflect/accessor.rs:619         fns: FieldAccessorFunctions::Repeated(RepeatedGet::Bytes(get)),
src/lib/reflect/accessor.rs:620     }
src/lib/reflect/accessor.rs:628:5: 633:6 error: the parameter type `M` may not live long enough
src/lib/reflect/accessor.rs:628     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:629         name: name,
src/lib/reflect/accessor.rs:630         fns: FieldAccessorFunctions::Repeated(RepeatedGet::Enum(
src/lib/reflect/accessor.rs:631             box GetRepeatedEnumImpl { get: get },
src/lib/reflect/accessor.rs:632         )),
src/lib/reflect/accessor.rs:633     }
src/lib/reflect/accessor.rs:628:5: 633:6 help: consider adding an explicit lifetime bound `M: 'static`...
src/lib/reflect/accessor.rs:628     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:629         name: name,
src/lib/reflect/accessor.rs:630         fns: FieldAccessorFunctions::Repeated(RepeatedGet::Enum(
src/lib/reflect/accessor.rs:631             box GetRepeatedEnumImpl { get: get },
src/lib/reflect/accessor.rs:632         )),
src/lib/reflect/accessor.rs:633     }
src/lib/reflect/accessor.rs:628:5: 633:6 note: ...so that the declared lifetime parameter bounds are satisfied
src/lib/reflect/accessor.rs:628     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:629         name: name,
src/lib/reflect/accessor.rs:630         fns: FieldAccessorFunctions::Repeated(RepeatedGet::Enum(
src/lib/reflect/accessor.rs:631             box GetRepeatedEnumImpl { get: get },
src/lib/reflect/accessor.rs:632         )),
src/lib/reflect/accessor.rs:633     }
src/lib/reflect/accessor.rs:641:5: 646:6 error: the parameter type `M` may not live long enough
src/lib/reflect/accessor.rs:641     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:642         name: name,
src/lib/reflect/accessor.rs:643         fns: FieldAccessorFunctions::Repeated(RepeatedGet::Message(
src/lib/reflect/accessor.rs:644             box GetRepeatedMessageImpl { get: get },
src/lib/reflect/accessor.rs:645         )),
src/lib/reflect/accessor.rs:646     }
src/lib/reflect/accessor.rs:641:5: 646:6 help: consider adding an explicit lifetime bound `M: 'static`...
src/lib/reflect/accessor.rs:641     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:642         name: name,
src/lib/reflect/accessor.rs:643         fns: FieldAccessorFunctions::Repeated(RepeatedGet::Message(
src/lib/reflect/accessor.rs:644             box GetRepeatedMessageImpl { get: get },
src/lib/reflect/accessor.rs:645         )),
src/lib/reflect/accessor.rs:646     }
src/lib/reflect/accessor.rs:641:5: 646:6 note: ...so that the declared lifetime parameter bounds are satisfied
src/lib/reflect/accessor.rs:641     box FieldAccessorImpl {
src/lib/reflect/accessor.rs:642         name: name,
src/lib/reflect/accessor.rs:643         fns: FieldAccessorFunctions::Repeated(RepeatedGet::Message(
src/lib/reflect/accessor.rs:644             box GetRepeatedMessageImpl { get: get },
src/lib/reflect/accessor.rs:645         )),
src/lib/reflect/accessor.rs:646     }

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.