You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by Chet Murthy <mu...@gmail.com> on 2017/11/30 06:27:57 UTC
Question about t_const_value in plugin.thrift (and its relation to
t_const_value in compiler/..../parse)
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--