Add enum class support to json_schema_compiler (idl files)

tools/json_schema_compiler/test/idl_basics.idl

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 // Tests a variety of basic API definition features.
 
 [internal] namespace idl_basics {
   // Enum description
   enum EnumType {
     // comment1
     name1,
     name2
   };
 
   [nodoc] enum EnumTypeWithNoDoc {
     name1,
     name2
   };
 
+  [cpp_enum_prefix_override="prefix"] enum EnumWithPrefix {

[Devlin, 2016/05/17 19:04:10]

Do we want to support prefixes for vanilla enums?  What's the use case?

[tapted, 2016/05/18 09:35:54]

Ah, it's actually the prefixes for class-enums that I wasn't sure about :).
prefixes are used already in ax_enums.idl. E.g., there it has:

[cpp_enum_prefix_override="ax_attr"] enum AXStringAttribute {
    access_key,
  ...
}

[cpp_enum_prefix_override="ax_attr"] enum AXIntAttribute {
    scroll_x,
  ...
}

These generate

AX_ATTR_ACCESS_KEY
AX_ATTR_SCROLL_X


When these switch directly to enum classes, currently the approach will be

AXStringAttribute::AX_ATTR_ACCESS_KEY
AXIntAttribute::AX_ATTR_SCROLL_X


or the prefix could be removed to become

AXStringAttribute::ACCESS_KEY
AXIntAttribute::SCROLL_X


or -- depending how they're used -- we could merge them, and just have

AXAttr::ACCESS_KEY
AXAttr::SCROLL_X


But that might violate some use cases -- perhaps there is type matching for
overloads somewhere.


Perhaps for these it would make sense to keep them as non-class enums and turn
cpp_enum_prefix_override+enum_class into a hard error. For now I didn't really
add anything special, but just ensured it wouldn't fail. And if somewhere
there's a preference to have an additional FOO_ prefix on class enums too, then
that's supported.

+    name1,
+    name2
+  };
+
+  [class] enum EnumClass {
+    name1,
+    name2
+  };
+
+  [class,cpp_enum_prefix_override="prefix"] enum EnumClassWithPrefix {

[Devlin, 2016/05/17 19:04:10]

nit: cpp_enum_prefix_override is quite a mouthful.  Maybe just "prefix"? 
Conversely, [class] actually seems not-as-descriptive - maybe [use_class] or a
full [enum_class]?

These are just my opinions, and don't really affect all that much, so I'll leave
it up to you.

[tapted, 2016/05/18 09:35:54]

Yup I agree 'class' is a bit terse - went with enum_class.

changing cpp_enum_prefix_override would alter some idl files, so is a bit
orthogonal. (I just wanted to ensure there was some test coverage for this
existing use case :).

+    name1,
+    name2
+  };
+
   dictionary MyType1 {
     // This comment tests "double-quotes".
     [legalValues=(1,2)] long x;
     DOMString y;
     DOMString z;
     DOMString a;
     DOMString b;
     DOMString c;
   };
 
   dictionary MyType2 {
     DOMString x;
   };
 
+  dictionary MyType3 {
+    EnumType w;
+    EnumWithPrefix x;
+    EnumClass y;
+    EnumClassWithPrefix z;
+  };
+
   dictionary UnionType {
     (EnumType or DOMString)? x;
     (DOMString or EnumType) y;
   };
 
   callback Callback1 = void();
   callback Callback2 = void(long x);
   callback Callback3 = void(MyType1 arg);
   callback Callback4 = void(MyType2[] arg);
   callback Callback5 = void(EnumType type);
@@ skipping 60 matching lines @@
     [nodefine] static void function31(long switch);
   };
 
   interface Events {
     static void onFoo1();
     static void onFoo2(long x);
     static void onFoo2(MyType1 arg);
     static void onFoo3(EnumType type);
   };
 };