Austin Ziegler 18a07eab37
Improved Elixir Code Generation (#12751)
* Bump the minimum version of Elixir supported

The previous minimum version of Elixir is several years EOL.

The current minimum version of Elixir is also EOL, but is the minimum
version required to support some upcoming changes to the config
templates.

* Bump the minimum version fo Tesla

Keep the dependencies up to date

* Add a default .formatter.exs

* Add two Elixir-specific mustache lambdas

- The `atom` lambda results in the proper quoting of an atom depending
  on the safe contents of the atom text, per the Elixir language
  specification. That is, `{{#atom}}foo{{/atom}}` will be turned into
  `:foo` and `{{#atom}foo.bar{{/atom}}` will be turned into
  `:"foo.bar"`.

- The `env_var` lambda results in the treatment of the identifier
  provided being capitalized as an environment variable would be.
  `{{#env_var}}apiVersion{{/env_var}}` would become `ENV_VAR`.

* Use modern Elixir configuration

- This includes runtime configuration
- It depends on the `env_var` lambda.

* Fix a Language Server Warning

This change is *optional*, but removes a LS warning that was raised.

* Regenerated openapi_petstore for Elixir

* Add ex_doc as a default dependency

Fixes #12484

* Refine the regular expression for atoms

The original regex incorrectly matched `123Number` (unquoted atoms
cannot begin with numbers) and would incorrectly quote atoms ending in
`?` or `!`. Through testing with `iex`, it also turns out that the atom
`:-` is legal.

The following atoms will now not be quoted that would have been
incorrectly quoted:

- `:-`
- `:declawed?`
- `:neutered!`

The following atoms will be quoted that were incorrectly unquoted:

- `:"123Number"`

* Improve regex (again), remove files not generated

- The previous commit resulted in a number of warnings that were still
  present and so I played with the regular expression. This did not
  solve the problem, but the resulting regular expression is *much*
  better than the previous one, so I'm keeping it.

- The problem was that the configuration (`bin/configs/elixir.yaml`) is
  generated using a 3.0 input spec:

  ```yaml
  inputSpec: modules/openapi-generator/src/test/resources/3_0/petstore-with-fake-endpoints-models-for-testing.yaml
  ```

  Which means that there were 16 files committed which were no longer
  being generated. When I tested with the 2.0 input spec:

  ```yaml
  inputSpec: modules/openapi-generator/src/test/resources/2_0/petstore-with-fake-endpoints-models-for-testing.yaml
  ```

  The files were generated again. I *believe* that the correct change
  here is to switch back to the 2.0 input spec, as it tests more code
  generation, but I wanted to check in before I did this.

  The following files are deleted:

  - `elixir/lib/openapi_petstore/model/additional_properties_any_type.ex`
  - `elixir/lib/openapi_petstore/model/additional_properties_array.ex`
  - `elixir/lib/openapi_petstore/model/additional_properties_boolean.ex`
  - `elixir/lib/openapi_petstore/model/additional_properties_integer.ex`
  - `elixir/lib/openapi_petstore/model/additional_properties_number.ex`
  - `elixir/lib/openapi_petstore/model/additional_properties_object.ex`
  - `elixir/lib/openapi_petstore/model/additional_properties_string.ex`
  - `elixir/lib/openapi_petstore/model/big_cat.ex`
  - `elixir/lib/openapi_petstore/model/big_cat_all_of.ex`
  - `elixir/lib/openapi_petstore/model/inline_response_default.ex`
  - `elixir/lib/openapi_petstore/model/special_model_name.ex`
  - `elixir/lib/openapi_petstore/model/type_holder_default.ex`
  - `elixir/lib/openapi_petstore/model/type_holder_example.ex`
  - `elixir/lib/openapi_petstore/model/xml_item.ex`
  - `elixir/pom.xml`
  - `elixir/test/pet_test.exs`

  In the interim, I have removed those files from the commit.
2022-07-03 17:31:34 +08:00
..