## Motivation and Context
Implements [RFC: File-per-change
changelog](https://smithy-lang.github.io/smithy-rs/design/rfcs/rfc0042_file_per_change_changelog.html#rfc-file-per-change-changelog)
## Description
When this PR is merged to `main`, it will impact developer workflow for
creating a changelog entry that goes with a PR.
Prior to this, one edited `CHANGELOG.next.toml` to enter a changelog
entry, but it often caused merge conflicts among us. With this PR, one
creates a `.md` file (any filename stem will do) under the
`smithy-rs/.changelog` directory. This Markdown file has the YAML front
matter, and it can be created manually or via the `ChangeLogger` CLI
(see [this
commit](83cda76608)
for more details).
Here are the highlights of the code changes:
- [The release
script](https://github.com/smithy-lang/smithy-rs/pull/3774/files#diff-162dc2b82eb3d72b105291d2fc5fc8d10c4fbc1e6f35862bc08ac0d6a7c53f76)
has been pointed to `smithy-rs/.changelog`. This is pretty much what it
takes to let the `smithy-rs` release infra switch to the new changelog
mode.
-
[sdk-lints](efcc772b37)
now disallows `CHANGELOG.next.toml`. It will complain if the file is
present.
- The `--source-to-truncate` option for the `changelogger`'s `render` is
now optional because our internal release infra code no longer needs to
specify that option (i.e. there is nothing to truncate there).
- Tests in `smithy-rs-tool-common` and `changelogger` have been updated
so TOML changelog entries used in tests have been re-written to Markdown
changelog entries. We want to avoid giving the false impression that
TOML changelog entries are still well-supported.
## Testing
- Existing tests & lints in CI
- Ran `smithy-rs` [dry-run
release](https://github.com/smithy-lang/smithy-rs/actions/runs/10100442953)
and confirmed the correctness of `CHANGELOG.md` and
`SDK_CHANGELOG.next.json` in the release artifacts
- Ran the internal release and confirmed `CHANGELOG.md` was rendered
correctly in `aws-sdk-rust`
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
## Motivation and Context
Adds new subcommands `--new` and `--ls` to `changelogger`
## Description
This is part 2 in a series of PRs supporting [file-per-change
changelog](https://smithy-lang.github.io/smithy-rs/design/rfcs/rfc0042_file_per_change_changelog.html).
This PR just adds utilities for humans and does NOT impact the current
dev workflow, smithy-rs CI, or our release pipeline.
#### A subcommand `--new`
We can use this subcommand when creating a new changelog entry markdown
file. An example usage:
```
$ changelogger new -t client -t aws-sdk-rust -r smithy-rs#1234 -a someone --bug-fix -m "Some changelog" \
# for long flags, replace -t with --applies-to, -r with --references, -a with --authors, and -m with --message \
# also remember to escape with \ when including backticks in the message at command line, e.g. \`pub\`
The following changelog entry has been written to "/Users/ysaito1001/src/smithy-rs/.changelog/5745197.md":
---
applies_to:
- aws-sdk-rust
- client
authors:
- someone
references:
- smithy-rs#1234
breaking: false
new_feature: false
bug_fix: true
---
Some changelog
```
The following CLI arguments are "logically" required
- `--applies-to`
- `--ref`
- `--author`
- `--message`
If any of the above is not passed a value at command line, then an
editor is opened for further edit (which editor to open can be
configured per the [edit crate](https://docs.rs/edit/0.1.5/edit/)).
Note that the YAML syntax above is different from the single line array
syntax [proposed in the
RFC](https://smithy-lang.github.io/smithy-rs/design/rfcs/rfc0042_file_per_change_changelog.html#the-proposed-developer-experience).
This is due to [a
limitation](https://github.com/dtolnay/serde-yaml/issues/355) in
`serde-yaml` (which has been archived unfortunately), but the multi-line
values are still a valid YAML syntax and, most importantly, rendering
changelong entries will continue working. For now, I won't post-process
from the multi-line values syntax to the single line array syntax. One
can work around this by handwriting a changelog entry Markdown file in
`smithy-rs/.changelog` without using this subcommand.
#### A subcommand `--ls`
This subcommand will render a preview of changelog entries stored in
`smithy-rs/.changelog` and print it to the standard output. Example
usages (using the entry created at 5745197.md above):
```
$ changelogger ls -c smithy-rs \
# for long flag, replace -c with --change-set
Next changelog preview for smithy-rs
=====================================
**New this release:**
- 🐛 (client, [smithy-rs#1234](https://github.com/smithy-lang/smithy-rs/issues/1234), @someone) Some changelog
**Contributors**
Thank you for your contributions! ❤
- @someone ([smithy-rs#1234](https://github.com/smithy-lang/smithy-rs/issues/1234))
```
```
$ changelogger ls -c aws-sdk \
# for long flag, replace -c with --change-set
Next changelog preview for aws-sdk-rust
========================================
**New this release:**
- 🐛 ([smithy-rs#1234](https://github.com/smithy-lang/smithy-rs/issues/1234), @someone) Some changelog
**Contributors**
Thank you for your contributions! ❤
- @someone ([smithy-rs#1234](https://github.com/smithy-lang/smithy-rs/issues/1234))
```
## Testing
- Existing tests in CI
- Basic unit tests for subcommands
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
## Motivation and Context
Follow-up on https://github.com/smithy-lang/smithy-rs/pull/2544 to add
client-side support for the protocol
## Description
The client implementation mainly focuses on a sub-section
[Requests](https://smithy.io/2.0/additional-specs/protocols/smithy-rpc-v2.html#requests)
in the spec. To that end, this PR addresses `TODO` for the client to
fill in the blanks and includes additional adjustments/refactoring to
pass client protocol tests.
## Testing
- Existing tests in CI
- Upstream protocol test `rpcv2Cbor`
- Our handwritten protocol test `rpcv2Cbor-extras.smithy`
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
Member constraint shape tests were using a server codegen invocation
function which was very similar to `serverIntegrationTest`. This PR
removes that and uses `serverIntegrationTest` instead.
Co-authored-by: Fahad Zubair <fahadzub@amazon.com>
This PR adds codegen for service-defined smoketests.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
This allows end-users to keep hyper 0.x out of their tree
## Motivation and Context
This dependency appears unused and means that I have a 0.14 import in my
tree
## Description
Removes the dependency
## Testing
Builds locally, if CI passes I think its fair to say this is a no-op. I
can't find any usages of this lib.
## Checklist
I'm not sure this change warrants a changelog as there is no user facing
change
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
## Motivation and Context
<!--- Why is this change required? What problem does it solve? -->
<!--- If it fixes an open issue, please link to the issue here -->
## Description
<!--- Describe your changes in detail -->
## Testing
<!--- Please describe in detail how you tested your changes -->
<!--- Include details of your testing environment, and the tests you ran
to -->
<!--- see how your change affects other areas of the code, etc. -->
## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [ ] I have updated `CHANGELOG.next.toml` if I made changes to the
smithy-rs codegen or runtime crates
- [ ] I have updated `CHANGELOG.next.toml` if I made changes to the AWS
SDK, generated SDK code, or SDK runtime crates
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
## Motivation and Context
<!--- Why is this change required? What problem does it solve? -->
<!--- If it fixes an open issue, please link to the issue here -->
Lists and maps with sensitive members were not being properly redacted.
Closes https://github.com/smithy-lang/smithy-rs/issues/3757
## Description
<!--- Describe your changes in detail -->
Updated `Shape.shouldRedact` method to properly check for list and map
shapes with sensitive members. Also updated the test definition so it
would actually run since previously the test code was generated in a
nested function inside a no-op function and never run.
## Testing
<!--- Please describe in detail how you tested your changes -->
<!--- Include details of your testing environment, and the tests you ran
to -->
<!--- see how your change affects other areas of the code, etc. -->
Added test cases for lists with sensitive members, maps with sensitive
keys, and maps with sensitive values.
## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the
smithy-rs codegen or runtime crates
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
## Motivation and Context
[RFC: File-per-change
changelog](https://smithy-lang.github.io/smithy-rs/design/rfcs/rfc0042_file_per_change_changelog.html#rfc-file-per-change-changelog)
## Description
This PR is the first of the two implementing the proposal outlined in
the RFC, and it focuses on the initial 4 bullets in the [Changes
checklist](https://smithy-lang.github.io/smithy-rs/design/rfcs/rfc0042_file_per_change_changelog.html#changes-checklist).
Crucially, this update does not modify the workflow for developers
regarding changelog entries (editing `CHANGELOG.next.toml` remains
necessary) or impact the `smithy-rs` CI process and our release
pipeline.
The PR introduces support for deserializing the following Markdown front
matter in the YAML format described in the RFC, e.g.
```
---
# Adding `aws-sdk-rust` here duplicates this entry into the SDK changelog.
applies_to: ["client", "server", "aws-sdk-rust"]
authors: ["author1", "author2"]
references: ["smithy-rs#1234", "aws-sdk-rust#1234"]
# The previous `meta` section is broken up into its constituents:
breaking: false
# This replaces "tada":
new_feature: false
bug_fix: false
---
Some message for the change.
```
These changelog entry Markdown files will be saved in the
`smithy-rs/.changelog` directory:
```
┌───────────┐
│ smithy-rs │
└─────┬─────┘
│
│ ┌───────────┐
├────┤.changelog │
└─────┬─────┘
│
├─────test1.md
│
└─────test2.md
```
For a concrete example, see a test
`end_to_end_changelog_entry_markdown_files` that directly converts from
`end_to_end_changelog` and uses Markdown files (the expected test
results remain the same).
The next PR is expected to
- add new subcommands to `changelogger` to a) create a Markdown file and
b) preview changelog entries pending to be released
- port existing `CHANGELOG.next.toml` at that time to individual
Markdown files
- update `sdk-lints` to disallow the existence of `CHANGELOG.next.toml`
- pass a directory path for `smithy-rs/.changelog` to `--source` (one
for
[split](dc970b3738/tools/ci-scripts/generate-smithy-rs-release (L22))
and one for
[render](dc970b3738/tools/ci-scripts/generate-smithy-rs-release (L22)))
and to
[--source-to-truncate](dc970b3738/tools/ci-scripts/generate-smithy-rs-release (L23C1-L23C47))
(the 4th bullet effectively does the cutover to the new changelog mode)
## Testing
- Added `parse_markdown` and `end_to_end_changelog_entry_markdown_files`
for testing new changelog format (the rest of the tests showing up in
the diff are moved from different places)
- Confirmed via [a release
dry-run](https://github.com/smithy-lang/smithy-rs/actions/runs/9947165056)
that this PR does not break the existing `smithy-rs` release process
- Confirmed that this PR does not break the use of `changelogger` in our
internal release process
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
The Python server relies on types defined in `aws-smithy-http-server`,
which has a new version published. A new version of the Python server
should be released to ensure there is only one `aws-smithy-http-server`
in the dependency closure of the generated crates.
Co-authored-by: Fahad Zubair <fahadzub@amazon.com>
## Motivation and Context
<!--- Why is this change required? What problem does it solve? -->
<!--- If it fixes an open issue, please link to the issue here -->
We have to support the new [`operationContextParams`
trait](https://smithy.io/2.0/additional-specs/rules-engine/parameters.html#smithy-rules-operationcontextparams-trait)
for endpoint resolution. This trait specifies JMESPath expressions for
selecting parameter data from the operation's input type.
## Description
<!--- Describe your changes in detail -->
* Add codegen support for the [JMESPath
`keys`](https://jmespath.org/specification.html#keys) function (required
by the trait
[spec](https://smithy.io/2.0/additional-specs/rules-engine/parameters.html#smithy-rules-operationcontextparams-trait))
* Add codegen support for the trait itself. This is achieved by
generating `get_param_name` functions for each param specified in
`operationContextParams`. These functions pull the data out of the input
object and it is added to the endpoint params in the
`${operationName}EndpointParamsInterceptor`
## Testing
<!--- Please describe in detail how you tested your changes -->
<!--- Include details of your testing environment, and the tests you ran
to -->
<!--- see how your change affects other areas of the code, etc. -->
Updated the existing test suite for JMESPath codegen to test the `keys`
function. Updated the existing EndpointsDecoratorTest with an
`operationContextParams` trait specifying one param of each supported
type to test the codegen.
## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the
smithy-rs codegen or runtime crates
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
`serial_test = "1.0.0"` has a bug where it sometimes does not honor the
`#[ignore]` attribute on a test.
This PR bumps the dependency to version `3.1.1`.
Co-authored-by: Fahad Zubair <fahadzub@amazon.com>
Determining the error type when deserializing an `@httpPayload` is a
protocol-specific concern, and as such should not live in
`ServerHttpBoundProtocolGenerator`, which should remain
protocol-agnostic. This commits makes that determination part of the
`ServerProtocol` interface.
As a drive-by improvement, the companion object in
`ServerHttpBoundProtocolGenerator` has also been removed, since its
members have been unused for a long time.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
Adds an entry to CHANGELOG.next.toml for the
[PR:3378](https://github.com/smithy-lang/smithy-rs/pull/3378)
---------
Co-authored-by: Fahad Zubair <fahadzub@amazon.com>
Co-authored-by: david-perez <d@vidp.dev>
The `struct` created for a Builder should not have attributes because
these structs only derive from `Debug`, `PartialEq`, `Clone` and
`Default`. None of these support attributes.
This becomes a problem if a plugin tries to add attributes to the
`metadata` field to configure the generated code for the `struct`. In
this case, the attributes will also be added to the `Builder` struct;
which is wrong.
## Motivation and Context
I'm customizing client code generation by overriding the method:
```kotlin
override fun symbolProvider(base: RustSymbolProvider): RustSymbolProvider
```
I override the `symbol.expectRustMetadata().additionalAttributes` value
and add extra values there. The generated code adds the correct
attributes for the `struct`, however, it also adds these attributes to
the `Builder`.
The `Builder` is restricted to deriving from `Debug`, `PartialEq`,
`Clone` and `Default` (see
[code](a76dc184c2/codegen-core/src/main/kotlin/software/amazon/smithy/rust/codegen/core/smithy/generators/BuilderGenerator.kt (L188))).
I believe this change was added by mistake in
https://github.com/smithy-lang/smithy-rs/pull/2222/.
## Description
To solve the issue, I simply remove the offending line.
<!--- Describe your changes in detail -->
## Testing
I don't expect any existing code to break, given that this is a bug. It
only manifests when someone is customizing the generated code.
<!--- Please describe in detail how you tested your changes -->
<!--- Include details of your testing environment, and the tests you ran
to -->
<!--- see how your change affects other areas of the code, etc. -->
## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [ ] I have updated `CHANGELOG.next.toml` if I made changes to the
smithy-rs codegen or runtime crates
- [ ] I have updated `CHANGELOG.next.toml` if I made changes to the AWS
SDK, generated SDK code, or SDK runtime crates
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
Co-authored-by: Gustavo Muenz <muenze@amazon.com>
## Motivation and Context
<!--- Why is this change required? What problem does it solve? -->
<!--- If it fixes an open issue, please link to the issue here -->
this fixes an issue submitted by an internal user.
## Description
<!--- Describe your changes in detail -->
If the first event pushed into the log underlying stalled stream
protection, then the log manager would panic. This is because it was
expecting to merge the new event in but there was nothing to merge it
with.
To fix this, I updated the code to `push` the event when the log manager
is empty, instead of merging it.
## Testing
<!--- Please describe in detail how you tested your changes -->
<!--- Include details of your testing environment, and the tests you ran
to -->
<!--- see how your change affects other areas of the code, etc. -->
ran existing tests and wrote a new test exercising the
previous-panicking code.
## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the
smithy-rs codegen or runtime crates
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the AWS
SDK, generated SDK code, or SDK runtime crates
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
## Motivation and Context
<!--- Why is this change required? What problem does it solve? -->
<!--- If it fixes an open issue, please link to the issue here -->
## Description
<!--- Describe your changes in detail -->
Updated our endpoint rule generation to support the new `stringArray`
parameter type
## Testing
<!--- Please describe in detail how you tested your changes -->
<!--- Include details of your testing environment, and the tests you ran
to -->
<!--- see how your change affects other areas of the code, etc. -->
Updated the existing `EndpointsDecoratorTest` with tests for
`stringArray`
## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the
smithy-rs codegen or runtime crates
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
---------
Co-authored-by: Zelda Hessler <zhessler@amazon.com>
This is technically a breaking change because we stop implementing
`FromIterator<(String, S)>`.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
## Motivation and Context
When a user defines a handler function with additional parameters, these
parameters are constructed using the `FromRequest` trait implementation
specific to their types. If `FromRequest` fails to construct the
parameter – for instance, if `Extension<State>` is expected by the user
but `Extension<Arc<State>>` is actually added by the extension layer –
the server currently does not log a message indicating this construction
failure. Instead, it simply returns a 500 internal server error.
## Description
`tracing::{trace, error}` calls have been added.
## Breaking change
`FromParts<P>::Rejection` **must** implement `std::fmt::Display`.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
---------
Co-authored-by: Fahad Zubair <fahadzub@amazon.com>
## Motivation and Context
This PR upgrades Smithy to 1.50.0. The majority of the changes follow
`TODO` added in https://github.com/smithy-lang/smithy-rs/pull/3690.
Other than that, a few adjustments needed to be made:
- for the client
- added two failing tests `RestJsonClientPopulatesDefaultValuesInInput`
and `RestJsonClientUsesExplicitlyProvidedMemberValuesOverDefaults` to
known failing tests for the same reason
[here](https://github.com/smithy-lang/smithy-rs/blob/main/codegen-client/src/main/kotlin/software/amazon/smithy/rust/codegen/client/smithy/generators/protocol/ClientProtocolTestGenerator.kt#L72)
- added one broken test (i.e. the upstream test definition is incorrect
but our implementation is correct) to known broken tests per
([smithy#2341](https://github.com/smithy-lang/smithy/pull/2341),
[smithy-rs#3726](https://github.com/smithy-lang/smithy-rs/pull/3726#issuecomment-2199833659))
- for the server
- removed `rest-xml-extras.smithy` since
`RestXmlMustSupportParametersInContentType` is now available upstream
Smithy 1.50.0
- added the following to known failing tests (since the `awsJson1_0`
counterparts are already in the list, but we need the server team to
verify this assumption & provide additional `TODO` comments if
necessary)
- `RestJsonServerPopulatesDefaultsWhenMissingInRequestBody`
- `RestJsonServerPopulatesDefaultsInResponseWhenMissingInParams`,
-
`RestJsonServerPopulatesNestedDefaultValuesWhenMissingInInResponseParams`
## Testing
Existing tests in CI
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
---------
Co-authored-by: Zelda Hessler <zhessler@amazon.com>
I was speaking to several customers that found our connection poisoning
terminology confusing. To address this, I've changed the messaging and
I've also created a new section in the docs that explains some errors in
greater detail. To direct users to these explanations, I've added a link
to the `tracing::info!` call.
I propose that we consider doing the same any time we identify error
messaging that
- must be kept succinct to avoid logging too much info
- must be more understandable to our users.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
`UnconstrainedUnionGenerator` should use
`ValidationExceptionConversionGenerator` to generate the
`as_validation_exception` method.
---------
Co-authored-by: Fahad Zubair <fahadzub@amazon.com>
## Motivation and Context
<!--- Why is this change required? What problem does it solve? -->
<!--- If it fixes an open issue, please link to the issue here -->
At some point in the near future (after this customization is applied to
all existing SDKs) the S3 model will change the type of `Expires`
members to `String` from the current `Timestamp`. This change would
break backwards compatibility for us.
## Description
<!--- Describe your changes in detail -->
Add customization to ensure S3 `Expires` field is always a `Timestamp`
and ass a new synthetic member `ExpiresString` that persists the
un-parsed data from the `Expires` header.
## Testing
<!--- Please describe in detail how you tested your changes -->
<!--- Include details of your testing environment, and the tests you ran
to -->
<!--- see how your change affects other areas of the code, etc. -->
Added tests to ensure that the model is pre-processed correctly. Added
integration tests for S3. Considered making this more generic codegen
tests, but since this customization will almost certainly only ever
apply to S3 and I wanted to ensure that it was properly applied to the
generated S3 SDK I opted for this route.
## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the AWS
SDK, generated SDK code, or SDK runtime crates
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
Updates the smithy-rs models to the latest versions.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
We currently "hotfix" a broken protocol test in-memory, but there's no
mechanism that alerts us when the broken protocol test has been fixed
upstream when updating our Smithy version. This commit introduces such a
mechanism by generating both the original and the fixed test, with a
`#[should_panic]` attribute on the former, so that the test fails when
all its assertions succeed.
With this change, in general this approach of fixing tests in-memory
should now be used over adding the broken test to `expectFail` and
adding the fixed test to a `<protocol>-extras.smithy` Smithy model,
which is substantially more effort.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
## Motivation and Context
Docs are wrong.
## Description
The docs are referring to the wrong type name (`Config`).
The example right below the change uses the right type name
(`$crateName::config::Builder`).
## Testing
n/a
## Checklist
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
Fixes: #3471
## Motivation and Context
An issue was raised about a mobile client that appends "; charset=utf-8"
to the Content-Type when using restJson1. The [latest
RFC](https://www.rfc-editor.org/rfc/rfc8259) for "application/json" does
not register a charset parameter, but indicates it is reasonable to
accept it.
## Description
This change loosens the validation of the expected content type to allow
all parameters.
## Testing
* Tests for each protocol were added to
[smithy](https://github.com/smithy-lang/smithy/pull/2296)
* ran the runtime and codegen tests
* Added test for rest-xml, as smithy-rs does not currently run the
smithy tests.
## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the
smithy-rs codegen or runtime crates
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the AWS
SDK, generated SDK code, or SDK runtime crates
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
Refactor and define a separate function that returns a set of operation
shapes that must have a supported validation exception shape in their
associated errors list.
This helps identify which type of `ValidationException` has been added
to the operation shape's errors list.
Closes: [3722](https://github.com/smithy-lang/smithy-rs/issues/3722)
---------
Co-authored-by: Fahad Zubair <fahadzub@amazon.com>
Co-authored-by: david-perez <d@vidp.dev>
Protocol test generation code was one of the earlier parts of
smithy-rs's codebase and it has accrued a fair amount of tech debt as we
have evolved the code generation primitives. Its code was also forked
when the server code generator was introduced, introducing a lot of
duplicated code that has deviated over time.
This commit refactors the code to modern standards and aims to reconcile
commonalities in `ProtocolTestGenerator`, so that both client and server
can reap centralized improvements over time.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
This PR refactors the code to limit the visibility of
`crate::model::ValidationExceptionField` to only those decorators and
associated classes that are invoked when
`smithy.framework#ValidationException` is being used.
More information is in [this
issue](https://github.com/smithy-lang/smithy-rs/issues/3718).
Closes: [3178](https://github.com/smithy-lang/smithy-rs/issues/3718)
---------
Co-authored-by: Fahad Zubair <fahadzub@amazon.com>
Co-authored-by: david-perez <d@vidp.dev>
to get the path of the top level of the repo
## Motivation and Context
<!--- Why is this change required? What problem does it solve? -->
<!--- If it fixes an open issue, please link to the issue here -->
Fixing issue with test workspaces that would break if the repo is not
named `smithy-rs`
## Description
<!--- Describe your changes in detail -->
Moved to using `git rev-parse --show-toplevel` to get the project
directory instead of climbing the file tree.
## Testing
<!--- Please describe in detail how you tested your changes -->
<!--- Include details of your testing environment, and the tests you ran
to -->
<!--- see how your change affects other areas of the code, etc. -->
All of our CI tests this since it is part of generating test workspaces
## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
Also fixes IntelliJ lints
This PR is not intended to change any behavior. If you see me doing that
somewhere, then it's a mistake.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
## Motivation and Context
<!--- Why is this change required? What problem does it solve? -->
<!--- If it fixes an open issue, please link to the issue here -->
Due to numerous dependency issues over the past few weeks several of our
dependencies were pinned to specific minor versions. Now that we have
lockfiles for all of our workspaces those pinned versions can be undone.
## Description
<!--- Describe your changes in detail -->
I unpinned those dependencies and generated new lockfiles after that
change.
## Testing
<!--- Please describe in detail how you tested your changes -->
<!--- Include details of your testing environment, and the tests you ran
to -->
<!--- see how your change affects other areas of the code, etc. -->
I ran the gradle `assemble` and `sdkTest` tasks locally and they both
passed. I ran a full set of preview/release e2e tests against this
change in my local stack and those all passed. And since we copy the
Cargo.lock into the test workspaces the CI run for this PR will also
test the changes.
## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
No functional changes, only dependency changes.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
Otherwise, if you generate a crate and compile it using Gradle, like for
example using the invocation:
```
./gradlew -P modules='simple' -P cargoCommands='test' codegen-server-test:build
```
And then manually run a `cargo` command within the generated crate
directory, or open the project using `rust-analyzer`, Cargo will
re-compile the project from scratch, with
`CARGO_LOG=cargo::core::compiler::fingerprint=trace` reporting that
flags have changed since the last compilation.
Instead, it's best if we persist these flags to `.cargo/config.toml`, so
all `cargo` invocations, either through Gradle, manually, or through
`rust-analyzer`, use the same set. This way, if no files were changed,
subsequent compilations since code generation will truly be no-ops, with
Cargo reusing all artifacts.
Note this commit fixes a regression that was introduced when `--cfg
aws_sdk_unstable` was introduced in #2614, since I fixed this the first
time back in #1422.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
## Motivation and Context
The generated SDK conditionally re-exports `routing::LambdaHandler`
under the feature flag aws-lambda, but the `Cargo.toml` does not define
such a feature.
## Description
Closes: https://github.com/smithy-lang/smithy-rs/issues/3643
## Checklist
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the
smithy-rs codegen or runtime crates
---------
Co-authored-by: Fahad Zubair <fahadzub@amazon.com>
Co-authored-by: david-perez <d@vidp.dev>
## Motivation and Context
<!--- Why is this change required? What problem does it solve? -->
<!--- If it fixes an open issue, please link to the issue here -->
Our WASI canary was breaking with the newest Rust version due to the new
WASI build targets:
https://blog.rust-lang.org/2024/04/09/updates-to-rusts-wasi-targets.html
## Description
<!--- Describe your changes in detail -->
Updating the version of `cargo-component` used to build our WASI canary.
Made the same update in the `aws-sdk-rust` repo:
https://github.com/awslabs/aws-sdk-rust/pull/1168
## Testing
<!--- Please describe in detail how you tested your changes -->
<!--- Include details of your testing environment, and the tests you ran
to -->
<!--- see how your change affects other areas of the code, etc. -->
This same change was made in the canary workflow in the `aws-sdk-rust`
repo and run successfully there:
* PR: https://github.com/awslabs/aws-sdk-rust/pull/1168
* Canary run:
https://github.com/awslabs/aws-sdk-rust/actions/runs/9575014647
## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [ ] I have updated `CHANGELOG.next.toml` if I made changes to the
smithy-rs codegen or runtime crates
- [ ] I have updated `CHANGELOG.next.toml` if I made changes to the AWS
SDK, generated SDK code, or SDK runtime crates
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
## Motivation and Context
Update lockfiles based on [the codegen
release](https://github.com/awslabs/aws-sdk-rust/releases/tag/release-2024-06-18)
(a release including code changes in aws runtime crates, smithy runtime
crates, or codegen code).
## Testing
- [ ] Existing tests in CI
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
ysaito1001