* external/com_google_protobuf/src/google/protobuf/stubs/strutil.cc:1122:9: runtime error: negation of -9223372036854775808 cannot be represented in type 'google::protobuf::int64' (aka 'long'); cast to an unsigned type to negate this value to itself
* Bad external/com_google_protobuf/src/google/protobuf/text_format.cc:1320:14: runtime error: null pointer passed as argument 1, which is declared to never be null
/usr/include/string.h:62:62: note: nonnull attribute specified here
Signed-off-by: Harvey Tuch <htuch@google.com>
This actually has always been using the first branch because
`__cpluscplus` is not a real definition (contrast with the real spelling
of `__cplusplus`).
* 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
We ran into problems with precompiled protoc binaries not working on
some systems because of the dependence on a dynamically linked
libatomic. However, I found that linking against libatomic is not
actually necessary in our protoc build environment. Inside configure.ac
there's a test which figures out if we need to pass -latomic, and it
does this by attempting to build a test binary. That binary was failing
to build, but it turns out this was because we need to pass -std=c++11,
not -latomic.
This fixes#5875.
We need to mark messages as final soon, but before we do that we need to
provide a temporary opt-out mechanism to accommodate existing code that
inherits from generated messages. For 3.7.1 let's stop marking messages
final but in 3.8 we can reintroduce "final" with an opt-out option.
The bazel-bin/ and bazel-genfiles/ directories are going to be merged
soon. That change was causing some test failures on Windows, and I
believe it is because the logic for locating test data files was getting
confused and mistakenly looking for them under bazel-bin/. This commit
updates that logic to look for a more specific file (descriptor.cc)
which does not appear under any Bazel-related directories.
It sounds like the more official solution is to use the Bazel runfiles
library (i.e. //tools/cpp/runfiles). However, I decided not to do that
because we currently still support multiple build systems, and if we
used a separate solution for Bazel then I suspect we would need even
more #ifdefs in the code to handle the different systems.
* add check for reserved keywords in extensions
* add all reserved keywords
* use string without std::
* add test and update name in lite version
* test updates
* Replace strptime with custom implementation
* Fix ruby strptime
* Fix test
* Fix ruby conformance test
* Use mktime
* Remove EmptyFieldMask from failed conformance test list
