Skip to content
Unverified Commit e1ba6562 authored by david-perez's avatar david-perez Committed by GitHub
Browse files

Fix 3 bugs in `@length`-constrained collection and map shapes (#2085)



* Fix 3 bugs in `@length`-constrained collection and map shapes

The 3 bugs are related, hence why a single commit to address them all.

1. #2028 added support for the `@length` constraint trait on collection
   shapes, but the code enforcing the trait was not being exercised upon
   receiving a request, specifically when converting the input
   unconstrained list into the constrained one. Note that #2028 did not
   result in the removal of the relevant protocol tests from
   `ServerProtocolTestGenerator`'s list of known failing tests.
2. Fixes code generation of `@length`-constrained list shapes whose
   members are not constrained: the converter being generated only
   worked for the case where the member was (transitively) constrained.
   The `constraints.smithy` model has been expanded to cover this case.
3. Fixes bug in code generation, when the
   `codegenConfig.publicConstrainedTypes` setting is set to `false`, of
   `@length`-constrained map shapes and collection shapes whose values
   or members (respectively) are constrained, but result in Rust types
   that would have been public regardless of the setting's value. This
   is the case only when they are modeled as structure shapes or union
   shapes. In these cases, two converters from the constrained type to
   the inner type were being generated, resulting in two `From` trait
   implementations. The `constraints.smithy` model has been expanded to
   cover this case.

* Use correct symbol provider

* ./gradlew ktlintFormat

Co-authored-by: default avatarHarry Barber <106155934+hlbarber@users.noreply.github.com>
parent f3e05625
Loading
Loading
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment