* Manual Xcode project fixups
* Remove `firebase/firestore` from paths in Firestore/core
This renames all Firestore files under `Firestore/core` to remove the
interior `firebase/firestore` directory structure. This is motivated by
build failures under Windows where the filenames of intermediates were
too long.
Concretely:
* `Firebase/core/src/firebase/firestore` becomes `Firebase/core/src`
* `Firebase/core/test/firebase/firestore` becomes
`Firebase/core/test/unit`
Moving the tests into a `unit` subdirectory aligns Firestore with the
directory structure in
[AddNewPod](https://github.com/firebase/firebase-ios-sdk/blob/master/AddNewPod.md),
modified for C++ (see discussion in #3224).
This includes fixes for:
* All the field escaping tests
* testCanWriteVeryLargeBatches
* testWritesWithIndirectlyNestedArraysSucceed
All tests now pass. I've left isRunningAgainstEmulator in the source
even though there are now no callers.
* Update Firestore project to Xcode 10.1 defaults
* Fix NSUInteger in format strings warning
* Fix implicit conversion warning in FSTLevelDB
* Fix BOOL/bool mismatch
* Fix erroneous comparison
This failure shows up on 32-bit targets. I have no idea why this
succeeds on 64-bit targets.
* Fix incorrect type inference with explicit cast
clang is inferring the type of the key in these maps is `NSString *` and
then complaining that `FIRFieldValue *` doesn't match that type, despite
the underlying method taking `NSDictionary<id, id>`. Explicitly casting
to `id` prevents the warning.
* Remove reliance on representation in FSTFieldValue tests
On *some* platforms [NSNumber numberWithChar:1] ends up with a "c"
(signed char) objcType, but apparently on 32-bit platforms this ends up
as "i" (signed int). Rather than relying on this working properly just
test that [NSNumber numberWithBool:] does the right thing.
* Fix field_value_test on 32-bit targets
When sizeof(void*) is 4 the test failed :-(.
* Rephrase testWritesWithLargeNumbersFail in terms of fixed size types
The prior definition only worked on LP64. Switching to LLONG_MAX would
have also fixed this, but Firestore's data model is independent of C's
data model, so rewriting this in terms of fixed size types more closely
models what's actually an invalid value.
* Fix implicit retain self warnings
* add a new property `timestampsInSnapshotsEnabled` to `FirestoreSettings`, `false` by default;
* add a verbose warning message urging users to opt into the new behavior;
* set `timestampsInSnapshotsEnabled` to true in the integration tests to reduce the verbose console
spam during the test run and make sure the flag won't break anything once it's flipped.
- FSTTimestamp is now FIRTimestamp, under Firestore/Source/{Public,API}. This is a temporary solution; eventually, FIRTimestamp is supposed to live somewhere under Firebase;
- move most internal Timestamp methods to the public header (the only exception is ISOString).
* Move all Firestore files to Objective-C++
* Update project file references
* Don't use module imports from Objective-C++
* Use extern "C" for C-accessible globals
* Work around more stringent type checking in Objective-C++
* NSMutableDictionary ivars aren't implicitly casted to NSDictionary
* FSTMaybeDocument callback can't be passed a function that accepts
FSTDocument
* NSComparisonResult can't be multiplied by -1 without casting
* Add a #include <inttypes.h> where needed
* Avoid using C++ keywords as variables
* Remove #if __cplusplus guards
Gil