Mailing-List: contact dev-help@thrift.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@thrift.apache.org
MIME-Version: 1.0
From: Chet Murthy <murthy.chet@gmail.com>
Date: Wed, 29 Nov 2017 22:27:57 -0800
Message-ID: <CA++P_gep6tNZT26zG+33T-ofyyASHx2RgVRY=JfoiG7ypCC3VA@mail.gmail.com>
Subject: Question about t_const_value in plugin.thrift (and its relation to
 t_const_value in compiler/..../parse)
To: dev@thrift.apache.org
Content-Type: multipart/alternative; boundary="089e0828f4b4604f58055f2d5a81"
archived-at: Thu, 30 Nov 2017 06:28:03 -0000

--089e0828f4b4604f58055f2d5a81
Content-Type: text/plain; charset="UTF-8"

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

--089e0828f4b4604f58055f2d5a81--