Regen all remaining APIs with preproc - more changes than anticipated

This commit is contained in:
Sebastian Thiel
2019-07-05 17:05:15 +08:00
parent f33fae47e9
commit 3365d9fba1
90 changed files with 2777 additions and 2569 deletions

View File

@@ -375,8 +375,8 @@ impl<'a, C, A> Speech<C, A>
/// programming environments, including REST APIs and RPC APIs. It is used by
/// [gRPC](https://github.com/grpc). The error model is designed to be:
///
/// - Simple to use and understand for most users
/// - Flexible enough to meet unexpected needs
/// * Simple to use and understand for most users
/// * Flexible enough to meet unexpected needs
///
/// # Overview
///
@@ -406,26 +406,25 @@ impl<'a, C, A> Speech<C, A>
///
/// Example uses of this error model include:
///
/// - Partial errors. If a service needs to return partial errors to the client,
/// it may embed the `Status` in the normal response to indicate the partial
/// errors.
/// * Partial errors. If a service needs to return partial errors to the client,
/// it may embed the `Status` in the normal response to indicate the partial
/// errors.
///
/// - Workflow errors. A typical workflow has multiple steps. Each step may
/// have a `Status` message for error reporting.
/// * Workflow errors. A typical workflow has multiple steps. Each step may
/// have a `Status` message for error reporting.
///
/// - Batch operations. If a client uses batch request and batch response, the
/// `Status` message should be used directly inside batch response, one for
/// each error sub-response.
/// * Batch operations. If a client uses batch request and batch response, the
/// `Status` message should be used directly inside batch response, one for
/// each error sub-response.
///
/// - Asynchronous operations. If an API call embeds asynchronous operation
/// results in its response, the status of those operations should be
/// represented directly using the `Status` message.
/// * Asynchronous operations. If an API call embeds asynchronous operation
/// results in its response, the status of those operations should be
/// represented directly using the `Status` message.
///
/// - Logging. If some API errors are stored in logs, the message `Status` could
/// be used directly after any stripping needed for security/privacy reasons.
/// * Logging. If some API errors are stored in logs, the message `Status` could
/// be used directly after any stripping needed for security/privacy reasons.
///
/// This type is not used in any activity, and only used as *part* of another schema.
///
#[derive(Default, Clone, Debug, Serialize, Deserialize)]
pub struct Status {
/// A developer-facing error message, which should be in English. Any