This addresses issue #1008, by creating a JsonFormatter which is private and only different
to JsonFormatter.Default in terms of reference equality.
Other plausible designs:
- The same, but expose the diagnostic-only formatter
- Add something to settings to say "I don't have a type registry at all"
- Change the behaviour of JsonFormatter.Default (bad idea IMO, as we really *don't* want the result of this used as regular JSON to be parsed)
Note that just trying to find a separate fix to issue #933 and using that to override Any.ToString() differently wouldn't work for messages that *contain* an Any.
Generated code changes follow in the next commit.
This is adapted from the branch of @xfxyjwf at:
494716a682
and should solve the protobuf compilation problem against nvcc.
Tested against nvcc 6.5 and 7.0.
There are corner cases where MessageDescriptor.{ClrType,Parser} will return null, and these are now documented. However, normally they *should* be implemented, even for descriptors of for dynamic messages. Ditto FieldDescriptor.Accessor.
We'll still need a fair amount of work to implement dynamic messages, but this change means that the public API will be remain intact.
Additionally, this change starts making use of C# 6 features in the files that it touches. This is far from exhaustive, and later PRs will have more.
Generated code changes coming in the next commit.
Generated code coming in next commit - in a subsequent PR I want to do a bit of renaming and redocumenting around this, in anticipation of DynamicMessage.
In the old flow, any 2 char prefix in the expected file was still generating a
warning about being a poor prefix. Now we check the expected file first, so
anything expected is let through.
Instead of having a Proto nested namespace to avoid conflicts between the descriptor-holding static class and message classes, just append "Reflection" to the name.
Generated code changes (and corresponding manual changes) in following commit.
1. mathlimits.h must be included before the inclusion of cmath (which
gtest/gtest.h seems to include).
2. hash function for StringPiece doesn't work.
Change-Id: I358a25d941a25b10b39fe76780eda41557699811
VC++ up to VS 2015 RTM does not require explicit storage allocation for
static const integers declared in classes. VS 2015 Update 1 requires
these storage definitions in some cases. It's unclear exactly what
cases - simple tests work with and without the explicit storage
allocation.
Many previous versions of VC++ have theoretically *allowed* a
definition to supply storage, but tests on VC++ 2013 show that this
doesn't actually work correctly - it leads to duplicate definition
errors in Chromium. So, the change is scoped to VS 2015 only.
This change also updates the generated files to match the new generator.
TL;DR - this change is necessary in order for Chromium to build with
VS 2015 Update 1.
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.
This was originally submitted as a patch on the Google Code issue
tracker, but the original author didn't submit a pull request. They did,
however, give permission for somebody else to do so. I cleaned up a few
things myself and am now submitting it.
I can't find any record of what the original patch was, but there is a
copy of the discussion at
<https://groups.google.com/forum/#!topic/protobuf/SMwF5fYHIi0>.
Fixesgoogle/protobuf#581
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...
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}.
This came up because Chromium downstream modifies the lite library in a way that
requires this function, but I'm upstreaming it because based on the comments in
repeated_field.h, this ought to allow resolution of an existing hack.
I don't know enough about the protobuf code to feel confident trying to resolve
this hack myself, so I've merely updated the TODO comments.
When trying to compile the protobuf code as a DLL, and then compile other DLLs
with generated .pb.cc/h files that reference
InternalMetadataWithArena::InternalMetadataWithArena(Arena*), MSVC gives an
"unresolved external symbol" error. This seems to be due to the function being
simultaneously exported and inline. Moving it out-of-line fixes things.
There are other functions exported and inline as well but de-inlining them
doesn't seem to be necessary to get the build working, and I'd rather de-inline
as few functions as possible.
port.h #includes various headers in order to define byteswap functions, but it
currently does so from inside the google::protobuf namespace. This can cause
bizarre symbol conflicts and other build errors as these headers' contents are
then included inside this namespace.
Instead, #include the relevant headers above the namespace declarations.
Updating to the current protobuf version caused the following build errors in
Chromium when using Clang on Windows:
..\..\third_party\protobuf\src\google/protobuf/stubs/fastmem.h(67,43) : error: equality comparison with extraneous parentheses [-Werror,-Wparentheses-equality]
if (GOOGLE_PREDICT_FALSE(n_rounded_down == 0)) { // n <= 7
~~~~~~~~~~~~~~~^~~~
The problem is that on Windows, GOOGLE_PREDICT_FALSE is #defined to nothing, so
the code expands to 'if ((n_rounded_down == 0))', which Clang warns about.
Clang would not have warned if the extra parentheses came from the macro,
but in this case they don't because the macro is just dropped.
Fix this by making the macros behave as an identity function instead of just
getting dropped.
This is closer to what these macros look like in stubs/port.h internally.
This compiles with -std=c++11:
message Foo {
map<string, Foo> value = 1;
}
This does not compile:
message Foo {
map<int32, Foo> value = 1;
}
Needs to dig more into the underlying issue.
The internal down-integrate script probably does not handle the
top level macros well. Moved the macro inside of the namespace
declrations to avoid down-integrate errors in the future.
Change-Id: I3790357f36b0204a2a26577805192a3a1e989df8
We now do this in protoc instead of the generation simpler.
Benefits:
- Generation script is simpler
- Detection is simpler as we now only need to care about one filename
- The embedded descriptor knows itself as "google/protobuf/descriptor.proto" avoiding dependency issues
This PR also makes the "invalid dependency" exception clearer in terms of expected and actual dependencies.
See issue #240 - MSVC in VS2015 seems to inline a function it shouldn't. My original workaround was to disable inlining for the whole file, but I found a way to do it on just this specific function using __declspec(noinline).
Unfortunately __declspec has to go at the start of the function declaration, while __attribute in GCC can go either before or after. I had to move lots of GOOGLE_ATTRIBUTE_NOLINE to make it compile. I have not yet tested this change with GCC.
Will there be other side effects of defining this, given it wasn't previously?
I also noticed a few functions marked with both the 'inline' keyword, and GOOGLE_ATTRIBUTE_NOINLINE - huh? Is there an explanation for this, or is it an oversight?
- Add a env var to pass a set of expected prefixes for validation.
- Report warnings/errors based on the expected prefixes vs. the data in the files compiled.
- Use some helpers from common directory.
With this in place, generating APIs on github.com/google/googleapis works - previously annotations.proto failed.
Currently there's no access to the annotations (stored as extensions) but we could potentially expose those at a later date.
Now the generated code doesn't need to check for end group tags, as it will skip whole groups at a time.
Currently it will ignore extraneous end group tags, which may or may not be a good thing.
Renamed ConsumeLastField to SkipLastField as it felt more natural.
Removed WireFormat.IsEndGroupTag as it's no longer useful.
This mostly fixes issue 688.
(Generated code changes coming in next commit.)
This is a follow up CL for e9abc404df,
which breaks build when UNICODE macro is defined.
protoc has explicitly called MBCS version of APIs / funcsions
rather than UTF-16 (wchar_t) version of them regardless of
UNICODE macro definition (and it indeed works as expected).
Hence it makes sense to call GetModuleFileNameA explicitly.
The issue occurs when the template type deduction results in NodeType
being const.
Shortened version of compile error:
no matching function for call to 'operator new'
new (p) NodeType(std::forward<Args>(args)...);
candidate function not viable: no known conversion from 'const
std::__1::basic_string<char, std::__1::char_traits<char>,
std::__1::allocator<char> > *' to 'void *' for 2nd argument; take the
address of the argument with &
inline __attribute__ ((__visibility__("hidden"), __always_inline__))
void* operator new (std::size_t, void* __p) noexcept {return __p;}
