commit 48287e55b2888f3dfc4275ce1bbf90bdcaad7258
author Todd Wang <toddw@google.com> Wed Apr 20 15:15:43 2016 -0700
committer Todd Wang <toddw@google.com> Wed Apr 20 15:15:43 2016 -0700
tree 65fb8c1774f8a79280a2e2cdd799d0048cbbff54
parent fa769c26208ae18c91044cdf966ba0545f25afc3

Require transitively exported types in VDL.

Previously we allowed users to define types like this:

  type Exported struct { A unexported }
  type unexported struct { B []byte }

The problem with this pattern is that it makes it hard (or
sometimes impossible) to implement correct code.  E.g. in the
generated go code, we need the ability to set values of all types
to zero, and also to compare against zero.  The zero value in Go
isn't always the same as the zero value in VDL; e.g. Go
distinguishes nil and empty slices, while VDL does not.  So if
some code in a different package uses Exported, we won't be able
to check if Exported.A.B is zero or not; we can't access field B
from the unexported type.  Aaron reported similar issues in Swift
codegen.

This wasn't really intentional, but people actually started doing
it.  E.g. security used the unexported "publicKeyDischarge" in
the exported "WireDischarge" union, and rps used the unexported
"unused" empty struct in a couple of places.

This CL adds a restriction to the VDL compiler, requiring that
exported types are transitively exported.

The fix for both "publicKeyDischarge" and "unused" is to export
them.  I had tried to fix "unused" by allowing users to specify
the empty "struct{}" in VDL, as a special-case.  That's easy to
change in Go, but our Java / gradle / bintray / maven setup
baffles me, and I backed that out.

MultiPart: 1/2
Change-Id: Id1c1cec11920d0a97a0944b4b9af8046da484ff6