Assign to properties with explicit self in init(from decoder:)
#696
+22
−7
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
czechboy0
approved these changes
Dec 10, 2024
simonjbeaumont
added a commit
that referenced
this pull request
Dec 11, 2024
### Motivation In #696 we avoided clashing with a property called `container` in certain schemas by making use of explicit self in `init(from decoder:)`. We didn't have access to the OpenAPI document and hadn't caught the case where this was used in a schema that supported additional properties, where we also need to avoid the clash in `encode(to encoder:)`. ### Modifications - Access properties with explicit self in `encode(to encoder:)`. ### Result - Fixes #695 ### Test Plan More snippet tests and reference tests.
simonjbeaumont
added a commit
that referenced
this pull request
Dec 11, 2024
…and encoders (#700) ### Motivation In order to address #695 we made some targeted fixes (#696, #699) to use explicit-self to avoid clashing with schema property names. This addressed a clash with a specific variable with properties of only certain schemas, but there are more places where we might encounter future issues. Specifically, we have other variable names which might cause a clash (e.g. `storage` and `discriminator`), and there are other flavours of initializers, encoders, and decoders that were not updated in the targeted fix. In this PR, we update all access and assignment in the generated code dealing with schemas to use explicit-self. ### Modifications - Use self for member access and assignment in all initializers, decoders, and encoders. - Update the reference tests and snippet tests. ### Result Removed some cases where valid OpenAPI docs would produce non-compiling code. ### Test Plan Snippet and reference tests. The latter is actually compiled during the CI.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
Our generated
init(from decoder:)assigns to properties without using explicit self. This is a problem because it can produce conflicts with the local variables created in the initializer, e.g. the decoding container, which will then fail to compile for schemas with properties namedcontainer, as found by an adopter in #695.We should probably take a broader pass with regard to the use of explicit self in our generated code, but for now we can resolve this by focussing on this problematic generation, where a schema with named and additional properties.
Modifications
init(from decoder:)Result
containeras a property name of a model #695.Test Plan