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.)
Some protos have enum values of "FOO" and "Foo", which the ObjC generation
then makes into the same thing. Just skip generating the enum element for
the duplicate as it would be a compile error because of the name collision.
The descriptors are still generated to support reflection and TextFormat
more completely.
Just like fields, some extension fieldnames can be named such that they appear
to have meaning to ARC. Add the annotation to the compiler will get things
correct.
Add a bunch of extensions to allow inspection on generation to ensure things
are correct.
For deprecated fields, identify the deprecated field and source file in the deprecation message. For deprecated files, identify the deprecated file in deprecation messages of generated interfaces. This additional context in deprecation messages will help provide developers with more context which could help them seek recommended alternatives to deprecated interfaces.
In some cases proto files that want/need to use the objc_class_prefix option have
types that already have the prefix on a subset of their names. In this case we don't
want to duplicate the prefix.
Added tests for this (and prefixes in general).
Instead of using DEPRECATED_ATTRIBUTE from AvailabilityMacros.h, we should introduce a Google-specific Objective-C protobuf deprecation annotation. This helps address IWYU issues with using DEPRECATED_ATTRIBUTE and also enables allows clients to redefine the macro to treat protobuf warnings differently than other types of warnings (e.g., treating protobuf deprecation warnings as errors or ignoring them).
For messages that have multiple extension ranges, this will improve things
by avoiding repeated work. For messages with a single range, it should
be a wash.
- Sort the list of set extensions once during serialization and reuse the list.
- Break out of the serialization loop as soon as the loop has moved pasted at
accepted range for field ids.
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.
Rafi Kamal
Thomas Van Lenten
dmaclach
Paul Beusterien
Paul Yang
Julien Poumailloux
Andrzej Hunt
Hao Nguyen
Benjamin Peterson
Xiang Dai
Stephane Moore
Adam Cozzette
Parveen Bhatia
Michael Shields
Josh Haberman
Feng Xiao