Allow Mojo structs as map keys

mojo/public/tools/bindings/generators/cpp_templates/struct_traits_declaration.tmpl

Index: mojo/public/tools/bindings/generators/cpp_templates/struct_traits_declaration.tmpl
diff --git a/mojo/public/tools/bindings/generators/cpp_templates/struct_traits_declaration.tmpl b/mojo/public/tools/bindings/generators/cpp_templates/struct_traits_declaration.tmpl
index 24efbd5531064d623c8922793359cd78f98022ac..82af93720fd02340daf4dfb2b720decc65fe6fda 100644
--- a/mojo/public/tools/bindings/generators/cpp_templates/struct_traits_declaration.tmpl
+++ b/mojo/public/tools/bindings/generators/cpp_templates/struct_traits_declaration.tmpl
@@ -9,9 +9,12 @@ struct {{export_attribute}} StructTraits<{{mojom_type}}::DataView,
 {%- for field in struct.fields %}
 {%-   set return_ref = field.kind|is_object_kind or
                        field.kind|is_any_handle_or_interface_kind %}
+{#    We want the field accessor to be const whenever possible to allow #}
+{#    structs to be used as map keys. #}
+{%-   set const = "" if field.kind|contains_handles else "const" %}

[yzshen1, 2016/09/20 23:44:40]

Does it make sense to name this variable "maybe_const"? Otherwise, at a glance
people may think {{const}} always means "const".

FYI, although it may be a corner case that we don't want to worry about, "not
containing handles" doesn't necessarily mean that "it can be serialized with a
const ref". For example:
// Mojom type:
struct Foo { Bar bar; }

// typemapping:
Foo=CustomFoo[copyable_pass_by_value]

// StructTraits<FooDataView, CustomFoo>:
...
static const Bar& bar(CustomFoo& foo); // Use a non-const ref as input, maybe it
wants to modify |foo| in-place.

In this case, an auto-generated struct having a Foo field will fail to compile.

But I think this is probably a corner case that no one will care about.

[tibell, 2016/09/21 07:10:53]

Done.
I'll leave a TODO for now. Do you have any idea how to detect this case and
generate the right constness for it?

[yzshen1, 2016/09/21 23:17:52]

It would require adding new attribute in typemap config files. I think it is
pretty low priority. We could revisit it when there is an actual use case, which
should be pretty rare.

It is up to you whether to leave a TODO. (If you decide to leave one,) it seems
a little more clear to say "... e.g., custom types which don't contain handles
but require non-const reference for serialization." WDYT?

[tibell, 2016/09/22 05:17:23]

Done.

 {%-   if return_ref %}
-  static decltype({{mojom_type}}::{{field.name}})& {{field.name}}(
-      {{mojom_type}}Ptr& input) {
+  static {{const}} decltype({{mojom_type}}::{{field.name}})& {{field.name}}(
+      {{const}} {{mojom_type}}Ptr& input) {
     return input->{{field.name}};
   }
 {%-   else %}