Mojom runtime type info: New implementation for Go.

Mojom runtime type info: New implementation for Go.

Our implementation of runtime type information is changing and this CL implements the change for Go. The older implementation still exists for Dart. (Those are the only two languages for which the runtime type info has yet been implemented.)

In the older implementation the runtime type structures are computed and constructed by the code generators (thus in Python and the Jinja 2 templates).
In this newer implementation the Mojom parser computes the information and stores it in a mojom_types.RuntimeTypeInfo
structure. Then the code generators insert a literal array of bytes representing a serialized RuntimeTypeInfo into the generated Go code. At runtime all a Mojo application needs to do
is deserialize the RuntimeTypeInfo struct and use it to answer queries.

- In mojom_translator.py copy serialized_runtime_type_info into the mojom.Module.
- In mojom_go_generator.py we compute a Go literal string defining this array of bytes.
- In source.tmpl we generate Go code to deserialize this array of bytes into a RuntimeTypeInfo
struct and use this struct to answer queries about runtime type info.
- We delete the old implementation from source.tmpl and delete the files mojom_reference_macros.tmpl
and mojom_type_macros.tmpl.
- We fix up validation_type_test.go in accordance with these changes. The main change is that we use the format
of the type key currently being generated by the mojom parser. Also the old implementation was apparently
setting field names in DeclData incorrectly so we modify the tests to look for the correct names.
- The new implementation does not support generating the function GetTopLevelInterface() on interfaces that
are not top-level interfaces. Therefore we add the "ServiceName" annotation to the interface that is being
used to test this function: the BoundsCheckTestInterface in validation_test_interfaces.mojom.

BUG=#448
R=alexfandrianto@google.com, azani@chromium.org

Committed: https://chromium.googlesource.com/external/mojo/+/4970253149a7bc1d057c13fd8f173f2c795b3bfd

[rudominer, 2016-02-23 02:08:27]

Patchset #1 (id:1) has been deleted

[rudominer, 2016-02-23 02:08:35]

Patchset #1 (id:20001) has been deleted

[rudominer, 2016-02-23 02:08:44]

Patchset #1 (id:40001) has been deleted

[rudominer, 2016-02-23 02:08:57]

Patchset #1 (id:60001) has been deleted

[rudominer, 2016-02-23 02:09:04]

Patchset #1 (id:80001) has been deleted

[rudominer, 2016-02-23 02:09:10]

Patchset #1 (id:100001) has been deleted

[rudominer, 2016-02-23 02:09:18]

Patchset #1 (id:120001) has been deleted

[rudominer, 2016-02-23 02:19:12]

Description was changed from

==========
Deserialize RuntimeTypeInfo in the go template.

BUG=
==========

to

==========
Mojom runtime type info: New implementation for Go.

Our implementation of runtime type information is changing and this CL
implements the change for Go. The older implementation still exists for Dart.
(Those are the only two languages for which the runtime type info has yet been
implemented.)

In the older implementation the runtime type structures are computed and
constructed by the code generators. In this newer implementation the Mojom
parser computes the information and then the code generators insert a literal
array of bytes representing a serialized RuntimeTypeInfo into the generated Go
code. At runtime all a Mojo application needs to do
is deserialize the RuntimeTypeInfo struct and use it to answer queries.

- In mojom_translator.py copy serialized_runtime_type_info into the
mojom.Module.
-

BUG=448
==========

[rudominer, 2016-02-23 02:35:05]

Description was changed from

==========
Mojom runtime type info: New implementation for Go.

Our implementation of runtime type information is changing and this CL
implements the change for Go. The older implementation still exists for Dart.
(Those are the only two languages for which the runtime type info has yet been
implemented.)

In the older implementation the runtime type structures are computed and
constructed by the code generators. In this newer implementation the Mojom
parser computes the information and then the code generators insert a literal
array of bytes representing a serialized RuntimeTypeInfo into the generated Go
code. At runtime all a Mojo application needs to do
is deserialize the RuntimeTypeInfo struct and use it to answer queries.

- In mojom_translator.py copy serialized_runtime_type_info into the
mojom.Module.
-

BUG=448
==========

to

==========
Mojom runtime type info: New implementation for Go.

Our implementation of runtime type information is changing and this CL
implements the change for Go. The older implementation still exists for Dart.
(Those are the only two languages for which the runtime type info has yet been
implemented.)

