From Xcode 10.2 onwards, these annotations are required in all interface
declarations. The behaviour can be disabled, but since we were already
annotated most types it made sense to just annotate the rest.
Change-Id: Iacd09a2fea4dfb3e22fec97cf4ca22966fc783bf
GitHub-Last-Rev: a431572a83ea8b29f55813bcdafc9a00f8d15972
GitHub-Pull-Request: golang/mobile#29
Reviewed-on: https://go-review.googlesource.com/c/mobile/+/171957
Reviewed-by: Elias Naur <mail@eliasnaur.com>
This highly improves interop with Swift. It would map all
pointers as implicitly unwrapped optionals, which skip all
null safety checks. Adding `_Nullable` to pointer types
makes swift map them as optionals.
Also constructors are now nullable since it's valid to return nil from
Go code.
Change-Id: If0506bb80f31bf36f11522c16a1e66d77be935f8
GitHub-Last-Rev: bd6c30f7f50ef5ea5797b07073f0a4a70d545025
GitHub-Pull-Request: golang/mobile#26
Reviewed-on: https://go-review.googlesource.com/c/mobile/+/159477
Run-TryBot: Elias Naur <mail@eliasnaur.com>
Reviewed-by: Elias Naur <mail@eliasnaur.com>
Current generated headers work because they require `ref.h` to be loaded beforehand by the bridging header. However, in some cases where the bridging header is generated by another tool (such as Bazel), the order can't be guaranteed.
Fix that by explicitly importing `ref.h` in the headers that need it.
Change-Id: I444453a0ebdf53e14ba1b5290f7cc7084eaf2c07
GitHub-Last-Rev: e1e1e915bf0428d871cb1a268c8456cf7051d383
GitHub-Pull-Request: golang/mobile#28
Reviewed-on: https://go-review.googlesource.com/c/159758
Reviewed-by: Elias Naur <mail@eliasnaur.com>
Since generated names now have their package names prefixed, the
extra prefix, "Go", is both confusing and counter-productive to
making the generated ObjC code look like any other native code.
Change the default to the empty prefix, while preserving support
for an explicit prefix if needed.
This is a backwards incompatible change; to keep the old behaviour,
specify "-prefix Go" to the gobind or gomobile command.
While we're here, fix the Ivy example for the recent change in
error returns.
Change-Id: I7fef4a92a18ddadee972ccf359652e3b31624f33
Reviewed-on: https://go-review.googlesource.com/34643
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Since the Go package name is already prefixed to generated ObjC
names, the empty extra prefix is useful. Support that by not reverting
to the default extra prefix, "Go", if -prefix "" is specified.
To avoid file name clashes with the Go header files, add ".objc" to
the ObjC-facing header names.
Change-Id: I559fe60d7474521617f23894af247c6019ff2a21
Reviewed-on: https://go-review.googlesource.com/33954
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
The current iOS binding generator only generates returns if the
function being bound does not return an error. If a second error
return type is also present, the binder always generates both the
primary as well as the error as an output parameter.
This is undersirable because most decent functions in Go will
also return errors, so all of those get converted to plain methods
iOS side, each of them requiring allocating the return variable
first and only then execute the call. This gets even more annoying
with the Swift error wrapping protocol which converts errors to
throw statements automatically, but which still needs the ugly pre-
allocs caused by the genrated bindings not returning the result,
just placing it in an output argument.
This CL changes that so that if a nullable result is being returned
by a bound method from Go, then it is generated as a proper return
and not an output argument. This allows erroring functions to still
be called as a function in ObjC, and even more elegantly drop even
the error part in Swift.
Change-Id: I35152d7d2fd2a132eba836fa23be8fd4f317f097
Reviewed-on: https://go-review.googlesource.com/34072
Reviewed-by: Elias Naur <elias.naur@gmail.com>
Accept ObjC API wrapper types as arguments and return values from
bound Go package functions and methods. Also, allow Go structs
to extend ObjC classes and implement ObjC protocols as well as override
and implement methods.
This is the third and final part of the implementation of the golang/go#17102
proposal.
Fixesgolang/go#17102
Change-Id: I601d90fb6d22b8d6f8b7d5fe0130daa1a4dd4734
Reviewed-on: https://go-review.googlesource.com/29175
Reviewed-by: David Crawshaw <crawshaw@golang.org>
CL 24800 changed the error representation from strings to objects.
However, since native errors types are not immediately compatible
across languages, wrapper types were introduced to bridge the gap.
This CL remove those wrappers and instead special case the error
proxy types to conform to their language error protocol.
Specifically:
- The ObjC proxy for Go errors now extends NSError and calls
initWithDomain to store the error message.
- The Go proxy for ObjC NSError return the localizedDescription
property for calls to Error.
- The Java proxy for Go errors ow extends Exception and
overrides getMessage() to return the error message.
- The Go proxy for Java Exceptions returns getMessage whenever
Error is called.
The end result is that error values behave more like normal objects
across the language boundary. In particular, instance identity is
now preserved: an error passed across the boundary and back will
result in the same instance.
There are two semantic changes that followed this change:
- The domain for wrapped Go errors is now always "go".
The domain wasn't useful before this CL: the domains were set to
the package name of function or method where the error happened
to cross the language boundary.
- If a Go method that returns an error is implemented in ObjC, the
implementation must now both return NO _and_ set the error result
for the calling Go code to receive a non-nil error.
Before this CL, because errors were always wrapped, a nil ObjC
could be represented with a non-nil wrapper.
Change-Id: Idb415b6b13ecf79ccceb60f675059942bfc48fec
Reviewed-on: https://go-review.googlesource.com/29298
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Gobind uses strings for passing errors across the language barrier.
However, since Gobind doesn't have a concept of a nil string, it
can't separate an empty native string from a nil string.
In turn, that means that empty errors, exceptions or NSError * with
an empty description are treated as no error. With ObjC, empty errors
are replaced with a default string to workaround the issue, while
with Java empty errors are silently ignored.
Fix this by replacing strings with actual error objects, wrapping
the Go error, Java Throwable or ObjC NSError *, and letting the
existing bind machinery take care of passing the references across.
It's a large change for a small corner case, but I believe objects
are a better fit for exception that strings. Error objects also
naturally leads to future additions, for example accessing the
exception class name or chained exception.
Change-Id: Ie03b47cafcb231ad1e12a80195693fa7459c6265
Reviewed-on: https://go-review.googlesource.com/24100
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Multiple packages are already supported, but only as if each packages
were bound in isolation. This CL lets a bound package refer to other
bound packages in its exported functions, types and fields.
In Java, the JNI class jclass and constructor jmethodID are exported
so other packages can construct proxies of other packages' interfaces.
In ObjC, the class @interface declarations are moved from the package
.m file to its .h file to allow other packages to constructs its
interface proxies.
Add a supporting test package, secondpkg, and add Java and ObjC tests
for the new cross package functionality. Also add simplepkg for
testing corner cases where the generated Go file must not include its
bound package.
While we're here, stop generating Go proxy types for struct types;
only Go interfaces can be implemented in the foreign language.
Change-Id: Icbfa739c893703867d38a9100ed0928fbd7a660d
Reviewed-on: https://go-review.googlesource.com/20575
Reviewed-by: David Crawshaw <crawshaw@golang.org>
