Resolve merge conflicts from the origin repo #2
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…s_bug Fixed import guard when using relative file paths
…-list-out-files" contain only the names of files
Fixed crash when in-file-list or out-file-list path is unqualified
…ork with 131 only.
Set minimum compatible IDEA API version to 139.
…github project be the vendor.
IntelliJ plugin descriptor changes in preparation of uploading it to the public repository.
Update ios version in Make targets to 10.1.
Add a target for djinni_main.cpp, and use a new technique I discovered to make sure its JNI symbols are exposed by the shared-lib which contains it.
This is fixing a memory leak found in Dropbox's iOS networking libraries. Some ObjC objects were being autoreleased into a pool which is never flushed (the top-level pool on a C++-owned thread. This was Djinni violating its contracts around language isolation. The root cause turned out to be the destructor of an ObjcProxy object. Since it's called directly from C++, and does all its work in destructors, it was manipulating ObjC objects without an @autoreleasepool. The fix is more complex than I'd like due to the need to arrange for destructors to run inside of an @autorelease block, which forces an awkward code structure. Furthermore, I can't use optional without knowing what namespace to look in to find nullopt, which isn't easily extractable from Djinni's current usage, so I had to write my own. I'd very much like to find a simpler fix, so suggested follow-on diffs are welcome.
Automated fixes for typos in comments and strings.
This reverts commit fde1163.
…djinni_support_lib
- Adding global namespace scope to DJINNI_ASSERT to prevent conflict with local namespaces. - Add <memory> include to reference shared_ptr. - Use temporary variable in djinni_support.hpp to avoid compiler segfault.
CMake to build djinni support library
Generate bridging header for Swift
C++ fixes for compiler issues
dropbox#310) Fix Djinni initialization crash in multi shared library case on Android (i.e. djinni_support_lib is a shared library used by other shared libraries). Replaced generic static_registration class with non-templatized helpers in JniClassInitializer, which simplifies the code and avoids the issues of multiple instantiations of the same static data.
Fix CFStringEncoding/NSStringEncoding confusion
* Upgrade the example to Gradle 4.2 and Android plugin 2.3.3 Along with the necessary build system adjustments. * Move the NDK checks to Gradle execution phase Do not check for the NDK during Gradle configurion phase, otherwise a simple "gradle tasks" would fail if no NDK is configured. Do the checks later when the ndkBuild task is actually executed.
* Add a script to build static fat binary lib. Based on the platform file provided by the [ios-cmake](https://github.com/leetal/ios-cmake) repository, the script generates a fat static library based on the architectures specified by the `BUILD_ARCHITECTURES` variable. * Update according to the discussion - Rename the name of the script - Clarify what does the script * Move the build script. * Move script to support lib directory
Separate `flags` to `enum_flags.djinni`, to exclude it from `common.djinni`, so that it wouldn’t be picked up by Python in `python` branch. Otherwise it causes failure in `python` branch since flags feature is not implemented.
* example: Guard against ndkDir being null at configuration time This is a follow-up to PR dropbox#329. * example: Upgrade to Android Gradle plugin 3.0.1 Each version of the Android Gradle Plugin now has a default version of the build tools. The "compile" configuration was renamed to "implementation". * example: Upgrade to Gradle 4.4.1
…opbox#352) * Update parameter names in documentation Because parameter names may not be written in the same format between C++, Objective-C, and Java, it is impossible to have doxygen- or javadoc-style @param annotations that match for all languages. This change simply looks for "@param <PARAMNAME>" in the docstring and rewrites it the same way as the sourcecode does. * Replace all occurrences of parameter name in docstring * Also update Java for static methods * Add multi-word parameter name to test suite And reference it from the docstring. * Revert "Add multi-word parameter name to test suite" This reverts commit 785a226. * Add multi-word parameter name to test suite And reference it from the docstring.
* Generate an XCode like bridging header. Generates also the version number and name variable. * Add new generated headers. * Changes naming accorging to comments. * Update generated variable names.
ghost
mentioned this pull request
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.