Different fields from different messages can map to the same JSON name
and the original global lookup table is only capable of mapping one of
such fields. This change converts the global table to per-type tables
so fields from different messages won't conflict.
This commit adds a __wrap_memcpy function and a linker flag to use that
in place of memcpy for our Ruby gem C extension. This allows us to
always use the 2.2.5 version of memcpy, making it possible to use the
gem on distributions with pre-2.14 versions of glibc.
Before this change:
$ objdump -T protobuf_c.so | grep memcpy
0000000000000000 DF *UND* 0000000000000000 GLIBC_2.3.4 __memcpy_chk
0000000000000000 DF *UND* 0000000000000000 GLIBC_2.14 memcpy
After:
$ objdump -T protobuf_c.so | grep memcpy
0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 memcpy
0000000000000000 DF *UND* 0000000000000000 GLIBC_2.3.4 __memcpy_chk
0000000000042450 g DF .text 0000000000000005 Base __wrap_memcpy
This is based on gRPC's solution to a similar problem:
5098508d2d/src/core/lib/support/wrap_memcpy.c
This fixes issue #2783.
This better shows the semantic of the API. For already setted fields,
mergeFromString do replacement for singular fields and appending for
repeated fields.
Fixes#698.
PrintHelpText now prints to standard output instead of to standard error.
The purpose of this CL is to make it easy for users to grep for matches
otherwise stderr output has to be awkwardly redirectly to stdout
using this shell trick `2>&1`, for example
```shell
protoc --help 2>&1 | grep cpp
```
of which we shouldn't be making users have to work that hard just to
get use of --help.
+ Exhibits:
* Before:
```shell
$ protoc --help | grep cpp
Usage: protoc [OPTION] PROTO_FILES
Parse PROTO_FILES and generate output based on the options given:
-IPATH, --proto_path=PATH Specify the directory in which to search
for
imports. May be specified multiple times;
directories will be searched in order. If
not
given, the current working directory is
used.
--version Show version info and exit.
-h, --help Show this text and exit.
--encode=MESSAGE_TYPE Read a text-format message of the given
type
from standard input and write it in binary
to standard output. The message type must
be defined in PROTO_FILES or their
imports.
--decode=MESSAGE_TYPE Read a binary message of the given type
from
standard input and write it in text format
to standard output. The message type must
be defined in PROTO_FILES or their
imports.
--decode_raw Read an arbitrary protocol message from
standard input and write the raw tag/value
pairs in text format to standard output.
No
PROTO_FILES should be given when using
this
flag.
-oFILE, Writes a FileDescriptorSet (a protocol
buffer,
--descriptor_set_out=FILE defined in descriptor.proto) containing
all of
the input files to FILE.
--include_imports When using --descriptor_set_out, also
include
all dependencies of the input files in the
set, so that the set is self-contained.
--include_source_info When using --descriptor_set_out, do not
strip
SourceCodeInfo from the
FileDescriptorProto.
This results in vastly larger descriptors
that
include information about the original
location of each decl in the source file
as
well as surrounding comments.
--dependency_out=FILE Write a dependency output file in the
format
expected by make. This writes the
transitive
set of input file paths to FILE
--error_format=FORMAT Set the format in which to print errors.
FORMAT may be 'gcc' (the default) or
'msvs'
(Microsoft Visual Studio format).
--print_free_field_numbers Print the free field numbers of the
messages
defined in the given proto files. Groups
share
the same field number space with the
parent
message. Extension ranges are counted as
occupied fields numbers.
--plugin=EXECUTABLE Specifies a plugin executable to use.
Normally, protoc searches the PATH for
plugins, but you may specify additional
executables not in the path using this
flag.
Additionally, EXECUTABLE may be of the
form
NAME=PATH, in which case the given plugin
name
is mapped to the given executable even if
the executable's own name differs.
--cpp_out=OUT_DIR Generate C++ header and source.
--csharp_out=OUT_DIR Generate C# source file.
--java_out=OUT_DIR Generate Java source file.
--javanano_out=OUT_DIR Generate Java Nano source file.
--js_out=OUT_DIR Generate JavaScript source.
--objc_out=OUT_DIR Generate Objective C header and source.
--python_out=OUT_DIR Generate Python source file.
--ruby_out=OUT_DIR Generate Ruby source file.
```
* After:
```shell
$ protoc --help | grep cpp
--plugin=EXECUTABLE Specifies a plugin executable to use.
Normally, protoc searches the PATH for
plugins, but you may specify additional
executables not in the path using this
flag.
Additionally, EXECUTABLE may be of the
form
NAME=PATH, in which case the given plugin
name
is mapped to the given executable even if
the executable's own name differs.
--cpp_out=OUT_DIR Generate C++ header and source.
--csharp_out=OUT_DIR Generate C# source file.
--java_out=OUT_DIR Generate Java source file.
--javanano_out=OUT_DIR Generate Java Nano source file.
--js_out=OUT_DIR Generate JavaScript source.
--objc_out=OUT_DIR Generate Objective C header and source.
--python_out=OUT_DIR Generate Python source file.
--ruby_out=OUT_DIR Generate Ruby source file.
```
There was a bug where for JavaScript we would only serialize an
extension value if it evaluated as truthy, which meant that values like
0 would get silently dropped (even in proto2, where field presence is
significant). This fixes issue #2605, and takes care of the output of
toObject() in addition to the binary format.
- Don't prune the extension registry as that can lead to failures when two
threads are racing.
- If adding the method fails, check and see if it already is bound to decide
the return result. Deals with threading races binding the methods.
A uint32 is big enough to hold any return value from that function, and
doing it this way prevents compiler warnings in coded_stream.h about
narrowing a uint64 to a uint32.
This method merges the contents of the specified message into the
current message. Singular fields that are set in the specified message
overwrite the corresponding fields in the current message. Repeated
fields are appended. Map fields key-value pairs are overritten.
Singular/Oneof sub-messages are recursively merged. All overritten
sub-messages are deep-copied.
There are two motivations for this:
1) calcdeps.py is deprecated and replaced by closurebuilder.py.
2) As part of this I was able to tweak things so that the Closure
compiler does not attempt to examine every .js file in the tree under
js/. This makes it possible to put compatibility tests and related files
in a subdirectory without them getting mixed up with the main .js files
we care about.
