Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Re-point those using BuildError from smithy-http to smithy-types #3070

Merged
merged 9 commits into from
Oct 19, 2023

Conversation

ysaito1001
Copy link
Contributor

@ysaito1001 ysaito1001 commented Oct 13, 2023

Motivation and Context

Completes #3054 (a follow-up on #3032)

Description

#3032 moved BuildError from aws_smithy_http::operation::error to aws_smithy_types::error::operation. That PR also left "breadcrumbs", so that customers could still consume BuldError from aws_smithy_http after the move.

This PR turns breadcrumbs into deprecation messages (via #[deprecated(...)]) and updates existing places that used to use moved types from aws_smithy_http to aws_smithy_types.

Testing

Relied on tests in CI.

Checklist

  • 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.

@github-actions
Copy link

@ysaito1001 ysaito1001 marked this pull request as ready for review October 13, 2023 21:59
@ysaito1001 ysaito1001 requested review from a team as code owners October 13, 2023 21:59
@github-actions
Copy link

@github-actions
Copy link

@ysaito1001 ysaito1001 requested a review from rcoh October 17, 2023 03:38
@github-actions
Copy link

@github-actions
Copy link

CHANGELOG.next.toml Outdated Show resolved Hide resolved
Co-authored-by: Russell Cohen <rcoh@amazon.com>
@@ -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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this TODO for pre-GA or will we do this post GA?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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) {
    // ...
}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@github-actions
Copy link

@ysaito1001 ysaito1001 added this pull request to the merge queue Oct 19, 2023
Merged via the queue into main with commit e447a22 Oct 19, 2023
40 of 41 checks passed
@ysaito1001 ysaito1001 deleted the ysaito/follow-up-on-moving-build-error branch October 19, 2023 19:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking-change This will require a breaking change
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants