jni: Change vdl go codegen to emit __VDLInit funcs.
Fixes a subtle init-ordering issue in vdl-generated go code. The
basic problem looks something like this; there are many variants
to this problem, this is just one simple example:
// User's file a.go
package foo
import "v.io/v23/vdl"
var myType := vdl.TypeOf(FooType{})
// Generated file foo.vdl.go
package foo
import "v.io/v23/vdl"
func init() {
vdl.RegisterNative(FooToNative, FooFromNative)
}
The problem is that the vdl.RegisterNative call must occur before
the vdl.TypeOf call, so that the vdl package knows about native
types, and can analyze the type correctly. But init funcs are
always processed after all package-level variables have been
initialized, so we get the wrong order above.
We fix that by moving all initialization into a generated
__VDLInit func, with a trick to turn it into a var
initialization. Note that we still haven't fixed the above
example, since the package-level vars in a.go are typically
processed before foo.vdl.go. In the rare case where this
happens, the user can add a call to __VDLInit in a var
initializer early in their a.go file.
Similar problems existed with vom.RawBytesOf, and the
manually-generated types we were storing in package-level vars.
The new strategy is to put all ordering-dependent init logic in
__VDLInit, and to ensure that the order that we call things
within the function is correct. We also sort types, consts and
interfaces in the compiler as best we can. Note that sorting
types isn't strictly required (or meaningful), since we allow
cyclic types. But it still might be nice for some generated
languages.
There are further cleanups possible; we can probably add
error-checking more methodically for cases like above where the
user needs to add a call to __VDLInit, and we should replace the
long hex hash for generated type names to a simple counter. But
that'll occur in a separate CL; this is the more important one.
MultiPart: 2/6
Change-Id: I42e8d1827b354717c513376e623a993153c1e1a5
2 files changed