In the older implementation the runtime type structures are computed and
constructed by the code generators. In this newer implementation the Mojom
parser computes the information and then the code generators insert a literal
array of bytes representing a serialized RuntimeTypeInfo into the generated Go
code. At runtime all a Mojo application needs to do
is deserialize the RuntimeTypeInfo struct and use it to answer queries.

- In mojom_translator.py copy serialized_runtime_type_info into the
mojom.Module.
- In mojom_go_generator.py we compute a Go literal string defining this array of
bytes.
- In source.tmpl we generate Go code to deserialize this array of bytes into a
RuntimeTypeInfo
struct and use this struct to answer queries about runtime type info.
- We delete the old implementation from source.tmpl and delete the files
mojom_reference_macros.tmpl
and mojom_type_macros.tmpl.
- We fix up validation_type_test.go in accordance with these changes. The main
change is that we use the format
of the type key currently being generated by the mojom parser. Also the old
implementation was apparently
setting field names in DeclData incorrectly so we modify the tests to look for
the correct names.
- The new implementation does not support generating the function
GetTopLevelInterface() on interfaces that
are not top-level interfaces. Therefore we add the "ServiceName" annotation to
the interface that is being
used to test this function: the BoundsCheckTestInterface in
validation_test_interfaces.mojom.

BUG=448
==========

[rudominer, 2016-02-23 02:44:04]

Description was changed from

==========
Mojom runtime type info: New implementation for Go.

Our implementation of runtime type information is changing and this CL
implements the change for Go. The older implementation still exists for Dart.
(Those are the only two languages for which the runtime type info has yet been
implemented.)

In the older implementation the runtime type structures are computed and
constructed by the code generators. In this newer implementation the Mojom
parser computes the information and then the code generators insert a literal
array of bytes representing a serialized RuntimeTypeInfo into the generated Go
code. At runtime all a Mojo application needs to do
is deserialize the RuntimeTypeInfo struct and use it to answer queries.

- In mojom_translator.py copy serialized_runtime_type_info into the
mojom.Module.
- In mojom_go_generator.py we compute a Go literal string defining this array of
bytes.
- In source.tmpl we generate Go code to deserialize this array of bytes into a
RuntimeTypeInfo
struct and use this struct to answer queries about runtime type info.
- We delete the old implementation from source.tmpl and delete the files
mojom_reference_macros.tmpl
and mojom_type_macros.tmpl.
- We fix up validation_type_test.go in accordance with these changes. The main
change is that we use the format
of the type key currently being generated by the mojom parser. Also the old
implementation was apparently
setting field names in DeclData incorrectly so we modify the tests to look for
the correct names.
- The new implementation does not support generating the function
GetTopLevelInterface() on interfaces that
are not top-level interfaces. Therefore we add the "ServiceName" annotation to
the interface that is being
used to test this function: the BoundsCheckTestInterface in
validation_test_interfaces.mojom.

BUG=448
==========

to

==========
Mojom runtime type info: New implementation for Go.

Our implementation of runtime type information is changing and this CL
implements the change for Go. The older implementation still exists for Dart.
(Those are the only two languages for which the runtime type info has yet been
implemented.)

In the older implementation the runtime type structures are computed and
constructed by the code generators (thus in Python and the Jinja 2 templates).
In this newer implementation the Mojom parser computes the information and then
the code generators insert a literal array of bytes representing a serialized
RuntimeTypeInfo into the generated Go code. At runtime all a Mojo application
needs to do
is deserialize the RuntimeTypeInfo struct and use it to answer queries.

- In mojom_translator.py copy serialized_runtime_type_info into the
mojom.Module.
- In mojom_go_generator.py we compute a Go literal string defining this array of
bytes.
- In source.tmpl we generate Go code to deserialize this array of bytes into a
RuntimeTypeInfo
struct and use this struct to answer queries about runtime type info.
- We delete the old implementation from source.tmpl and delete the files
mojom_reference_macros.tmpl
and mojom_type_macros.tmpl.
- We fix up validation_type_test.go in accordance with these changes. The main
change is that we use the format
of the type key currently being generated by the mojom parser. Also the old
implementation was apparently
setting field names in DeclData incorrectly so we modify the tests to look for
the correct names.
- The new implementation does not support generating the function
GetTopLevelInterface() on interfaces that
are not top-level interfaces. Therefore we add the "ServiceName" annotation to
the interface that is being
used to test this function: the BoundsCheckTestInterface in
validation_test_interfaces.mojom.

BUG=448
==========

[rudominer, 2016-02-23 02:45:21]

Description was changed from

==========
Mojom runtime type info: New implementation for Go.

