> I’m not sure how to it works with Flex & Bison

Yes. If it would not, its the wrong tool.

See also https://issues.apache.org/jira/browse/THRIFT-5626 I'm on it already.


Am 10.09.2022 um 11:16 schrieb Triton Circonflexe:
I’m not sure how to it works with Flex & Bison but there should be a way to
indicate that if the word in context should not be a specific token (in
this case, it’s not reserved), then the parser should fallback to interpret
it as something else (in this case, an identifier).

At the moment, every simple type name (i8…i64, binary, …) is considered to
be a reserved word even if the specification does not list them as such.

Le ven. 9 sept. 2022 à 23:27, Jens Geyer <jensge...@hotmail.com> a écrit :

I would say that the parser is broken then. Why should I not be able to
call my field "uuid"?


Am 09.09.2022 um 21:41 schrieb Duru Can Celasun:
Agreed. It seems a new reserved word is unavoidable, so let's at least
prefix it.
On Fri, 9 Sep 2022, at 18:30, Yuxuan Wang wrote:
If making it not a reserved word is infeasible, my next suggestion
would be
to rename it to something like "tuuid" (similar to how we prefix t to a
lot
of the names).

It would still be a big breaking change if someone have a thrift file
with
a field/type named tuuid, but that's far less likely compare to the name
uuid.

On Fri, Sep 9, 2022 at 10:24 AM Yuxuan Wang <yuxuan.w...@reddit.com>
wrote:
I was trying the compiler from the latest master branch, and got this
error on one of our existing thrift files:

[ERROR:/path/to/file.thrift:182] (last token was 'uuid')

The line is basically a field named uuid:

    40: optional string uuid,

So I think what happens is that uuid is now a reserved word of thrift,
and
we can no longer use it as the name of a field/struct/etc. (the same
as we
cannot name a field "string" or "i64")

This is a big problem. This means that old thrift file no longer
compiles
without modification (uuid is likely a commonly used field name right
now
when we actually needs an uuid there), and renaming an existing field
is
also a breaking change (it means all the code have to be changed to
accommodate the new field name).

I'm not sure how feasible it is to make it not a reserved word?


Reply via email to