rust-server generated code does not compile

[jsnewby]

Description

The code generated from our swagger file fails to compile with multiple errors.

Swagger-codegen version

Tried with current stable release and with recent nightly (swagger-codegen-cli-2.4.0-20180511.013033-251.jar)

Swagger declaration file content or url

https://github.com/aeternity/epoch/blob/master/config/swagger.yaml

Command line used for generation

java -jar ~/Downloads/swagger-codegen-cli-2.4.0-20180511.013033-251.jar generate -i ../aeternity/src/epoch/config/swagger.yaml -l rust-server

Steps to reproduce

java -jar ~/Downloads/swagger-codegen-cli-2.4.0-20180511.013033-251.jar generate -i ../aeternity/src/epoch/config/swagger.yaml -l rust-server
cargo check

fails with multiple errors like

error[E0201]: duplicate definitions with name `get_tx`:
     --> src/client/mod.rs:14218:5
      |
6838  | /     fn get_tx(&self, param_tx_hash: String, param_tx_encoding: Option<String>, context: &C) -> Box<Future<Item=GetTxResponse, Error=ApiError>> {
6839  | |
6840  | |         // Query parameters
6841  | |         let query_tx_encoding = param_tx_encoding.map_or_else(String::new, |query| format!("tx_encoding={tx_encoding}&", tx_encoding=query.to_string()));
...     |
6949  | |
6950  | |     }
      | |_____- previous definition of `get_tx` here
...
14218 | /     fn get_tx(&self, param_tx_hash: String, param_tx_encoding: Option<String>, context: &C) -> Box<Future<Item=GetTxResponse, Error=ApiError>> {
14219 | |
14220 | |         // Query parameters
14221 | |         let query_tx_encoding = param_tx_encoding.map_or_else(String::new, |query| format!("tx_encoding={tx_encoding}&", tx_encoding=query.to_string()));
...     |
14329 | |
14330 | |     }
      | |_____^ duplicate definition

error[E0201]: duplicate definitions with name `get_txs`:
     --> src/client/mod.rs:14332:5
      |
6952  | /     fn get_txs(&self, context: &C) -> Box<Future<Item=GetTxsResponse, Error=ApiError>> {
6953  | |
6954  | |
6955  | |         let uri = format!(
...     |
7019  | |
7020  | |     }
      | |_____- previous definition of `get_txs` here
...
14332 | /     fn get_txs(&self, context: &C) -> Box<Future<Item=GetTxsResponse, Error=ApiError>> {
14333 | |
14334 | |
14335 | |         let uri = format!(
...     |
14399 | |
14400 | |     }
      | |_____^ duplicate definition

error: aborting due to 889 previous errors

Related issues/PRs

Suggest a fix/enhancement

[bjgill]

Thanks for the report. It looks like this is caused by the presence of multiple tags for some endpoints. This seems to cause swagger-codegen (for rust-server, at least) to generate duplicates, which is what you're seeing.

The tests for fixing this will be to add the following to the spec:

  /fake/many_tags:
    get:
      tags:
        - user
        - store
      description: Multiple status values can be provided with comma separated strings
      responses:
        '200':
          description: foo

[jsnewby]

Thanks for this, I attempted to work around it with

cat ../swagger-codegen/swagger.yaml |egrep -v '\- (gossip|transactions|dev|name_service|obsolete|node_operator|chain|debug)' > swagger.yaml 

which fails, but less so :)

I've attached the generated file and the errors https://gist.github.com/jsnewby/8f220d22ea10659b925072b637456ad0 here

[bjgill]

Interesting. Thanks for the report. It looks as if the following is the problem:

  Pow:
    type: array
    items:
      type: integer

Given that we end up with Integer, I wonder if the problem is caused by if ("integer".equals(property.baseType)) {. I'm not really sure, though.

The other problem is simpler - if the API has more than 32 regexes, the generated code will fail to compile. IntoIterator is only implemented for slices up to size 32.

[jsnewby]

Ah OK super interesting, are you able to suggest a workaround for this one? I guess I can slice up the YAML but that seems a bit brutal...

[bjgill]

I can't think of a better workaround. The fix looks pretty simple, though - regex::RegexSet::new(vec![.

There's been a slowdown in getting PRs merged, though, so I'm not sure when I'll get to this.