Our implementation of runtime type information is changing and this CL
implements the change for Go. The older implementation still exists for Dart.
(Those are the only two languages for which the runtime type info has yet been
implemented.)

In the older implementation the runtime type structures are computed and
constructed by the code generators (thus in Python and the Jinja 2 templates).
In this newer implementation the Mojom parser computes the information and then
the code generators insert a literal array of bytes representing a serialized
RuntimeTypeInfo into the generated Go code. At runtime all a Mojo application
needs to do
is deserialize the RuntimeTypeInfo struct and use it to answer queries.

- In mojom_translator.py copy serialized_runtime_type_info into the
mojom.Module.
- In mojom_go_generator.py we compute a Go literal string defining this array of
bytes.
- In source.tmpl we generate Go code to deserialize this array of bytes into a
RuntimeTypeInfo
struct and use this struct to answer queries about runtime type info.
- We delete the old implementation from source.tmpl and delete the files
mojom_reference_macros.tmpl
and mojom_type_macros.tmpl.
- We fix up validation_type_test.go in accordance with these changes. The main
change is that we use the format
of the type key currently being generated by the mojom parser. Also the old
implementation was apparently
setting field names in DeclData incorrectly so we modify the tests to look for
the correct names.
- The new implementation does not support generating the function
GetTopLevelInterface() on interfaces that
are not top-level interfaces. Therefore we add the "ServiceName" annotation to
the interface that is being
used to test this function: the BoundsCheckTestInterface in
validation_test_interfaces.mojom.

BUG=448
==========

to

==========
Mojom runtime type info: New implementation for Go.

Our implementation of runtime type information is changing and this CL
implements the change for Go. The older implementation still exists for Dart.
(Those are the only two languages for which the runtime type info has yet been
implemented.)

In the older implementation the runtime type structures are computed and
constructed by the code generators (thus in Python and the Jinja 2 templates). 
In this newer implementation the Mojom parser computes the information and
stores it in a mojom_types.RuntieTypeInfo
structure. Then the code generators insert a literal array of bytes representing
a serialized RuntimeTypeInfo into the generated Go code. At runtime all a Mojo
application needs to do
is deserialize the RuntimeTypeInfo struct and use it to answer queries.

- In mojom_translator.py copy serialized_runtime_type_info into the
mojom.Module.
- In mojom_go_generator.py we compute a Go literal string defining this array of
bytes.
- In source.tmpl we generate Go code to deserialize this array of bytes into a
RuntimeTypeInfo
struct and use this struct to answer queries about runtime type info.
- We delete the old implementation from source.tmpl and delete the files
mojom_reference_macros.tmpl
and mojom_type_macros.tmpl.
- We fix up validation_type_test.go in accordance with these changes. The main
change is that we use the format
of the type key currently being generated by the mojom parser. Also the old
implementation was apparently
setting field names in DeclData incorrectly so we modify the tests to look for
the correct names.
- The new implementation does not support generating the function
GetTopLevelInterface() on interfaces that
are not top-level interfaces. Therefore we add the "ServiceName" annotation to
the interface that is being
used to test this function: the BoundsCheckTestInterface in
validation_test_interfaces.mojom.

BUG=448
==========

[rudominer, 2016-02-23 02:45:58]

Description was changed from

==========
Mojom runtime type info: New implementation for Go.

Our implementation of runtime type information is changing and this CL
implements the change for Go. The older implementation still exists for Dart.
(Those are the only two languages for which the runtime type info has yet been
implemented.)

In the older implementation the runtime type structures are computed and
constructed by the code generators (thus in Python and the Jinja 2 templates). 
In this newer implementation the Mojom parser computes the information and
stores it in a mojom_types.RuntieTypeInfo
structure. Then the code generators insert a literal array of bytes representing
a serialized RuntimeTypeInfo into the generated Go code. At runtime all a Mojo
application needs to do
is deserialize the RuntimeTypeInfo struct and use it to answer queries.

- In mojom_translator.py copy serialized_runtime_type_info into the
mojom.Module.
- In mojom_go_generator.py we compute a Go literal string defining this array of
bytes.
- In source.tmpl we generate Go code to deserialize this array of bytes into a
RuntimeTypeInfo
struct and use this struct to answer queries about runtime type info.
- We delete the old implementation from source.tmpl and delete the files
mojom_reference_macros.tmpl
and mojom_type_macros.tmpl.
- We fix up validation_type_test.go in accordance with these changes. The main
change is that we use the format
of the type key currently being generated by the mojom parser. Also the old
implementation was apparently
setting field names in DeclData incorrectly so we modify the tests to look for
the correct names.
- The new implementation does not support generating the function
GetTopLevelInterface() on interfaces that
are not top-level interfaces. Therefore we add the "ServiceName" annotation to
the interface that is being
used to test this function: the BoundsCheckTestInterface in
validation_test_interfaces.mojom.

