thrift-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Allen George (Jira)" <j...@apache.org>
Subject [jira] [Comment Edited] (THRIFT-4098) Support user-defined output namespaces in generated Rust modules
Date Thu, 19 Nov 2020 14:40:00 GMT

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

Allen George edited comment on THRIFT-4098 at 11/19/20, 2:39 PM:
-----------------------------------------------------------------

Copying comment from THRIFT-5071:

One can't place thrift files that are dependent on each other in an arbitrary directory structure,
because the generated {{use ...}} declarations assume that all thrift files are in the same
location. For this situation, I *think* the problem is as follows. Consider:

{noformat}
root
+- common.thrift
+- dir1
   +- dependent_1_on_common.thrift
   +- ...
+- dir2
   +- dependent_2_on_common.thrift
   +- ...
{noformat}

The problem here is that the generated {{dependent_1_on_common.rs}} and {{dependent_2_on_common.rs}}
all would have declarations like:

{noformat}

// Autogenerated by Thrift Compiler (0.14.0)
// DO NOT EDIT UNLESS YOU ARE SURE THAT YOU KNOW WHAT YOU ARE DOING

#![allow(unused_imports)]
#![allow(unused_extern_crates)]
#![cfg_attr(feature = "cargo-clippy", allow(too_many_arguments, type_complexity))]
#![cfg_attr(rustfmt, rustfmt_skip)]

use crate::common; <---- PROBLEMATIC LINE

...

{noformat}

that would obviously break because their location in the rust/filesystem module hierarchy
is not reflected in the thrift-generated code. Assuming the compiler has the information,
I *think* this would be solved by including the Thrift namespace of the *dependent* file in
the generated {{use}} expressions in the *dependee*.


was (Author: allengeorge):
Copying comment from THRIFT-5071:
One can't place thrift files that are dependent on each other in an arbitrary directory structure,
because the generated {{use ...}} declarations assume that all thrift files are in the same
location. For this situation, I *think* the problem is as follows. Consider:

{noformat}
root
+- common.thrift
+- dir1
   +- dependent_1_on_common.thrift
   +- ...
+- dir2
   +- dependent_2_on_common.thrift
   +- ...
{noformat}

The problem here is that the generated {{dependent_1_on_common.rs}} and {{dependent_2_on_common.rs}}
all would have declarations like:

{noformat}

// Autogenerated by Thrift Compiler (0.14.0)
// DO NOT EDIT UNLESS YOU ARE SURE THAT YOU KNOW WHAT YOU ARE DOING

#![allow(unused_imports)]
#![allow(unused_extern_crates)]
#![cfg_attr(feature = "cargo-clippy", allow(too_many_arguments, type_complexity))]
#![cfg_attr(rustfmt, rustfmt_skip)]

use crate::common; <---- PROBLEMATIC LINE

...

{noformat}

that would obviously break because their location in the rust/filesystem module hierarchy
is not reflected in the thrift-generated code. Assuming the compiler has the information,
I *think* this would be solved by including the Thrift namespace of the *dependent* file in
the generated {{use}} expressions in the *dependee*.

> Support user-defined output namespaces in generated Rust modules
> ----------------------------------------------------------------
>
>                 Key: THRIFT-4098
>                 URL: https://issues.apache.org/jira/browse/THRIFT-4098
>             Project: Thrift
>          Issue Type: Improvement
>          Components: Rust - Compiler
>            Reporter: Allen George
>            Priority: Minor
>
> Currently the Rust compiler assumes that all generated modules are rooted at the top-level
of your crate (i.e. at {{lib.rs}}). There are many useful cases where you want to control
exactly where the generated code lives (for example - you may want it to be inside another
sub-module you control); typically this is done via thrift {{namespace}} definitions. The
compiler currently ignores these declarations. It should be changed to:
> # recognize them if they exist, and generate code with the proper module paths
> # default to the current behavior if no {{namespace}} declarations exist
> # work properly in both cases with service inheritance.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Mime
View raw message