- Bump the version marker in the generated code.
- Set the flag to say clear on zero is known.
- Set clear on zero for proto3 optional fields that aren't tagged as optional.
- Also tweak the call from some C generated code to use different apis with
better validation.
- Mark the ObjC generator as supporting the proto3 optional feature.
- Regenerate the WKTs to get the new flags.
- With the new flags, the syntax isn't needed, so don't pass it.
- To keep library binary compatibility, rename the helpers since one
"Internal" method was called from generated code. Keep a shim with
the old signature to support those generated sources.
- Add a Descriptor flag to capture if the field should clear on being zeroed.
- Update the runtime to use the new clear on zero flag.
- Add a flag on message initialization to indicate the sources were generated
with/without this support so the runtime can backfill the flag for older
generated sources.
- Don't make an OneofGenerator for synthetic oneofs.
- Update the field calculations that determine if hasbits are needed to
know about synthetic oneofs and ignore them.
There are have been a few issues around people using case sensitive file systems
what Xcode/clang does when looking at the paths. In attempts to solve one set of
warnings, new warnings/errors happened in different setup. So, to hopefully put
these problem away for got, move the WKTs to be at the same level as the other
headers.
- Revert "Override CocoaPods module to lowercase (#6464)"
This reverts commit 479ba8226b.
- Move WKTs to the objectivec directory and make the old headers shim back to
the new locations.
- Update objectivec/generate_well_known_types.sh to check them one at a time
and to deal with the new locations for them.
Fixes#6803
This should reduce binary size slightly, small performance improvement, and improve linkage by forcing references to all used classes.
Note that this maintains backwards compatibility for sources generated by older protoc for the time being. If you want the benefits
you will need to recompile your protos with the newer protoc.
VLAs complicate static analysis and bloat stack size. Replace VLA allocation
with calls to malloc and free. This will alos the code to build with -Wvla.
The OSReadLittleInt64 function as defined by Apple reduces down to:
`return *(volatile uint64_t *)((uintptr_t)base + byteOffset);`
which means we are type-punning using a cast. On ARMv7 and other aligned architectures this can cause crashes.
Minimal example: https://gist.github.com/dmaclach/b10b0a71ae614d304c067cb9bd264336Fixes#6679
The code in question hasn't change in a long time so the cause of
https://github.com/firebase/firebase-ios-sdk/issues/3851 still appears to be
an Xcode 11 clang change/bug; but this does appear to be slightly better
code for the work being done.
Cleanup along the way for #6679
The OSReadLittleInt64 function as defined by Apple reduces down to:
`return *(volatile uint64_t *)((uintptr_t)base + byteOffset);`
which means we are type-punning using a cast. On ARMv7 and other aligned architectures this can cause crashes.
Minimal example: https://gist.github.com/dmaclach/b10b0a71ae614d304c067cb9bd264336Fixes#6679
The code in question hasn't change in a long time so the cause of
https://github.com/firebase/firebase-ios-sdk/issues/3851 still appears to be
an Xcode 11 clang change/bug; but this does appear to be slightly better
code for the work being done.
Cleanup along the way for #6679
This avoids hitting the following warning when including GPBDescriptor.h in ARC
projects with stricter warning settings:
error: 'assign' property of object type may become a dangling reference; consider using 'unsafe_unretained' [-Werror,-Wobjc-property-assign-on-object-type
We first hit this in XCode 11, it's unclear whether it simply got stricter about
enforcing this warning or whether the flags enabled with -Wall or -Weverything
have been expanded.
For reasons I don't follow, when passing CXXFLAGS to configure, the build
ends up breaking because something along the way fails to detect C++11
support within the third_party/googletest part of the build.
The CocoaPod (and source) have always support tvOS, but adding the project
makes it easier to run the tests and debug if there ever were an issue.
(not adding a watchOS project at the moment because Apple doesn't provide
XCTest, so all it could do is build the library. We still support that,
just can't "test" it.)