BUG=448
==========

to

==========
Mojom runtime type info: New implementation for Go.

Our implementation of runtime type information is changing and this CL
implements the change for Go. The older implementation still exists for Dart.
(Those are the only two languages for which the runtime type info has yet been
implemented.)

In the older implementation the runtime type structures are computed and
constructed by the code generators (thus in Python and the Jinja 2 templates). 
In this newer implementation the Mojom parser computes the information and
stores it in a mojom_types.RuntimeTypeInfo
structure. Then the code generators insert a literal array of bytes representing
a serialized RuntimeTypeInfo into the generated Go code. At runtime all a Mojo
application needs to do
is deserialize the RuntimeTypeInfo struct and use it to answer queries.

- In mojom_translator.py copy serialized_runtime_type_info into the
mojom.Module.
- In mojom_go_generator.py we compute a Go literal string defining this array of
bytes.
- In source.tmpl we generate Go code to deserialize this array of bytes into a
RuntimeTypeInfo
struct and use this struct to answer queries about runtime type info.
- We delete the old implementation from source.tmpl and delete the files
mojom_reference_macros.tmpl
and mojom_type_macros.tmpl.
- We fix up validation_type_test.go in accordance with these changes. The main
change is that we use the format
of the type key currently being generated by the mojom parser. Also the old
implementation was apparently
setting field names in DeclData incorrectly so we modify the tests to look for
the correct names.
- The new implementation does not support generating the function
GetTopLevelInterface() on interfaces that
are not top-level interfaces. Therefore we add the "ServiceName" annotation to
the interface that is being
used to test this function: the BoundsCheckTestInterface in
validation_test_interfaces.mojom.

BUG=448
==========

[rudominer, 2016-02-23 05:20:00]

Patchset #1 (id:140001) has been deleted

[rudominer, 2016-02-23 16:56:28]

rudominer@chromium.org changed reviewers:
+ alexfandrianto@google.com, azani@chromium.org

[rudominer, 2016-02-23 16:56:29]

Hi Alex and Alex, 

ptal.

-Mitch

[azani, 2016-02-23 19:02:49]

lgtm

[alexfandrianto, 2016-02-23 21:19:31]

On 2016/02/23 19:02:49, azani wrote:
> lgtm

This looks like it'll be fine. I believe we can adapt on our end without much
headache. That said, can you prioritize the Dart-version of this CL? If Go and
Dart are out of sync, I won't be able to update the v23proxy implementation. If
possible, can you hold off on submitting this CL until Dart's is ready?

[alexfandrianto, 2016-02-23 21:19:47]

https://codereview.chromium.org/1719873003/diff/180001/mojo/go/tests/validati...
File mojo/go/tests/validation_type_test.go (right):

https://codereview.chromium.org/1719873003/diff/180001/mojo/go/tests/validati...
mojo/go/tests/validation_type_test.go:25: // in mojom/mojom_descriptor.go in the
Mojom parser source code.
We'll also take this into account too on our end. Is there a good place to put
this function so that it's always accessible?

https://codereview.chromium.org/1719873003/diff/180001/mojo/go/tests/validati...
mojo/go/tests/validation_type_test.go:112: 0: "struct_d",
Swapping to lowercase_with_underscores will affect our proxy, but I think it'll
end up being okay if we add a function to convert and compare UpperCamelCase
only

https://codereview.chromium.org/1719873003/diff/180001/mojo/go/tests/validati...
mojo/go/tests/validation_type_test.go:156: t.Fatalf("StructField for %s at
ordinal %d had ShortName %s, expecting %s", structID, i,
*field.DeclData.ShortName, expectedFieldShortName)
*field.DeclData.ShortName could easily panic, but maybe that's not a problem if
we're t.Fatalf ing here anyway

https://codereview.chromium.org/1719873003/diff/180001/mojo/go/tests/validati...
mojo/go/tests/validation_type_test.go:168: expectedReferenceID := "StructD"
It looks like the identifier/referenceID now is the shortname.

https://codereview.chromium.org/1719873003/diff/180001/mojo/public/tools/bind...
File mojo/public/tools/bindings/generators/mojom_go_generator.py (left):

