The only case that doesn't work is decoding a wrapper type from JSON
at the top level. This doesn't make sense and probably no users do it
I changed it to throw.
* Rolled forward again with "Updated upb from defcleanup branch..."
Revert "Revert "Updated upb from defcleanup branch and modified Ruby to use it (#5539)" (#5848)"
This reverts commit 1568deab40.
* A few more merge fixes.
* Updated for defcleanup2 branch.
* Fixed upb to define upb_decode().
* Fixed names of nested messages.
* Revert submodule.
* Set -std=gnu90 and fixed warnings/errors.
Some of our Kokoro tests seem to run with this level of warnings,
and the source strives to be gnu90 compatible. Enforcing it for
every build removes the possibility of some errors showing up in
Kokoro/Travis tests only.
* Fixed remaining warnings with gnu90 mode.
I tried to match warning flags with what Ruby appears to do
in our Kokoro tests.
* Initialize values registered by rb_gc_register_address().
* Fixed subtle GC bug.
We need to initialize this marked value before creating the instance.
* Truly fix the GC bug.
* Updated upb for mktime() fix.
* Removed XOPEN_SOURCE as we are not using strptime().
* Removed fixed tests from the conformance failure list for Ruby.
* Fixed memory error related to oneof def names.
* Picked up new upb changes re: JSON printing.
* Uncomment concurrent decoding test.
Prior to this CL, creating an empty message object would create
two empty string objects for every declared field. First we
created a unique string object for the field's default. Then
we created yet another string object when we assigned the
default value into the message: we called #encode to ensure
that the string would have the correct encoding and be frozen.
I optimized these unnecessary objects away with two fixes:
1. Memoize the empty string so that we don't create a new empty
string for every field's default.
2. If we are assigning a string to a message object, avoid creating
a new string if the assigned string has the correct encoding and
is already frozen.
* add implicit time conversion
* add duration
* add init test
* more tests
* add type check and alternative c type check
* add rational and bigdecimal
* use rb_obj_is_kind_of
* use native time check
* chain implicit conversions
* remove unused variable
This change only adds basic proto2 support without advanced features
like extensions, custom options, maps, etc.
The protoc binary now generates ruby code for proto2 syntax.
However, for now, it is restricted to proto2 files without advanced features
like extensions, in which case it still errors out.
This change also modifies the DSL to add proto messages to the DescriptorPool.
There is a new DSL Builder#add_file to create a new FileDescriptor. With this,
the generated ruby DSL looks something like:
Google::Protobuf::DescriptorPool.generated_pool.build do
add_file "test.proto" do
add_message "foo" do
optional :val, :int32, 1
end
end
end
* Add continuous test for ruby 2.3, 2.4 and 2.5
* Change ruby 2.5 to 2.5.0
* No need to provide argument to rb_funcall when argc is 0
* Fix tests for ruby 2.5
* Use rescue instead of assert_raise to accept subclass of error
* This allows for ruby code to catch and handle Protobuf
TypeErrors separately from the standard Ruby TypeError
* Maintains backwards compatibility by having the new
Google::Protobuf::TypeError inherit from the base
TypeError. Any code that was catching TypeError should
continue to work.
self->field_type_class returns the correct Ruby class, get_def_obj
returns the Descriptor object used to generate the Ruby class via
msgclass, so to compare the two types we get the msgclass from the
descriptor.
While we are C99 in general, the Ruby build system
for building C extensions enables several flags that
throw warnings for C89/C90 variable ordering rules.
To avoid spewing a million warnings (or trying to
specifically override these warnings with command-line
flags, which would be tricky and possibly fragile)
we conform to Ruby's world of C89/C90.
Change-Id: I0e03e62d95068dfdfde112df0fb16a248a2f32a0
This adds the Map container and support for parsing and serializing maps
in the protobuf wire format (as defined by the C++ implementation, with
MapEntry submessages in a repeated field). JSON map
serialization/parsing are not yet supported as these will require some
changes to upb as well.
system. The Ruby module build now uses an amalgamated distribution of
upb, and successfully builds a Ruby gem called 'google-protobuf' with
module 'google/protobuf'.
