PR #25335 - OpenAPITools/openapi-generator

Since #24841, the default (Tesla) request_builder.ex.mustache defines the private add_multipart_field/3 helpers between the add_param(request, :multipart_form, ...) clause and the last two add_param/4 clauses. Every generated client then compiles with:

warning: clauses with the same name and arity (number of arguments) should be grouped together, "def add_param/4" was previously defined (lib/openapi_petstore/request_builder.ex:97)

Projects that build with --warnings-as-errors can't compile the client, and apps that depend on it see the warning too. We hit this in a generated client.

To reproduce

Any spec: the warning comes from the supporting file request_builder.ex. With the petstore sample:

cd samples/client/petstore/elixir
mix deps.get
mix compile --force --warnings-as-errors

Before:

     warning: clauses with the same name and arity (number of arguments) should be grouped together, "def add_param/4" was previously defined (lib/openapi_petstore/request_builder.ex:97)
Compilation failed due to warnings while using the --warnings-as-errors option

After:

Compiling 61 files (.ex)
Generated openapi_petstore app

The change

The add_param(request, :form, ...) and add_param(request, location, ...) clauses move up, so the add_multipart_field/3 helpers follow the last add_param/4 clause. The add_param/4 clauses keep their order, so matching is unchanged. The req library's request_builder.ex.mustache already keeps its clauses together and isn't changed.

What I ran

Regenerated bin/configs/elixir*.yaml (elixir, elixir-req). Only samples/client/petstore/elixir/lib/openapi_petstore/request_builder.ex changes (8 lines moved); the elixir-req sample is unchanged.
mix compile --force --warnings-as-errors on the elixir sample (Elixir 1.19.1, OTP 28): fails on master with the warning above, passes with this change.
Added ElixirClientCodegenTest#testRequestBuilderKeepsClausesOfEachFunctionTogether, which generates a client and checks that no function in request_builder.ex has clauses on both sides of another definition. It fails on master (add_param has clauses on both sides of another function in request_builder.ex); with the change ElixirClientCodegenTest passes (6 tests).

PR checklist

Read the contribution guidelines.
Run the following to build the project and update samples:
```
./mvnw clean package || exit
./bin/generate-samples.sh ./bin/configs/*.yaml || exit
./bin/utils/export_docs_generators.sh || exit
```
(For Windows users, please run the script in WSL)
Commit all changed files.
This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
These must match the expectations made by your contribution.
You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*.
IMPORTANT: Do NOT purge/delete any folders/files (e.g. tests) when regenerating the samples as manually written tests may be removed.
If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

(Samples: only the Elixir configs were regenerated, see above. Template-only change, so the generator docs are unaffected.)

Elixir technical committee: @mrmstn

Summary by cubic

Fixes the generated Elixir request builder so add_param/4 clauses stay grouped together, eliminating the "clauses with the same name and arity should be grouped together" warning that broke compilation for projects using --warnings-as-errors.

Moved the add_multipart_field/3 private helpers after the last add_param/4 clause in request_builder.ex.mustache; clause order and matching behavior are unchanged.
Added ElixirClientCodegenTest#testRequestBuilderKeepsClausesOfEachFunctionTogether, which fails on master and passes with this change.
Regenerated the Elixir petstore sample; only request_builder.ex changed, and the req-based sample was already unaffected.