https://codereview.chromium.org/1719873003/diff/180001/mojo/public/tools/bind...
mojo/public/tools/bindings/generators/mojom_go_generator.py:328: 'mojom_type':
GetMojomTypeValue,
I think a lot of these filters don't need to be here anymore, if the templates
are removed.

For example, fullidentifier and mojom_type don't seem like they'd be needed.

[rudominer, 2016-02-23 21:31:52]

On 2016/02/23 21:19:31, alexfandrianto wrote:
> On 2016/02/23 19:02:49, azani wrote:
> > lgtm
> 
> This looks like it'll be fine. I believe we can adapt on our end without much
> headache. That said, can you prioritize the Dart-version of this CL? If Go and
> Dart are out of sync, I won't be able to update the v23proxy implementation.
If
> possible, can you hold off on submitting this CL until Dart's is ready?

This code only changed implementation details that your code should not be
depending on. Let's try to figure out how to change the V23 proxy so as not to
depend on these implementation details. I will set up a meeting for tomorrow.

[rudominer, 2016-02-23 21:32:22]

alexfandrianto: Please take a look at my responses to your comments.

https://codereview.chromium.org/1719873003/diff/180001/mojo/go/tests/validati...
File mojo/go/tests/validation_type_test.go (right):

https://codereview.chromium.org/1719873003/diff/180001/mojo/go/tests/validati...
mojo/go/tests/validation_type_test.go:25: // in mojom/mojom_descriptor.go in the
Mojom parser source code.
On 2016/02/23 21:19:46, alexfandrianto wrote:
> We'll also take this into account too on our end. Is there a good place to put
> this function so that it's always accessible?

No, your code should not be constructing type keys. Can you explain why your
code needs to construct type keys?

https://codereview.chromium.org/1719873003/diff/180001/mojo/go/tests/validati...
mojo/go/tests/validation_type_test.go:112: 0: "struct_d",
On 2016/02/23 21:19:46, alexfandrianto wrote:
> Swapping to lowercase_with_underscores will affect our proxy, but I think
it'll
> end up being okay if we add a function to convert and compare UpperCamelCase
> only

But we are not "swapping" anything. The definition of the identifier is the
string that is used in the .mojom file.

https://codereview.chromium.org/1719873003/diff/180001/mojo/go/tests/validati...
mojo/go/tests/validation_type_test.go:168: expectedReferenceID := "StructD"
On 2016/02/23 21:19:47, alexfandrianto wrote:
> It looks like the identifier/referenceID now is the shortname.

the "Identifier" field of a reference is by definition whatever string was used
at the site of the reference in the .mojom file.

[alexfandrianto, 2016-02-23 22:00:04]

https://codereview.chromium.org/1719873003/diff/180001/mojo/go/tests/validati...
File mojo/go/tests/validation_type_test.go (right):

https://codereview.chromium.org/1719873003/diff/180001/mojo/go/tests/validati...
mojo/go/tests/validation_type_test.go:25: // in mojom/mojom_descriptor.go in the
Mojom parser source code.
On 2016/02/23 21:32:22, rudominer wrote:
> On 2016/02/23 21:19:46, alexfandrianto wrote:
> > We'll also take this into account too on our end. Is there a good place to
put
> > this function so that it's always accessible?
> 
> No, your code should not be constructing type keys. Can you explain why your
> code needs to construct type keys?

In order to convert between VDL/vom and mojom, we need to remember to keep track
of package path (or module) information separately. So if we go from VDL/vom to
mojom, we'll need to reconstruct these mojom type keys from the package path.

https://codereview.chromium.org/1719873003/diff/180001/mojo/go/tests/validati...
mojo/go/tests/validation_type_test.go:112: 0: "struct_d",
On 2016/02/23 21:32:22, rudominer wrote:
> On 2016/02/23 21:19:46, alexfandrianto wrote:
> > Swapping to lowercase_with_underscores will affect our proxy, but I think
> it'll
> > end up being okay if we add a function to convert and compare UpperCamelCase
> > only
> 
> But we are not "swapping" anything. The definition of the identifier is the
> string that is used in the .mojom file.

The swap I'm referring to is how the old value was guaranteed to be
UpperCamelCase but now is no longer the case. This isn't an actual problem with
your implementation, but it is an observation on what we'll have to change on
our end. VDL requires that all fields be UpperCamelCase, so that means our
UpperCamelCase normalization will have to occur in our proxy instead of in the
generated mojom type info code.

