Using NSCoding with a Message that has extensions is risky because
when reloaded, there is no way to provide a registry through the
NSCoding plumbing, so output a warnings to atleast give developers
a hint about the potential issues.
The builds were failing under Xcode 10 because of the new build system.
Even when reverted to the old build system, the build was failing
on the analyzer and swift bridging header, so it seems the general
logic for searching for things was changed in a way the setting does
not always cover.
- Disable HeaderMaps.
- Set user header search paths instead of system search paths.
- Turn off always search user paths (now recommended).
Tested in Xcode 10.1 and 9.4.1; both are able to build/pass with this.
Previously --cpp_out:lite was available to force the optimization mode
to the lite runtime. This adds --cpp_out=speed:...
which is needed to override the file specific options in cases where
libprotobuf-mutator is used for fuzzing since it depends on reflection.
Signed-off-by: Allen Webb <allenwebb@google.com>
* Increase C# default recursion limit to 100
This matches the Java and C++ defaults.
* Change compatibility tests to use execution-time default recursion limit
This way the same tests should pass against all versions, even
if the recursion limit changes. (The tests will be testing whether
different messages work, admittedly - but that's probably fine.)
We have code for converting C/C++/Objc keywords that appear in protos
to convert them so that they can be compiled.
One of the things we need to be careful of is accidentally overriding methods
that Apple declares in NSObject. It turns out that we have run into issues
where we conflict with "hidden" methods in NSObject or methods added by
categories. method_dump.sh collects all of the methods we care about for
macOS and iOS and dumps them into objectivec_nsobject_methods.h which
is then included in objectivec_helpers.cc as part of the build.
Added a pile of tests to verify that conversions are happening as expected.
This unbreaks the Windows shared-library build of Chrome when using
Clang versions based on r344987 or later, see https://crbug.com/901776
implicit_weak_message.cc is part of protobuf_lite.dll, and it includes
wire_format_lite.h, which includes the dllexport inline function
WireFormatLite::WriteGroupToArray which will therefore be emitted.
WriteGroupToArray in turn calls the inline function
InternalWriteGroupToArray, however that definition is provided in the
_inl file. To make sure the definition is available, the _inl file must
be included.
Before Clang r344987 the build worked anyway due to luck, because
InternalWriteGroupToArray was emitted into other object files (e.g. in
wire_format_lite.obj). After that Clang revision, those definitions
started getting inlined, and so are longer available and cause a link
failure for the reference from implicit_weak_message.obj.
@bazel_skylib//:lib is supposedly deprecated. The 'versions' struct in lib.bzl was committed to bazel-skylib at the same time as //lib:versions.bzl, so there should be no backward incompatibility.
No changes were needed, but since the Xcode projects pick up the updated
setting, the tests require a newer Xcode that supports Swift 4.
This is being done because Xcode 10 starting warning about Swift 3 support
going away in the future, so we might as well do the updates since most
folks shouldn't be on those really old Xcode versions any more.
Not sure the history for why there were two objc_library targets, but
given the one has an issue about not working, merge them into a single
target and an alias.
- Use the alias for :objectivec since that naming doesn't seem to follow
the other targets *_library targets here.
- Update :protobuf_objc to be use for the working target and just inline
the sources/headers lists so there is less indirection in the file.
Fixes#5284