TL;DR I think that the definition of t_const_value in plugin.thrift needs to change, in an incompatible way, so that it can properly carry all the information from the compiler to plugins. Thoughts? Adivce?
I was trying to understand the meaning of all the fields in plugin.thrift's messages, and found a discrepancy in t_const_value. The Thrift struct implies that "enum" is an *alternative*. But the code in both thrift.yy and in t_const_value.h tell a different story: there, the enum and the identifier_val go together, and are used to -compute- the integer_val for code-emitting. At the time when it comes for creating GeneratorInput, both the identifier_val and the enum are copied over into the "union". I've verified these assertions by: (a) adding code to plugin_output.cc, in the converter for t_const_value, to check that if the const_value is an identifier, then the enum_ member variable is set. (b) adding code to the Ocaml generator (t_ocaml_generator::render_const_value) to do the same check (c) writing a C++ "deserializer" to take the plugin GeneratorInput and dump it out in JSON, where I can see the enum_val came thru in the field below: { "struct_val": { "is_union": false, "is_xception": false, "members": [ { "key": 1, "name": "e", "reference": false, "req": "T_OPT_IN_REQ_OUT", "type": "1000000", "value": { "enum_val": "1000000", "identifier_val": "E.C" } } ], "metadata": { "annotations": {}, "name": "Urk", "program_id": "1000000" } } } (d) writing the same in Ocaml, again deserializing, to verify that the value has two different fields. it sure seems like this is a bug, not noticed b/c no plugin does anything nontrivial with the data? --chet--