[rudominer, 2016-02-24 00:03:01]

https://codereview.chromium.org/1719873003/diff/180001/mojo/go/tests/validati...
File mojo/go/tests/validation_type_test.go (right):

https://codereview.chromium.org/1719873003/diff/180001/mojo/go/tests/validati...
mojo/go/tests/validation_type_test.go:25: // in mojom/mojom_descriptor.go in the
Mojom parser source code.
On 2016/02/23 22:00:04, alexfandrianto wrote:
> On 2016/02/23 21:32:22, rudominer wrote:
> > On 2016/02/23 21:19:46, alexfandrianto wrote:
> > > We'll also take this into account too on our end. Is there a good place to
> put
> > > this function so that it's always accessible?
> > 
> > No, your code should not be constructing type keys. Can you explain why your
> > code needs to construct type keys?
> 
> In order to convert between VDL/vom and mojom, we need to remember to keep
track
> of package path (or module) information separately. So if we go from VDL/vom
to
> mojom, we'll need to reconstruct these mojom type keys from the package path.
You can explain the situation in more detail to me tomorrow in person but the
type keys are supposed to be opaque. Why can't you store the type key of an
object along with its fully-qualified name?

https://codereview.chromium.org/1719873003/diff/180001/mojo/go/tests/validati...
mojo/go/tests/validation_type_test.go:112: 0: "struct_d",
On 2016/02/23 22:00:04, alexfandrianto wrote:
> On 2016/02/23 21:32:22, rudominer wrote:
> > On 2016/02/23 21:19:46, alexfandrianto wrote:
> > > Swapping to lowercase_with_underscores will affect our proxy, but I think
> > it'll
> > > end up being okay if we add a function to convert and compare
UpperCamelCase
> > > only
> > 
> > But we are not "swapping" anything. The definition of the identifier is the
> > string that is used in the .mojom file.
> 
> The swap I'm referring to is how the old value was guaranteed to be
> UpperCamelCase but now is no longer the case. This isn't an actual problem
with
> your implementation, but it is an observation on what we'll have to change on
> our end. VDL requires that all fields be UpperCamelCase, so that means our
> UpperCamelCase normalization will have to occur in our proxy instead of in the
> generated mojom type info code.

Acknowledged.

[rudominer, 2016-02-24 01:49:01]

Patchset #3 (id:200001) has been deleted

[rudominer, 2016-02-24 02:06:53]

The latest two patchsets include the following changes:

- I responded to some of @alexfandrianto's comments. Alex F ptal.

- I have added a mojom_type_key field to the ReferenceKind type in module.py and
populated it in mojom_translator.py. I think we will need for the generated Go
types to be able to access their own type_key's. I have not implemented how this
will work pending meetings tomorrow. Alex Z ptal.

https://codereview.chromium.org/1719873003/diff/180001/mojo/go/tests/validati...
File mojo/go/tests/validation_type_test.go (right):

https://codereview.chromium.org/1719873003/diff/180001/mojo/go/tests/validati...
mojo/go/tests/validation_type_test.go:156: t.Fatalf("StructField for %s at
ordinal %d had ShortName %s, expecting %s", structID, i,
*field.DeclData.ShortName, expectedFieldShortName)
On 2016/02/23 21:19:46, alexfandrianto wrote:
> *field.DeclData.ShortName could easily panic, but maybe that's not a problem
if
> we're t.Fatalf ing here anyway

Done.

https://codereview.chromium.org/1719873003/diff/180001/mojo/public/tools/bind...
File mojo/public/tools/bindings/generators/mojom_go_generator.py (left):

https://codereview.chromium.org/1719873003/diff/180001/mojo/public/tools/bind...
mojo/public/tools/bindings/generators/mojom_go_generator.py:328: 'mojom_type':
GetMojomTypeValue,
On 2016/02/23 21:19:47, alexfandrianto wrote:
> I think a lot of these filters don't need to be here anymore, if the templates
> are removed.
> 
> For example, fullidentifier and mojom_type don't seem like they'd be needed.

Done.

[alexfandrianto, 2016-02-25 00:38:07]

