* Don't bother searching for XCTest on non-Apple platforms
* Force working directory to be in the project root
This makes the spec tests work when cmake is invoked with a relative filename.
* Fix build error on Linux/GCC 7.4.0
This moves iOS and macOS user data from `NSDocumentDirectory` to `NSApplicationSupportDirectory`, adding a pre-open migration step that:
* Moves old data into the new location
* Cleans up any resulting empty directories in the old Documents folder
* Stops before removing the Documents folder itself (see tests)
Note that other platforms don't need a migration:
* tvOS was already storing documents in `NSCachesDirectory`
* Linux, Windows, and other UNIX haven't been publicly released or aren't changing.
See individual commits for details. Most notably this adds some additional filesystem manipulation routines to our (sadly) growing library.
Fixes#843.
* Update versions for Release 6.15.0
* Update podspec dependencies for M62 (#4640)
* Cherry-picks for M62. (#4650)
* Include GoogleUtilities in the release manifest.
* Crashlytics fix header import ordering issue (#4649)
Co-authored-by: Sam Edson <samedson@google.com>
Co-authored-by: Ryan Wilson <wilsonryan@google.com>
This change does not yet change all the classes that use the filesystem
to take Filesystem as a dependency. Those changes will come in follow-up
PRs.
This change is motivated by feedback in #4609. There I had created a
complicated interface to LevelDbOpener just so that different migration
scenarios could be tested, when in reality, I just needed to be able to
plumb through different values for the result of AppDataDir and related
functions.
* Remove unused -[FIRFirestore isLoggingEnabled]
Use util::LogIsLoggable(util::kLogLevelDebug) directly.
* Remove objc_compatibility.h
* Remove/cleanup unused #if __OBJC__ blocks
* Remove dead code
* Remove MakeNSStringNoCopy
* Remove worthless include
* Tidy up FIRFirestore
* Remove dead code and use forward declarations in FSTHelpers
* Minor fixes for LevelDbTransaction:
* Make methods const where possible
* Make key() and value() return const std::string&, allowing callers
to create their own const references
* Remove Comparator<NSString*>
* [1/4] Split Query and Target, and make LocalStore/RemoteStore work with Target. (#4413)
* [2/4]LimitToLast: Make SyncEngine work with Target (#4491)
* [3/4] Implement LimitToLast (#4505)
* Fix use after move in LevelDbPersistenceForTesting
* Fix size-related errors when compiling in 32-bit mode
* Fix test-only memory leaks
* Fix test-only memory leaks
* Prevent spec tests from appearing to leak
The spec tests aren't actually leaking, but they accumulate enough
garbage without clearing the autorelease pool that Instruments
complains.
* Avoid temporaries in methods that @throw
ARC does not release temporaries when an Objective-C exception is
thrown. Use C++ equivalents directly to avoid leaks as detected by
Instruments.
* Fix memory leak in acknowledge mutation
Any previous value must be freed before the next one is assigned.
* Manually implement assignment operators in ByteString
The single by-value implementation wasn't preventing the compiler
generated standard versions from being generated which was causing
leaks.
* Prevent leaking GrpcCompletions that complete after Shutdown
After shutdown, the AsyncQueue silently drops Enqueue requests which
prevents these blocks from being deleted.
* Avoid racing with enqueued operations
It's possible for the Executor to immediately execute the given block,
at which point the block might observe the async queue in a
not-shutting-down state.
* Change string parameters from absl::string_view to std::string
No abseil types can be used as parameters in this package.
This fixes an issue where Unity builds fail due to missing symbols.
The underlying issue is that Abseil in CocoaPods is an LTS release and
LTS releases contain an inline namespace, making types like
absl::string_view link as absl::lts_2019_08_08::string_view. When
compiling Firestore in google3 it uses the abseil in //third_party/absl,
which is not an LTS release and does not include the inline namespace.
This disagreement causes issues for the public C++ API which is compiled
in google3 and consumes code in the API package.
* Avoid absl::any in interfaces shared with public C++
* Make resource-related methods class members
This gives them access to private methods of friends of Serializer.
* Access control FieldPath/ResourcePath construction
* Access control Document construction
* Access control FieldValue construction
* Access control TransformOperation methods
* Remove DocumentSnapshot constructor that takes metadata pieces individually
* Restrict access to DocumentSnapshot from optional<Document>
* Add comments indicating how Abseil types are restricted
* Make DocumentKey::FromPathString take std::string
* Add Objective-C API tests to the CMake build
* Fix signedness warnings under the CMake build
* Get the remainder of Objective-C tests running under CMake
Also:
* Add a Path::HasExtension check
* Change spec tests to pick up json without NSBundle
Note: the output is indistinguishable from what is generated by the Objective-C library, with two exceptions:
* class names are different (due to using prefixes, e.g., `GCFS`);
* order in which map fields are outputted can be different (which I presume is to be expected).
I verified this by running integration tests and using simple diffing code to compare outputs: in the destructor of each `Message<T>` (if it's not moved-from), serialize the `Message` to bytes, create an Objective-C proto out of those bytes, convert both protos to their string form, compare the strings (ignoring minor differences in indentation, etc.). Out of 5.7K comparisons, there were just two cases of differences:
* one was in `SerializerTest.FailOnInvalidInputBytes`; since the input in question is invalid, this doesn't seem to require much attention;
* another one was due to differing floating point precision: C++ produces `1.79769e+308` while Objective-C produces `1.79769313486232e+308`. Added a TODO.
Example output:
```
2019-10-28 21:44:56.941749-0400 Firestore_Example_iOS[78883:2094242] 6.11.0 - [Firebase/Firestore][I-FST000001] WriteStream (7f903ca53d50) write request: <WriteRequest 0x70000991ef08>: {
writes {
update {
name: "projects/varconst-11-a51fd/databases/(default)/documents/test-collection/u6QizHeYjqt8Xe61kBoi"
fields {
key: "key"
value {
string_value: "value"
}
}
}
}
stream_token: "\031\020hB\002\201\364\265\265"
}
```
* Upgrade gRPC to 1.24.3
* Upgrade C++ Protobuf to 3.9.2
Disable -Wunreachable-code in protobuf-generated code
* Regenerate C++ protos with protobuf 3.9.2
* Generate objc protos with Protobuf 3.9.2
* Require CMake 3.5.1
This is the version required by the latest versions of gRPC and Google
Benchmark. See discussion https://github.com/google/benchmark/pull/613.
Remove version check around find_package(XCTest)
Also, add a dependency on objc protos that was missing but somehow
implicitly being added before.
* Upgrade Google Benchmark to 1.5.0
* Move FSTQueryCacheTests files to Firestore/core
* Rewrite QueryCache tests in C++
* Fix test flake in local store tests
This doesn't affect production because we always set the additional
references pointer there, but it's technically optional and some tests
don't do this.
There are more sources that can be `.cc` now (e.g., in API); these are left for a follow-up PR.
The dependency on Objective-C proto library cannot be removed just yet due to current lack of pretty-printing support for Nanopb.
After this PR is merged, the Objective-C serializers can be completely removed from the project. Also, this PR changes the `Message` class quite a bit; it's probably in its final form now.
I did some performance testing locally and came to the conclusion that replacing Objective-C serializers with their C++ versions brings no performance downgrade; actually, there seems to be a very slight improvement. I tested writing large batches and reading large collections:
* both are network-dominated; wall time is about twice longer than CPU time;
* serialization represents a pretty small percentage of the total CPU time;
* for writing, C++ serialization is a little more efficient, taking ~6% of total CPU time, compared to ~8% in the Objective-C version. I've seen similar results for reading.
All integration tests pass, under Address Sanitizer as well.
* Move FSTPersistenceHelpers to core/test/.../local
* Rewrite persistence_testing in C++
* Migrate from FSTPersistenceTestHelpers to C++ persistence_testing
* Rename .mm to .cc where possible in IndexManager tests
* Remove Objective-C gunk from index_manager_test.h
Replace all uses of `FSTSerializerBeta` in `remote_objc_bridge.{h,mm}` with the C++ `Serializer`. Also, make most of `remote/` sources pure C++ and remove no-longer-used methods in `FSTSerializerBeta`. All integration tests pass, under Address Sanitizer as well.
Unfortunately, pretty-printing is still delegated to Objective-C, so that `remote_objc_bridge.mm` still has to be an Objective-C++ source (and which prevents inlining `remote_objc_bridge` into the streams).
#no-changelog Will add a changelog entry when local serializer is ported, too.
Gil