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--