On 2016/02/24 02:06:53, rudominer wrote:
> The latest two patchsets include the following changes:
> 
> - I responded to some of @alexfandrianto's comments. Alex F ptal.
> 
> - I have added a mojom_type_key field to the ReferenceKind type in module.py
and
> populated it in mojom_translator.py. I think we will need for the generated Go
> types to be able to access their own type_key's. I have not implemented how
this
> will work pending meetings tomorrow. Alex Z ptal.
> 
>
https://codereview.chromium.org/1719873003/diff/180001/mojo/go/tests/validati...
> File mojo/go/tests/validation_type_test.go (right):
> 
>
https://codereview.chromium.org/1719873003/diff/180001/mojo/go/tests/validati...
> mojo/go/tests/validation_type_test.go:156: t.Fatalf("StructField for %s at
> ordinal %d had ShortName %s, expecting %s", structID, i,
> *field.DeclData.ShortName, expectedFieldShortName)
> On 2016/02/23 21:19:46, alexfandrianto wrote:
> > *field.DeclData.ShortName could easily panic, but maybe that's not a problem
> if
> > we're t.Fatalf ing here anyway
> 
> Done.
> 
>
https://codereview.chromium.org/1719873003/diff/180001/mojo/public/tools/bind...
> File mojo/public/tools/bindings/generators/mojom_go_generator.py (left):
> 
>
https://codereview.chromium.org/1719873003/diff/180001/mojo/public/tools/bind...
> mojo/public/tools/bindings/generators/mojom_go_generator.py:328: 'mojom_type':
> GetMojomTypeValue,
> On 2016/02/23 21:19:47, alexfandrianto wrote:
> > I think a lot of these filters don't need to be here anymore, if the
templates
> > are removed.
> > 
> > For example, fullidentifier and mojom_type don't seem like they'd be needed.
> 
> Done.

lgtm

[azani, 2016-02-25 01:28:55]

lgtm

[rudominer, 2016-02-25 17:25:26]

Description was changed from

==========
Mojom runtime type info: New implementation for Go.

Our implementation of runtime type information is changing and this CL
implements the change for Go. The older implementation still exists for Dart.
(Those are the only two languages for which the runtime type info has yet been
implemented.)

In the older implementation the runtime type structures are computed and
constructed by the code generators (thus in Python and the Jinja 2 templates). 
In this newer implementation the Mojom parser computes the information and
stores it in a mojom_types.RuntimeTypeInfo
structure. Then the code generators insert a literal array of bytes representing
a serialized RuntimeTypeInfo into the generated Go code. At runtime all a Mojo
application needs to do
is deserialize the RuntimeTypeInfo struct and use it to answer queries.

- In mojom_translator.py copy serialized_runtime_type_info into the
mojom.Module.
- In mojom_go_generator.py we compute a Go literal string defining this array of
bytes.
- In source.tmpl we generate Go code to deserialize this array of bytes into a
RuntimeTypeInfo
struct and use this struct to answer queries about runtime type info.
- We delete the old implementation from source.tmpl and delete the files
mojom_reference_macros.tmpl
and mojom_type_macros.tmpl.
- We fix up validation_type_test.go in accordance with these changes. The main
change is that we use the format
of the type key currently being generated by the mojom parser. Also the old
implementation was apparently
setting field names in DeclData incorrectly so we modify the tests to look for
the correct names.
- The new implementation does not support generating the function
GetTopLevelInterface() on interfaces that
are not top-level interfaces. Therefore we add the "ServiceName" annotation to
the interface that is being
used to test this function: the BoundsCheckTestInterface in
validation_test_interfaces.mojom.

BUG=448
==========

to

==========
Mojom runtime type info: New implementation for Go.

Our implementation of runtime type information is changing and this CL
implements the change for Go. The older implementation still exists for Dart.
(Those are the only two languages for which the runtime type info has yet been
implemented.)

In the older implementation the runtime type structures are computed and
constructed by the code generators (thus in Python and the Jinja 2 templates).
In this newer implementation the Mojom parser computes the information and
stores it in a mojom_types.RuntimeTypeInfo
structure. Then the code generators insert a literal array of bytes representing
a serialized RuntimeTypeInfo into the generated Go code. At runtime all a Mojo
application needs to do
is deserialize the RuntimeTypeInfo struct and use it to answer queries.

- In mojom_translator.py copy serialized_runtime_type_info into the
mojom.Module.
- In mojom_go_generator.py we compute a Go literal string defining this array of
bytes.
- In source.tmpl we generate Go code to deserialize this array of bytes into a
RuntimeTypeInfo
struct and use this struct to answer queries about runtime type info.
- We delete the old implementation from source.tmpl and delete the files
mojom_reference_macros.tmpl
and mojom_type_macros.tmpl.
- We fix up validation_type_test.go in accordance with these changes. The main
change is that we use the format
of the type key currently being generated by the mojom parser. Also the old
implementation was apparently
setting field names in DeclData incorrectly so we modify the tests to look for
the correct names.
- The new implementation does not support generating the function
GetTopLevelInterface() on interfaces that
are not top-level interfaces. Therefore we add the "ServiceName" annotation to
the interface that is being
used to test this function: the BoundsCheckTestInterface in
validation_test_interfaces.mojom.

