Gofmt to update doc comments to the new formatting.
For golang/go#51082.
Change-Id: I9b4c287e2d25aa108adfa9fe2f972c8fd3d68fe1
Reviewed-on: https://go-review.googlesource.com/c/mobile/+/399597
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
This CL gives CGO_ENABLED=1 explicitly when executing gobind since
Cgo is disabled by default when GOOS is given.
This CL also adds importing C to the tests to confirm that Cgo
works correctly.
This CL also updates go.mod since this change requries the change
in go/packages: golang.org/cl/214943
Updates golang/go#27234
Updates golang/go#36547
Change-Id: I66f9697f992f15b52fca7871e4e0ed64ca2b4965
Reviewed-on: https://go-review.googlesource.com/c/mobile/+/214498
Run-TryBot: Hajime Hoshi <hajimehoshi@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
bind_test.go compares the generated Go files against golden files
checked in the repository. The bind package formats some of the
generated Go files, so any changes in the go formatter can break
the tests.
This change makes the test more robust by applying formatting based
on the currently used go version. Since a golden file often
includes multiple go files generated by the bind, the `gofmt`
function splits the golden file using the gobindPreamble marker
and then run format.Source for each chunk. In order to ease the
golden file splitting, this CL also moves the gobindPreamble
to the beginning of each generated file consistently.
It turned out bind omits formatting for some go files (generated
for reverse binding). That needs to be fixed but it is a much
bigger fix. Thus, in this CL, we apply the formatting on the
bind's output as well.
This CL also updates the gobindPreamble to follow the style guide
for generated code. https://golang.org/s/generatedcodeFixesgolang/go#34619
Change-Id: Ia2957693154face2848e051ebbb2373e95d79593
Reviewed-on: https://go-review.googlesource.com/c/mobile/+/198322
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
previously package level function comments are ignored. this change
keeps the comment in generated java files
Change-Id: I86dcd93b1026c4455d2c4782cbc9f30b514b3107
Reviewed-on: https://go-review.googlesource.com/c/mobile/+/181038
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
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>
Our Java proxy class defines a constructor which takes a single int
that is the reference number of the Go peer. However, in Go, constructors
of the form NewT(i int32) *T generate the same signature as the internal
constructor.
The longer fix is to avoid using a constructor for initializing
proxies. This CL simply skips clashing Go constructors.
Reported in https://groups.google.com/forum/#!topic/golang-nuts/EKC_gEjaQH4
Change-Id: I1153f71d8b5a757c499b3ce6e18e2ea5d22dc9e5
Reviewed-on: https://go-review.googlesource.com/c/mobile/+/167660
Run-TryBot: Elias Naur <mail@eliasnaur.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.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>
The Character.Subset Java class changed between JDK 8 and JDK 11
which is the default JDK on my system. To avoid the golden tests
depend on the JDK version, drop the reference to the Character.Subset
class.
The inner class case is covered by the bind/java runtime tests.
For the upcoming Android container builders.
Change-Id: I05897ff7de7970633176207305099153de2f208c
Reviewed-on: https://go-review.googlesource.com/c/163377
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.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>
The go tool requires either HOME or GOCACHE set, but tests invoking
go install only passed GOPATH. Pass the inherited environment as well.
While here, update the reverse generated java.go.golden file with
additions from the latest Android SDK.
Change-Id: I3567dcc30e588b20266e9ba01d17a0ee547919bc
Reviewed-on: https://go-review.googlesource.com/c/159677
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
The current header generation uses old style Objective C
getters/setters. This causes Swift to incorrectly bridge properties as
methods. Using @property lets you write goObj.str = "value" (vs
goObj.setStr("value")).
Change-Id: I99d63743623734414edd50343dbdded52bdf2bf5
GitHub-Last-Rev: fb0ad7ec50d25ae5aa75ed729b04b95b99672f04
GitHub-Pull-Request: golang/mobile#27
Reviewed-on: https://go-review.googlesource.com/c/159618
Reviewed-by: Elias Naur <mail@eliasnaur.com>
Go 1.10 was supposed to change the jclass JNI type to map to Go
uintptr, but failed to map the Android NDK definition until
recently.
There was a single instance in the reverse binding generator that
compared jclass values to nil. Change it to use 0 and cast the
jclass value to uintptr to ensure compatibility with older Go
releases.
Change-Id: Ifa22ed2db556220b7dfd0076b004bd8930219e08
Reviewed-on: https://go-review.googlesource.com/124915
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
A previous CL switched gobind to use the "source" importer so go
files using cgo can be type checked. However, CGO_ENABLED=1 also
have to be passed in for such files not be ignored.
Also add -tags ios to the gomobile test output missing from CL
99777.
Fixesgolang/go#24941
Change-Id: I868469af3061b82ab592899e365a8a90a0333e58
Reviewed-on: https://go-review.googlesource.com/108336
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
When passing a refnum across the language barrier there is a small
window where a proxy object itself can be garbage collected, its
reference count go to 0 and the object be gone when the refnum
is dereferenced on the other side.
In Go the proxy object is pinned with runtime.KeepAlive. This CL
implements the same mechanism in Java by passing the proxy object to
native code, ensuring the Java GC can't reclaim it during the call.
Change-Id: I23824439012eb00f90d729f59d4846999f24f01f
Reviewed-on: https://go-review.googlesource.com/107095
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Android runs a finalizer watchdog that tracks the running time of
finalizers and throws an exception if any runs too long. Our
finalizers do very little work and as such are not affected by the
timeout. However, there has been reports, for example:
https://stackoverflow.com/questions/24021609/how-to-handle-java-util-concurrent-timeoutexception-android-os-binderproxy-fin
that the watchdog does not take into account periods where the device
goes to sleep in the middle of a finalizer run. So if a given app runs
in the background, the Java GC starts a finalizer and the device goes
to sleep before it returns, an exception will crash the app if the sleep
period extends the watchdog timeout.
The problem might be fixed on some newer version of Android, but the
problem is reported for as late as Android 6.
The suggested workaround is to use PhantomReferences and run a
background thread that take dead references off a ReferenceQueue and
perform cleanup.
This CL builds on the previous CL and splits up the Ref class so Refs
only reference counts Java objects, while a new class GoRef tracks Go
references. The Go references are wrapped in PhantomReferences that in
turn appear on a GoRefQueue to be cleaned up by a background (daemon)
Thread.
Change-Id: I04e3296b851999c612d3baf6a593cc044c2c5bdd
Reviewed-on: https://go-review.googlesource.com/106876
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Today, the Seq.Ref class has two purposes. For Java references,
Ref contains the refnum, a reference to the Java object and a
reference count. For Go references, Ref contains the refnum and
its finalizer makes sure to decrement the reference count on the Go
side.
The next CL will replace the use of finalizers with an explicit
ReferenceQueue of Go references, and the Ref class will no longer
be used for Go refences. To prepare for that, this CL pulls up the
construction of Go referencing Ref instances into the Seq.trackGoRef
function.
Change-Id: I9eefe238cd3fd1b661b2af11d331a2f61e31303b
Reviewed-on: https://go-review.googlesource.com/106875
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Before this change, binding unsupported basic types such as
uint failed with an error. Instead, add them to the list of
ignored types so that no error is generated and a comment is
generated explaining why the offending function, constant or
variable was skipped.
Unsigned integers are probably easy to support in ObjC, but
leave them unsupported for now.
While here, improve the printing of the ignored types in the
explaining comments.
Fixesgolang/go#24762
Change-Id: I0d9ab471b2245728270f6ee588f554d4a105d500
Reviewed-on: https://go-review.googlesource.com/105377
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Move the benchmark support package to the testdata directory, just
like the other test packages.
Change-Id: Idc35ca973a7da78e8c8bb640ba60cfb947fbed5b
Reviewed-on: https://go-review.googlesource.com/101896
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
The gobind and gomobile bind tools have historically overlapped:
gobind outputs generated bindings, and gomobile bind will generate
bindings before building them. However, the gobind bindings were
never used for building and thus allowed to not be complete.
To simplify version control, debugging, instrumentation and build
system flexibility, this CL upgrades the gobind tool to be the
canonical binding generator and change gomobile bind to use gobind
instead of its own generator code.
This greatly simplifies gomobile bind, but also paves the way to skip
gomobile bind entirely. For example:
$ gobind -outdir=$GOPATH golang.org/x/mobile/example/bind/hello
$ GOOS=android GOARCH=arm64 CC=<ndk-toolchain>/bin/clang go build -buildmode=c-shared -o libgobind.so gobind
$ ls libgobind.*
libgobind.h libgobind.so
The same applies to iOS, although the go build command line is more
involved.
By skipping gomobile it is possible to freely customize the Android
or iOS SDK level or any other flags not supported by gomobile bind.
By checking in the generated source code, the cost of supporting
gomobile in a custom build system is also decreased.
Change-Id: I59c14a77d625ac1377c23b3213672e0d83a48c85
Reviewed-on: https://go-review.googlesource.com/99316
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
The gobind command is about to get more powerful and able to generate
complete and standalone bindings. Platform specific build tags based
on GOOS or GOARCH are now meaningless to generate bindings from, so
remove them from the test packages.
The tags mattered to the reverse bound packages, since the go tool can't
build them without the Go wrappers for the imported Java packages.
Before this CL, the `android` tag was used to fool the go tool since
the host GOOS is unlikely to be android.
A fix is to check in the generated Go wrappers, but since the
packages are for testing we don't want that. Instead, move the test
packages to the testdata directory so the go tool ignores them.
Change-Id: I57178e930a400f690ebd7a65758bed894eeb10b0
Reviewed-on: https://go-review.googlesource.com/99315
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
If a Go struct or interface has the same name as its package class,
append an underscore to the generated Java class name.
Fixesgolang/go#23327.
Change-Id: Ib680af35c956801073a0effb510a3ed9bbb8b9d1
Reviewed-on: https://go-review.googlesource.com/87656
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
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>
Hilário Coelho
Russ Cox
Hajime Hoshi
Hana Kim
Junda Liu
Juan Pablo Civile
Elias Naur
Steeve Morin
Federico Bond
Tadas
Elias Naur
James Treanor
Péter Szilágyi