Description
The rust client's code generation can have variable name conflicts with function's definition and the generated parameter names. For example, if a parameter to a function using oauth2 auth is called "token", the below code will override its value:
|
{{#isOAuth}} |
|
if let Some(ref token) = configuration.oauth_access_token { |
|
let auth = hyper::header::Authorization( |
Suggest a fix/enhancement
There are a couple possible options here.
One option would be to reserve all variable names used in the body of such functions and ave the java code remap the parameter names.
Another could be to prefix all those variables with something like "openapi_local" and assume no one will name parameters starting with that string.
We could also rebind all the parameters immediately to known names which won't conflict, and then allow shadowing throughout the rest of the function. This is also fairly easy, and I think might be the best short term solution.
In the long term, I think this can be improved by having a helper non-generated method to make the request, and then have each generated method simply be a call to that helper with the correct parameters, allowing the generated method's scope to not polute the main logic of handling a request.
Description
The rust client's code generation can have variable name conflicts with function's definition and the generated parameter names. For example, if a parameter to a function using oauth2 auth is called "token", the below code will override its value:
openapi-generator/modules/openapi-generator/src/main/resources/rust/api.mustache
Lines 73 to 75 in b594262
Suggest a fix/enhancement
There are a couple possible options here.
One option would be to reserve all variable names used in the body of such functions and ave the java code remap the parameter names.
Another could be to prefix all those variables with something like "openapi_local" and assume no one will name parameters starting with that string.
We could also rebind all the parameters immediately to known names which won't conflict, and then allow shadowing throughout the rest of the function. This is also fairly easy, and I think might be the best short term solution.
In the long term, I think this can be improved by having a helper non-generated method to make the request, and then have each generated method simply be a call to that helper with the correct parameters, allowing the generated method's scope to not polute the main logic of handling a request.