Re: [protobuf] Protobuf v3.12.0-rc1 is released

The need for non-empty oneof came up in conversations with users. The other evidence for this being a real user need is that PGV has a validator for non-empty oneofs in their code gen, so it wouldn't be unreasonable if someone implemented

Re: [protobuf] Re: Discrepancy in generated code of unsafe_arena_release_foo

As a related issue, I remember reading some comments in protobuf source code that says google internal protobuf supports arena allocation that's not portable (probably assumes certain std::string implementation), thus it is not open sourced, what's the plan for string arena allocation support?

Re: [protobuf] Re: Discrepancy in generated code of unsafe_arena_release_foo

On Tue, May 5, 2020 at 4:20 PM King Kong wrote: > Thanks for your reply. > > Yes, I have been using arena, but I wanted to do better than batching heap > allocation, when possible. The "scoped leasing" use case I described above > achieve 0 heap allocation all the time. I guess my code could use

Re: [protobuf] Protobuf v3.12.0-rc1 is released

On Tue, May 5, 2020 at 6:24 PM Nadav Samet wrote: > What representations do you mean? In general it is not expected that oneof >> names are exposed in wire formats. Authors of .proto files are free to >> change them at will without breaking the wire. >> > > An example would be code that produces

[protobuf] Re: Discrepancy in generated code of unsafe_arena_release_foo

I could be wrong, but it seems to arena checking is only done for std::string in generated unsafe_arena_* code. I wonder if it is because google internal version of protobuf has arena support for std::string, thus the special treatment. On Tuesday, May 5, 2020 at 5:09:01 PM UTC-7, King Kong

Re: [protobuf] Protobuf v3.12.0-rc1 is released

> > What representations do you mean? In general it is not expected that oneof > names are exposed in wire formats. Authors of .proto files are free to > change them at will without breaking the wire. > An example would be code that produces an alternative JSON representation that groups all the

Re: [protobuf] Protobuf v3.12.0-rc1 is released

Hi Nadav, On Tue, May 5, 2020 at 5:25 PM Nadav Samet wrote: > Hi Josh, thanks for the heads up on the upcoming change needed by source > code generators. > > At first sight, the implementation detail around > synthetic/real oneofs seems like a clever hack to avoid breaking some code > that uses

Re: [protobuf] Protobuf v3.12.0-rc1 is released

Hi Josh, thanks for the heads up on the upcoming change needed by source code generators. At first sight, the implementation detail around synthetic/real oneofs seems like a clever hack to avoid breaking some code that uses reflection, but the consequence would be that: 1. some code that does

[protobuf] Re: Discrepancy in generated code of unsafe_arena_release_foo

Thanks for your reply. Yes, I have been using arena, but I wanted to do better than batching heap allocation, when possible. The "scoped leasing" use case I described above achieve 0 heap allocation all the time. I guess my code could use GetArena() at runtime to decide how the "leasing"

[protobuf] Re: Discrepancy in generated code of unsafe_arena_release_foo

The documentation for unsafe_arena_release_foo() says: > This method should only be used when the parent message is on the arena and the submessage is on the same arena, or an arena with equivalent lifetime. The DCHECK() you highlighted is checking the first part of this requirement.

[protobuf] Protobuf v3.12.0-rc1 is released

I have released Protobuf v3.12.0-rc1 to GitHub and the per-language repositories (NuGet, npm, RubyGems, etc). https://github.com/protocolbuffers/protobuf/releases/tag/v3.12.0-rc1 Please try it out and let us know if you have any issues. The full 3.12.0 release should follow within a week or

[protobuf] Discrepancy in generated code of unsafe_arena_release_foo

I am using unsafe_arena_set_allocated_* and unsafe_arena_release_* APIs to avoid unnecessary allocations when the sub-objects are only used in a function scope, unsafe_arena_release_* is always called before leaving the scope. At the beginning, I chose to always use the arena versions of