BUG=448
R=alexfandrianto@google.com, azani@chromium.org

Committed:
https://chromium.googlesource.com/external/mojo/+/4970253149a7bc1d057c13fd8f1...
==========

[rudominer, 2016-02-25 17:25:27]

Committed patchset #5 (id:260001) manually as
4970253149a7bc1d057c13fd8f173f2c795b3bfd (presubmit successful).

[rudominer, 2016-02-26 16:21:27]

Description was changed from

==========
Mojom runtime type info: New implementation for Go.

Our implementation of runtime type information is changing and this CL
implements the change for Go. The older implementation still exists for Dart.
(Those are the only two languages for which the runtime type info has yet been
implemented.)

In the older implementation the runtime type structures are computed and
constructed by the code generators (thus in Python and the Jinja 2 templates).
In this newer implementation the Mojom parser computes the information and
stores it in a mojom_types.RuntimeTypeInfo
structure. Then the code generators insert a literal array of bytes representing
a serialized RuntimeTypeInfo into the generated Go code. At runtime all a Mojo
application needs to do
is deserialize the RuntimeTypeInfo struct and use it to answer queries.

- In mojom_translator.py copy serialized_runtime_type_info into the
mojom.Module.
- In mojom_go_generator.py we compute a Go literal string defining this array of
bytes.
- In source.tmpl we generate Go code to deserialize this array of bytes into a
RuntimeTypeInfo
struct and use this struct to answer queries about runtime type info.
- We delete the old implementation from source.tmpl and delete the files
mojom_reference_macros.tmpl
and mojom_type_macros.tmpl.
- We fix up validation_type_test.go in accordance with these changes. The main
change is that we use the format
of the type key currently being generated by the mojom parser. Also the old
implementation was apparently
setting field names in DeclData incorrectly so we modify the tests to look for
the correct names.
- The new implementation does not support generating the function
GetTopLevelInterface() on interfaces that
are not top-level interfaces. Therefore we add the "ServiceName" annotation to
the interface that is being
used to test this function: the BoundsCheckTestInterface in
validation_test_interfaces.mojom.

BUG=448
R=alexfandrianto@google.com, azani@chromium.org

Committed:
https://chromium.googlesource.com/external/mojo/+/4970253149a7bc1d057c13fd8f1...
==========

to

==========
Mojom runtime type info: New implementation for Go.

Our implementation of runtime type information is changing and this CL
implements the change for Go. The older implementation still exists for Dart.
(Those are the only two languages for which the runtime type info has yet been
implemented.)

In the older implementation the runtime type structures are computed and
constructed by the code generators (thus in Python and the Jinja 2 templates).
In this newer implementation the Mojom parser computes the information and
stores it in a mojom_types.RuntimeTypeInfo
structure. Then the code generators insert a literal array of bytes representing
a serialized RuntimeTypeInfo into the generated Go code. At runtime all a Mojo
application needs to do
is deserialize the RuntimeTypeInfo struct and use it to answer queries.

- In mojom_translator.py copy serialized_runtime_type_info into the
mojom.Module.
- In mojom_go_generator.py we compute a Go literal string defining this array of
bytes.
- In source.tmpl we generate Go code to deserialize this array of bytes into a
RuntimeTypeInfo
struct and use this struct to answer queries about runtime type info.
- We delete the old implementation from source.tmpl and delete the files
mojom_reference_macros.tmpl
and mojom_type_macros.tmpl.
- We fix up validation_type_test.go in accordance with these changes. The main
change is that we use the format
of the type key currently being generated by the mojom parser. Also the old
implementation was apparently
setting field names in DeclData incorrectly so we modify the tests to look for
the correct names.
- The new implementation does not support generating the function
GetTopLevelInterface() on interfaces that
are not top-level interfaces. Therefore we add the "ServiceName" annotation to
the interface that is being
used to test this function: the BoundsCheckTestInterface in
validation_test_interfaces.mojom.

BUG=#448
R=alexfandrianto@google.com, azani@chromium.org

Committed:
https://chromium.googlesource.com/external/mojo/+/4970253149a7bc1d057c13fd8f1...
==========