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.
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.
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.
If you make up a module map for Objective C protocol buffers, the compiler will complain about missing a declaration for GPBUnknownFieldSet which is used in this file.
* objectivec: Quash -Wself-assign
* objectivec: Set -Wno-vla when building
Objective-C protobuf uses VLAs for performance reasons. Ensure Clang
doesn’t complain about them.
Added new API to GPBEnumDescriptor to enable introspection of enum values.
Refactored implementation so that this contains a minimum of added code.
Clarified comments regarding behavior in the presence of the alias_allowed option.
Added unit tests for new functionality and for the alias case.
* Fix memory leak of exceptions raised by RaiseException()
Currently exceptions raised by RaiseException() is never deallocated because:
* ARC is disabled for this library: https://github.com/google/protobuf/blob/master/BUILD#L913
* It is constructed with `+alloc` but is never `-release`d.
This change fixes the issue by using `-[NSException exceptionWithName:...]` instead, which returns an autoreleased instance, so it is deallocated properly.
* Fix format.
The tests can run as what Apple calls a Logic Test (under xctest), which means
it doesn't have to load an full UI App under the simulator, which speeds things
up a fair amount.
To ensure all headers aren't dependent on other things being imported
before/after them, make a source that just imports each header and add
it to the unittesting target, that way we ensure it can be included on
its own with ordering issues.
Also do this testing with a few generated headers that aren't part of
the library to help ensure the different generated imports needed are
complete.
Haven't been able to make a repo case, but this should "fix" the problem
by avoid it completely.
- Move readOnlySemaphore_ into the .m file so it isn't exposed in any
header.
- Move GPBGetObjectIvarWithField() also to go with the new limited
visibility on the readOnlySemaphore_.
The Undefined Behavior sanitizer flags one part of the unittests for this.
For default values for `bytes` we write a length on the front of a c-string
in the static data, apparently the compiler/linker doesn't always make this
4 byte aligned, so it get flagged for undefined/degraded performance. Avoid
this by using memcpy instead.
The generated code for enums needs atomics support, so generate the
import instead of relying on it via transitive imports. This will
make future changes to this likely likely to break generated code
and runtime support are mixed.
Followup to https://github.com/google/protobuf/pull/4184.
Followup to https://github.com/google/protobuf/pull/4184, keep the
import to not break any existing generated code that isn't regenerated
when they update to the newer protobuf code.