[Rust] Generated code is inconsistent for fields named type
#5052
Labels
Comments
kszucs
pushed a commit
to apache/arrow
that referenced
this issue
Apr 8, 2019
I generated the IPC code after installing the flatbuffers release available via conda but still had to manually modify the code to make it compile due to these issues with flatbuffers: google/flatbuffers#5052 google/flatbuffers#5053 google/flatbuffers#5054 I think this is the best we can do for now. Author: Andy Grove <[email protected]> Closes #4021 from andygrove/rust-ipc and squashes the following commits: 7a549be <Andy Grove> encode field data type ab769bb <Andy Grove> delete file a81bee9 <Andy Grove> fix CI 1bbc4a7 <Andy Grove> Update README 83f3b4c <Andy Grove> Add generated IPC code
|
This issue has been automatically marked as stale because it has not had activity for 6 months. It will be closed if no further activity occurs. Thank you for your contributions. |
alamb
pushed a commit
to apache/arrow-rs
that referenced
this issue
Apr 20, 2021
I generated the IPC code after installing the flatbuffers release available via conda but still had to manually modify the code to make it compile due to these issues with flatbuffers: google/flatbuffers#5052 google/flatbuffers#5053 google/flatbuffers#5054 I think this is the best we can do for now. Author: Andy Grove <[email protected]> Closes #4021 from andygrove/rust-ipc and squashes the following commits: 7a549be9e <Andy Grove> encode field data type ab769bba5 <Andy Grove> delete file a81bee9b3 <Andy Grove> fix CI 1bbc4a76b <Andy Grove> Update README 83f3b4c06 <Andy Grove> Add generated IPC code
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Language: Rust
Operating System: Ubuntu 16.04
Gcc: 5.4.0
I used Flatbuffers as of commit 2159191 to generate code from the Schema.fbs file in Apache Arrow (https://github.com/apache/arrow/blob/master/format/Schema.fbs) and the generated code would not compile. There were inconsistencies around code generated for the field named
type(I'm guessing this might be a reserved word issue).The generated code sometimes refered to
type__type(two underscores) and sometimestype_type(one underscore). I manually performed a search and replace to standardize on the single underscore version and the code then compiled.The text was updated successfully, but these errors were encountered: