Xcode 9 now enables CLANG_WARN_STRICT_PROTOTYPES by default.
This update ObjC function prototypes with no params from
FOUNDATION_EXPORT Something* DoSomething();
to
FOUNDATION_EXPORT Something* DoSomething(void);
Change-Id: I23b1d3e70a2ede2d2d77951ffe8a1a9598a1b7a0
Reviewed-on: https://go-review.googlesource.com/68970
Reviewed-by: Elias Naur <elias.naur@gmail.com>
Convert Go documentation to JavaDoc tags (/** ... */).
Since the .aar file format doesn't support source files, gomobile
will create a package-sources.jar along with the main package.aar.
For Objective-C, JavaDoc-style comments seems to work as well,
judging by manual inspection of Xcode quick help.
Change-Id: I47fe5b6804681d459a873be37a44610d392166ef
Reviewed-on: https://go-review.googlesource.com/52330
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Declare all implemented interfaces in the protocol list of a bound
struct. This is the ObjC equivalent of similar functionality for
Java.
Change-Id: Ibaea881f57fecf8a0716d25ec925de43974fe0fe
Reviewed-on: https://go-review.googlesource.com/52010
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
For functions on the form
New<T>... (...) *T
or
New<T>... (...) (*T, error)
generate corresponding initializers. The name of an initializer is
the function name where "New<T>" is replaced by "init".
If no functions match for a type *T, generate a default (empty)
initializer that returns new(T). The default initializer mirrors
the default constructor in Java.
Fixesgolang/go#20254.
Change-Id: I3c317418fa517d3f2de3f67f400867285b11ea4f
Reviewed-on: https://go-review.googlesource.com/52012
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Currently the generated bindings assume that any object
passed to Go as a method argument is actually a valid one
originating from Go. The `null` object is however a corner
case to this assumption, which should be accepted for Go
pointer types, since they can cleanly convert into `nil`.
This CL modifies the generated wrapper code so any `nil`
reference is permitted for Go pointer types, which until
now produced a nil pointer dereference error.
Fixesgolang/go#20330
Change-Id: If1ab9cf9df7ac3808486d23ccf2db8d32fb89426
Reviewed-on: https://go-review.googlesource.com/43253
Reviewed-by: Elias Naur <elias.naur@gmail.com>
If a wrapped Java class is missing at runtime, for example because
the app is running on an older Android version, the resulting class
not found exception would cause the app to crash. Fix it by ignoring
missing classes, allowing the app to avoid using them according to a
runtime version check.
Change-Id: I9138c4e2a905b180959306ecbb997695236ab273
Reviewed-on: https://go-review.googlesource.com/35853
Reviewed-by: David Crawshaw <crawshaw@golang.org>
For Java classes implemented in Go, it is useful to take a Java instance
and extract its wrapped Go instance. For example, consider the
java.lang.Runnable implementation wrapping a Go function:
package somepkg
type GoRunnable struct {
lang.Runnable
f func()
}
Java methods that take a java.lang.Runnable cannot directly take a
*GoRunnable, so this CL adds a Unwrap method:
import gorun "Java/somepkg/GoRunnable"
...
r := gorun.New()
r.Unwrap().(*GoRunnable).f = func() { ... }
javapkg.Run(r)
The extra interface conversion is unfortunately needed to avoid
import cycles.
Change-Id: Ib775a5712cd25aa75a19d364a55d76b1e11dce77
Reviewed-on: https://go-review.googlesource.com/35295
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Before this CL, with code such as
import "Java/some/pkg/Class"
...
Class.StaticFunc().DoSomething()
the reverse generator wouldn't find the the Java/some/pkg.Class
reference.
Change-Id: I1def4b54589fd1c123767ff59438c647cbced0cd
Reviewed-on: https://go-review.googlesource.com/35331
Reviewed-by: David Crawshaw <crawshaw@golang.org>
When wrapping Java exceptions, their toString() methods are called from
the wrapper's Error() method to satisfy the Go error interface. Make
sure toString() is always included, even if it never directly referenced
from bound packages.
Change-Id: I5653f6ad82afbe4b061e02a69d60453000288a83
Reviewed-on: https://go-review.googlesource.com/35189
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Before this CL, calling overloaded methods on reverse bound Java
classes and interfaces involved confusing and ugly name mangling.
If a set of methods with the same name differed only in argument count,
the mangling was simply adding the argument count to the name:
func F()
func F1(int32)
But if two or more methods had the same number of arguments, the type
had to be appended:
func (...) F() int32
func (...) F1(int32) (int32, error)
func (...) F__I(int32, int32)
func (...) F__JLjava_util_concurrent_TimeUnit_2(int64, concurrent.TimeUnit)
This CL sacrifices a bit of type safety and performance to regain the
convenience and simplicity of Go by resolving overloaded method dispatch
at runtime.
Overloaded Java methods are combined to one Go method that, when invoked,
determines the correct Java method variant at runtime.
The signature of the Go method is compatible with every Java method with
that name. For the example above, the single Go method becomes the most
general
func (...) F(...interface{}) (interface{}, error)
The method is variadic to cover function with a varying number of
arguments, and it returns interface{} to cover int32, int64 and no
argument. Finally, it returns an error to cover the variant that returns
an error. The generator tries to be specific; for example
func G1(int32) int32
func G2(int32, int32) int32
becomes
func G(int32, ...int32) int32
Overriding Java methods in Go is changed to use the Go parameter types to
determine to correct Java method. To avoid name clashes when overriding
multiple overloaded methods, trailing underscores in the method name are
ignored when matching Java methods. See the Get methods of GoFuture in
bind/testpkg/javapkg for an example.
Change-Id: I6ac3e024141daa8fc2c35187865c5d7a63368094
Reviewed-on: https://go-review.googlesource.com/35186
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This CL restructures function generation to match the way methods
are generated, to avoid two different code paths for a coming CL.
Change-Id: I5a4f15e51ea5df101f9aa419ed4170ab36506418
Reviewed-on: https://go-review.googlesource.com/35185
Reviewed-by: David Crawshaw <crawshaw@golang.org>
The tests was missing the generated code for the universe package
and some parts of the reverse generated code. Include it.
Change-Id: Id5e2f215c8f6f717c30377965255c4b64f31e923
Reviewed-on: https://go-review.googlesource.com/34992
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This is the Objective-C equivalent of CL 34776, generating reverse
wrappers for generated ObjC types. The implementation follows the same
strategy as the Java implementation: use the Go ast package to find
exported structs with embedded Objective-C types and synthesize their
types as if they were imported through clang.
In turn, the handling of the implicit "self" parameter changes in the
same way as well: the type of self parameters must be the wrapped type
for the generated type. For example:
func (d *GoNSDate) Description(self Foundation.NSDate) string
becomes
import gopkg "ObjC/Objcpkg"
func (d *GoNSDate) Description(self gopkg.GoNSDate) string
Change-Id: I26f838b06a622864be463f81dbb4dcae76f70f20
Reviewed-on: https://go-review.googlesource.com/34780
Reviewed-by: David Crawshaw <crawshaw@golang.org>
The Objective-C bindings was recently changed to support the empty
name prefix and to use that as the default. This CLs changed the Java
generators in the same way, supporting the empty Java package and using
it as the default.
Change-Id: I857affce686c67638a2b6c4e1da5d6a88d7ba560
Reviewed-on: https://go-review.googlesource.com/34778
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Before this CL, Java types that were only implicitly referenced
were represented as interface{}. However, if a value of such an
implicit type were passed to Java, a runtime crash would occur
because there would be no wrapper class to unwrap.
Fix this by generating implicit types, fixing the crashes,
gaining type safety, and removing the interface{} special case in
the generator.
While we're here, remove a redundant insert to the clsMap map in
java.go.
Change-Id: Ic50125da3d7cd6075899bf628d419b084c630490
Reviewed-on: https://go-review.googlesource.com/34777
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Before this CL, the type of the implicit "this" parameter to Java methods
implemented in Go could only be a super class of the generated Java
class. For example, the following GoRunnable type is an implementation of
the Java interface java.lang.Runnable with a toString method:
package somepkg
import "Java/java/lang"
type GoRunnable struct {
lang.Runnable
}
func (r *GoRunnable) ToString(this lang.Runnable) string {
...
}
The "this" parameter is implicit in the sense that the reverse generator
automatically fills it with a reference to the Java instance of
GoRunnable.
Note that "this" has the type Java/java/lang.Runnable, not
Java/go/somepkg.GoRunnable, which renders it impossible to call Java
methods and functions that expect GoRunnable. The most practical example
of this is the Android databinding libraries.
This CL changes the implicit this parameter to always match the exact
type. In the example, the toString implementation becomes:
import gopkg "Java/go/somepkg"
func (r *GoRunnable) ToString(this gopkg.GoRunnable) string {
...
}
One strategy would be to simply treat the generated Java classes
(GoRunnable in our example) as any other Java class and import it
through javap. However, since the Java classes are generated after
importing, this present a chicken-and-egg problem.
Instead, use the newly added support for structs with embedded prefixed types
and synthesize class descriptors for every exported Go struct type.
Change-Id: Ic5ce4a151312bd89f91798ed4088c9959225b448
Reviewed-on: https://go-review.googlesource.com/34776
Reviewed-by: David Crawshaw <crawshaw@golang.org>
The return value of a JNI call is undefined when an exception was
raised during the call. To make sure comparisons with NULL works,
clear the value when an exception is raised.
No new tests; some devices, like the Samsung S2, crashes with the
existing tests without this CL.
Change-Id: I85eb983e9444fff1f05e0f83a0640d106280e54d
Reviewed-on: https://go-review.googlesource.com/34631
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.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>
Package names, type names and method names are already sanitized.
Extend that to parameter names as well.
Change-Id: I408024c5e2f9561c37e8059a2b53199ee1afaef6
Reviewed-on: https://go-review.googlesource.com/31519
Reviewed-by: David Crawshaw <crawshaw@golang.org>
CL 29298 got rid of error type wrappers, but failed to update a
variable type accordingly.
Exposed by CL 31517 that enables -Werror.
Change-Id: I2c2b75dcd43b89ffa7fb008150b1aee09ec25229
Reviewed-on: https://go-review.googlesource.com/31518
Reviewed-by: David Crawshaw <crawshaw@golang.org>
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>
The go_seq_to_refnum function handles its argument object as a Java
object if it doesn't implement Seq.Proxy. Java classes implemented in
Go does not implement Seq.Proxy, but when passing "this" references to
Go, instances must be treated as a Go object.
Use go_seq_to_refnum_go everywhere "this" is passed to Go, which fixes
field accessors and simplifies the method call case.
Change-Id: I3d01c63d7b2081e6344ece431f5e5021a9dd7662
Reviewed-on: https://go-review.googlesource.com/31171
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Using the new ObjC type analyzer API, scan the bound packages for
references to ObjC classes and protocols and generate Go wrappers for them.
This is the second part of the implementation of proposal golang/go#17102.
For golang/go#17102
Change-Id: I773db7b0362a7ff526d0a0fd6da5b2fa33301144
Reviewed-on: https://go-review.googlesource.com/29174
Reviewed-by: David Crawshaw <crawshaw@golang.org>
The are three generators that currently call this method:
A -> B
(1) go -> java
(2) go -> objective-c
(3) go -> go
As discussed below, we only substitute for invalid unicode characters
in case (1).
**Case 1**
Go:
From golang.org/ref/spec:
Identifiers name program entities such as variables and types.
An identifier is a sequence of one or more letters and digits(unicode_digit).
The first character in an identifier must be a letter(unicode_letter | "_" ).
Java:
From https://docs.oracle.com/javase/specs/jls/se7/html/jls-3.html#jls-3.8
`The "Java letters" include uppercase and lowercase ASCII Latin letters
A-Z (\u0041-\u005a), and a-z (\u0061-\u007a), and, for historical reasons,
the ASCII underscore (_, or \u005f) and dollar sign ($, or \u0024). The $
character should be used only in mechanically generated source code or,
rarely, to access pre-existing names on legacy systems.`
Therefore, Go's identifiers are checked in case they break these Java rules.
**Case 2**
There is no objective-c standard specification for valid identifiers.
From some testing it seems that Go and objective-c have identical
valid identifier rules.
**Case 3**
Requires no checking.
Change-Id: I881810eb9355af6a418727ace32cb6ce4266b2a0
Reviewed-on: https://go-review.googlesource.com/14044
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Generate Cast functions that take a proxy for a Java class or interface,
and return a new proxy with the same reference. The Cast functions
panic if the underlying Java object is not an instance of the expected
type.
Change-Id: I08a5bf9a79139f0fac5dd102c7b028c8c989fc6d
Reviewed-on: https://go-review.googlesource.com/30095
Reviewed-by: David Crawshaw <crawshaw@golang.org>
A recent CL added Java constructors to generated classes that extends
or implements other Java classes and interfaces. Constructors for a
struct S are Go functions on the form
func NewS...(...) *S
If no such constructors exists, a default empty constructor is
generated.
Expand that to cover every exported Go struct.
Fixesgolang/go#17086
Change-Id: I910aba13d5884c3f67c946c62a8ac4a3db8e2ea7
Reviewed-on: https://go-review.googlesource.com/29710
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>
When the Java class parser began culling unused constructors, the
logic for determining whether a given Java class has a no-arg
constructor broke when the no-arg constructor is culled. Add
an explicit field for tracking the no-arg constructor property.
Change-Id: Ib68929ae1108bd6fa1fd23de1d134332eb0d97a2
Reviewed-on: https://go-review.googlesource.com/29875
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
With the introduction of constructors Java side, all types
become entry points into the library. However the library
was only initialized by the main class until now, resulting
in all other constructors hitting linker errors until an
interaction with the main library class.
This CL fixes that by changing each generated type to touch
the main library class, ensuring that the underlying native
library is loaded.
Change-Id: I640d1dc329e072f8d0753f74ccce87cd9e5aaea8
Reviewed-on: https://go-review.googlesource.com/29994
Reviewed-by: Elias Naur <elias.naur@gmail.com>
The ClassGen.genGo function always uses unsafe, contrary to what
the check in GenGo says. With this CL, generated code always
imports unsafe if there are any classes to be generated.
Change-Id: Ic807111a26e494b4941790830b1950bb8b1f73d5
Reviewed-on: https://go-review.googlesource.com/29873
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Accept Java API interface types as arguments and return values from
bound Go package functions and methods. Also, allow Go structs
to extend Java classes and implement Java interfaces as well as override
and implement methods.
This is the third and final part of the implementation of the golang/go#16876
proposal.
Fixesgolang/go#16876
Change-Id: I6951dd87235553ce09abe5117a39a503466163c0
Reviewed-on: https://go-review.googlesource.com/28597
Reviewed-by: David Crawshaw <crawshaw@golang.org>
GoUniverseerror is a (generated) protocol type, and variables of
protocol types use id<> notation.
Change-Id: I3d36b3ba634c10f0e59424faf71809c94df52cc6
Reviewed-on: https://go-review.googlesource.com/29052
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Using the new Java class analyzer API, scan the bound packages
for references to Java classes and interfaces and generate Go
wrappers for them.
This is the second part of the implementation of proposal golang/go#16876.
For golang/go#16876
Change-Id: I59ec0ebdae0081a615dc34d450f344c20c03f871
Reviewed-on: https://go-review.googlesource.com/28596
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Errors was recently converted to use objects as representation instead
of strings. Issue golang/go#17073 exposed a few places that wasn't properly
updated. Fix them and add the test case from the the issue.
Fixesgolang/go#17073
Change-Id: I0191993a8427d930540716407fc09032f282fc66
Reviewed-on: https://go-review.googlesource.com/29176
Reviewed-by: David Crawshaw <crawshaw@golang.org>
The new tests in CL 28494 exposed a bug: the ObjC generator does
not avoid reserved names and names with special meaning ("init").
Generalize the name sanitizer from the Java generator and use that.
Also, move the lowerFirst function to gen.go since it is now used
by both generators.
Change-Id: I25b7af2594b2ea136f05d2bab1cfdc66ba169859
Reviewed-on: https://go-review.googlesource.com/28592
Reviewed-by: David Crawshaw <crawshaw@golang.org>
There was a discussion a year ago about making methods and types
lowercase in ObjC (https://github.com/golang/go/issues/12889),
which was done (https://go-review.googlesource.com/#/c/15780/),
alas the suggested Java lower casing was never addressed.
This CL converts all generated Java methods to lower case.
Change-Id: Ia2f28519bc59362877881636109ddfc651b24960
Reviewed-on: https://go-review.googlesource.com/28494
Reviewed-by: Elias Naur <elias.naur@gmail.com>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Before this CL, generated Java classes or interfaces were inner
classes to the top package class. That is both unnecessary and creates
ugly class names. Instead, move every generated class and interface to its
own package level class.
NOTE: This is a backwards incompatible change and requires every client
of gomobile APIs to be updated to leave out the package class in the
type names. For example, the Go type
package pkg
type S struct {
}
now generates (with the default java package name go) a Java class named
go.pkg.S. The name before this CL was go.pkg.Pkg.S.
Also, change the custom java package to specify the package prefix and
not the full package as before. This is an unfortunate change needed
to avoid name clashes between two bound packages. On the plus side,
the change brings the custom package case closer to the default behaviour,
which is a commen prefix, "go.", and a distinct java package for every
Go package bound.
Change-Id: Iadfaad56e101d1caf7e2a05006f4d384859a20fe
Reviewed-on: https://go-review.googlesource.com/27436
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>
Proxies are an implementation detail, so make them private to hide
them from the public API.
Also, move the proxy classes out of its interface scope; classes
declared inside Java interfaces are always public and cannot be
declared otherwise. Use the lowercase "proxy" class prefix to
avoid name clashes with exported Go interfaces and structs.
Change-Id: Iae6a53ed4885b7899f2fa770b73c135f54ffb263
Reviewed-on: https://go-review.googlesource.com/21370
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Requiring user code to extend Go interface Stubs to be able to pass
Java objects to Go is clumsy and use up the single extend slot.
Instead, support (and enforce) java classes to implement translated
Go interface directly. This is similar to how ObjC works.
The stub classes are now gone, and users of gobind Java APIs need
to update their code to implement interfaces directly.
Change-Id: I880bb7c8e89d3c21210b2ab2c85ced8d7859ff48
Reviewed-on: https://go-review.googlesource.com/21313
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Each side of the language barrier maintains a map of reference numbers
to objects. Each entry has a reference count that exactly matches
the number of active proxy objects on the other side. When a reference
crosses the barrier, the count is incremented and when a proxy finalizer
is run, the count is decremented. If the count reaches 0, the reference
number and its object are removed from the map.
There is a possibility that a reference number is passed to the other
side, and the last proxy is then immediately garbage collected and
finalized. The reference counter then reaches 0 before the other side has
converted the reference number to its object, crashing the program.
This is possible in both Go/Java/ObjC but is most likely to happen in
ObjC because its own automatic reference count runtime frees objects
as soon as they are statically never referenced again.
Fix the race by always incrementing the reference count before sending
a reference across the barrier. When converting the reference back into
an object on the other side, decrement the counter again.
Only the new ObjC test fails without this fix, but I left the Java
counterpart in for good measure.
Change-Id: I92743aabec275b4a5b82b952052e7e284872ce02
Reviewed-on: https://go-review.googlesource.com/21311
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Java classes must explicitly declare implemented interfaces. Bind
already declares all such interfaces within each package. Expand
the set of interfaces to include all bound packages.
In addition, let Java interfaces extend all possible interfaces in
the same way as Java classes. To avoid circular references, only
let interfaces extend compatible interfaces with fewer methods.
Before, each package was imported in its own importer, breaking the
assumption of types.AssignableTo that identical packages have
identical *types.Package. Fix that by using one importer for all
bound packages, replacing package path equality checks with direct
equality checks.
While we're here, add missing arguments to a few error messages.
Change-Id: I5eb58972a3abe918862ca99d5a203809699a3433
Reviewed-on: https://go-review.googlesource.com/20987
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Rename the refnum field, Num, to something much less likely to clash
with an interface method set.
Change-Id: If334966b2430f38118baded44461bd39298bafb0
Reviewed-on: https://go-review.googlesource.com/20983
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
