Re-point those using BuildError from smithy-http to smithy-types
#3070
Conversation
|
A new generated diff is ready to view.
A new doc preview is ready to view. |
ysaito1001
added
breaking-change
|
A new generated diff is ready to view.
A new doc preview is ready to view. |
This commit addresses #3070 (comment)
|
A new generated diff is ready to view.
A new doc preview is ready to view. |
This commit addresses #3070 (comment)
|
A new generated diff is ready to view.
A new doc preview is ready to view. |
|
A new generated diff is ready to view.
A new doc preview is ready to view. |
Co-authored-by: Russell Cohen <[email protected]>
| @@ -9,11 +9,17 @@ | |||
| use aws_smithy_types::config_bag::{Storable, StoreReplace}; | |||
| use std::borrow::Cow; | |||
|
|
|||
| //TODO(runtimeCratesVersioningCleanup): Re-point those who use the following reexport to | |||
| // directly depend on `aws_smithy_types` and remove the reexport below. | |||
| //TODO(runtimeCratesVersioningCleanup): Re-point those who use the deprecated type aliases to | |||
There was a problem hiding this comment.
Is this TODO for pre-GA or will we do this post GA?
There was a problem hiding this comment.
I'd expect it's for pre-GA. After we've released a new version (likely a breaking release), we'll go ahead and remove those deprecated type aliases.
| pub use aws_smithy_types::error::operation::{BuildError, SerializationError}; | ||
| /// An error occurred attempting to build an `Operation` from an input. | ||
| #[deprecated(note = "Moved to `aws_smithy_types::error::operation::BuildError`.")] | ||
| pub type BuildError = aws_smithy_types::error::operation::BuildError; |
There was a problem hiding this comment.
Any code generated from this release will raise a Serialization(#[from] aws_smithy_types::error::operation::SerializationError) error. So if a customer's codebase has a function that takes the re-exported, deprecated type from aws_smithy_http instead of the one from aws_smithy_types, will the code compile (with a deprecated warning)? Or will the compiler produce an error, stating that the two types are not the same?
let error = some_call_that_generates_a_serialization_error();
match error {
Serialization(se) => handle_se(se),
_ => (),
}
// Will the compiler produce an error here, stating that the passed-in type is
// `aws_smithy_types::error::operation::SerializationError`?
fn handle_error(e: aws_smithy_http::operation::error::SerializationError) {
// ...
}There was a problem hiding this comment.
will the code compile (with a deprecated warning)? Or will the compiler produce an error, stating that the two types are not the same?
It'll be the former, but whether it compiles or not ultimately depends on the compiler's warn level configured on a customer's end.
|
A new generated diff is ready to view.
A new doc preview is ready to view. |
Motivation and Context
Completes #3054 (a follow-up on #3032)
Description
#3032 moved
BuildErrorfromaws_smithy_http::operation::errortoaws_smithy_types::error::operation. That PR also left "breadcrumbs", so that customers could still consumeBuldErrorfromaws_smithy_httpafter the move.This PR turns breadcrumbs into deprecation messages (via
#[deprecated(...)]) and updates existing places that used to use moved types fromaws_smithy_httptoaws_smithy_types.Testing
Relied on tests in CI.
Checklist
CHANGELOG.next.tomlif I made changes to the smithy-rs codegen or runtime cratesBy submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.