thrift-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (THRIFT-4617) Avoid generating conflicting struct names in Rust code
Date Tue, 28 Aug 2018 18:45:00 GMT

    [ https://issues.apache.org/jira/browse/THRIFT-4617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16595424#comment-16595424
] 

ASF GitHub Bot commented on THRIFT-4617:
----------------------------------------

flavray commented on a change in pull request #1578: THRIFT-4617: Prepend service-specific
struct names with service name
URL: https://github.com/apache/thrift/pull/1578#discussion_r213429769
 
 

 ##########
 File path: compiler/cpp/src/thrift/generate/t_rs_generator.cc
 ##########
 @@ -2411,6 +2415,11 @@ string t_rs_generator::struct_to_invocation(t_struct* tstruct, const
string& fie
   return args.str();
 }
 
+void t_rs_generator::render_args_struct(t_function* tfunc) {
+    string args_struct_name = service_call_args_struct_name(tfunc);
 
 Review comment:
   Ah thanks, good point! C++ is not my mother tongue 😄

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


> Avoid generating conflicting struct names in Rust code
> ------------------------------------------------------
>
>                 Key: THRIFT-4617
>                 URL: https://issues.apache.org/jira/browse/THRIFT-4617
>             Project: Thrift
>          Issue Type: Bug
>          Components: Rust - Compiler
>            Reporter: Flavien Raynaud
>            Priority: Minor
>             Fix For: 0.12.0
>
>
> If a thrift definition file contains multiple services, with functions having the same
name, the generated code is not valid. There are conflicting definitions of {{*Args}} and
{{*Result}} structs.
> {noformat}
> service backend {
>   i32 send(
>     1: i32 arg
>   );
> }
> service other_backend {
>   string send(
>     1: i32 arg
>   )
> }
> {noformat}
> Will generate the following code in the same file (I only pasted the interesting bits):
> {noformat}
> struct SendResult {
>   result_value: Option<i32>,
> }
> // ...
> struct SendResult {
>   result_value: Option<String>,
> }
> {noformat}
> And rustc would complain with errors like:
> {noformat}
> error[E0428]: the name `SendResult` is defined multiple times
>    --> src/test.rs:496:1
>     |
> 234 | struct SendResult {
>     | ----------------- previous definition of the type `SendResult` here
> ...
> 496 | struct SendResult {
>     | ^^^^^^^^^^^^^^^^^ `SendResult` redefined here
>     |
>     = note: `SendResult` must be defined only once in the type namespace of this module
> {noformat}
> ----
> Another (very similar) issue occurs if a user-defined struct happens to be called (keeping
the same example as before) {{SendResult}}:
> {noformat}
> struct SendResult {
>     1: i32 resultCode,
>     2: optional string errorCause,
> }
> service backend {
>   SendResult send(
>     1: i32 arg
>   );
> }
> {noformat}
> Will generate the following code in the same file (I only pasted the interesting bits)::
> {noformat}
> pub struct SendResult {
>   pub result_code: Option<i32>,
>   pub error_cause: Option<String>,
> }
> // ...
> struct SendResult {
>   result_value: Option<SendResult>,
> }
> {noformat}
> Again, conflicting definitions of structs and rustc would complain.
> ----
> The approach taken by the Go generator (I haven't looked at other languages too much,
some other generators probably do the same) for generating internal structs related to a service
call is to [prepend the service name|https://github.com/apache/thrift/blob/master/compiler/cpp/src/thrift/generate/t_go_generator.cc#L502]
to each of the structs.
>  Using the same mechanism would solve both the issues cited above.
> I will give it a try and open a PR, but am also definitely open to any feedback on the
idea :)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message