This could be tidied up significantly, and at some point we will want to parse the markdown and generate more appropriate XML - but this is definitely better than nothing.
Generated code changes coming in next commit.
There are now summaries for:
- The Types nested class (which holds nested types)
- The file descriptor class for each proto
- The enum generated for each oneof
(Also fixed two typos.)
Generated code in next commit.
We still need the JSON representation, which relies on something like a DescriptorPool to fetch message types from based on the type URL. That will come a bit later.
(The DescriptorPool comment in this commit is just a note which will prove useful if we use DescriptorPool itself.)
Xcode raises warning that says "'BYTE_SIZE' macro redefined".
The original 'BYTE_SIZE' macro definition is here, for example:
'/Applications/Xcode/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/mach/vm_param.h'
This introduces a new C# option, base_namespace.
If the option is not specified, the behaviour is as before: no directories are generated.
If the option *is* specified, all C# namespaces must be relative to the base namespace, and the directories are generated relative to that namespace.
Example:
- Any.proto declares csharp_namespace = "Google.Protobuf.WellKnownTypes"
- We build with --csharp_out=Google.Protobuf --csharp_opt=base_namespace=Google.Protobuf
- The Any.cs file is generated in Google.Protobuf/WellKnownTypes (where it currently lives)
We need a change to descriptor.proto before this will all work (it wasn't in the right C# namespace) but that needs the other descriptors to be regenerated too. See next commit...
Fixes the ScalarMapContainer/MessageMapContainer implementations on
Python 3.4, by dynamically allocating their PyTypeObjects using
PyType_FromSpecWithBases, instead of statically allocating them. This is
necessary because Python 3.4+ disallows statically allocating a class
with a dynamically allocated parent.
Signed-off-by: Dan O'Reilly <oreilldf@gmail.com>
When the user passed in a block which was smaller than the Block
structure, this code would blow past the end of the memory and
crash. Check for that condition.
These are banned by the Google style guide, and Chromium has a hard
no-new-static-initializers policy preventing updating to a new version of
libprotobuf unless this is resolved. This is the first such change, I'll need
to make at least one more in the future.
Luckily, the protobuf source tree already has an alternative to static
initializers in once.h; use that machinery instead.
I defined everything in the .cc file in a blob to replace the old implementation
rather than matching the .h layout precisely; let me know if a different
ordering is preferred. I also eliminated the macro that used to be used here as
spelling everything out only takes one additional line, and the macro didn't
actually handle all details of using a particular member variable, just the
declaration, so it felt a bit error-prone.
It's not enough to check for C++11 language support, as it's possible for
projects to enable C++11 language and library features independently (e.g.
Chromium currently does this). Instead, explicitly check the library version to
see if it is recent enough to include unordered_{map|set}.
Jon Skeet
Jon Skeet
Paul Yang
Joshua Haberman
Jorge Canizales
Feng Xiao
Jan Tattermusch
0xAAE
Brian Silverman
Jisi Liu
Jisi Liu
kbinani
Dan O'Reilly
Feng Xiao
Austin Schuh
Peter Kasting