Struct darling::Error [−][src]
pub struct Error { /* fields omitted */ }
Expand description
An error encountered during attribute parsing.
Given that most errors darling encounters represent code bugs in dependent crates, the internal structure of the error is deliberately opaque.
Usage
Proc-macro expansion happens very infrequently compared to runtime tasks such as deserialization, and it happens in the context of an expensive compilation taks. For that reason, darling prefers not to fail on the first error it encounters, instead doing as much work as it can, accumulating errors into a single report.
As a result, darling::Error
is more of guaranteed-non-empty error collection
than a single problem. These errors also have some notion of hierarchy, stemming from
the hierarchical nature of darling’s input.
These characteristics make for great experiences when using darling-powered crates, provided crates using darling adhere to some best practices:
- Do not attempt to simplify a
darling::Error
into some other error type, such assyn::Error
. To surface compile errors, instead usedarling::Error::write_errors
. This preserves all span information, suggestions, etc. Wrapping adarling::Error
in a custom error enum works as-expected and does not force any loss of fidelity. - Do not use early return (e.g. the
?
operator) for custom validations. Instead, create a localVec
to collect errors as they are encountered and then usedarling::Error::multiple
to create an error containing all those issues if the list is non-empty after validation. This can create very complex custom validation functions; in those cases, split independent “validation chains” out into their own functions to keep the main validator manageable. - Use
darling::Error::custom
to create additional errors as-needed, then callwith_span
to ensure those errors appear in the right place. Usedarling::util::SpannedValue
to keep span information around on parsed fields so that custom diagnostics can point to the correct parts of the input AST.
Implementations
Error creation functions
Creates a new error for a field that appears twice in the input.
Creates a new error for a field that appears twice in the input. Helper to avoid repeating the syn::Path to String conversion.
Creates a new error for a non-optional field that does not appear in the input.
Creates a new error for a field name that appears in the input but does not correspond to a known field.
Creates a new error for a field name that appears in the input but does not correspond to a known field. Helper to avoid repeating the syn::Path to String conversion.
pub fn unknown_field_with_alts<'a, T, I>(field: &str, alternates: I) -> Error where
T: 'a + AsRef<str>,
I: IntoIterator<Item = &'a T>,
pub fn unknown_field_with_alts<'a, T, I>(field: &str, alternates: I) -> Error where
T: 'a + AsRef<str>,
I: IntoIterator<Item = &'a T>,
Creates a new error for a field name that appears in the input but does not correspond to a known attribute. The second argument is the list of known attributes; if a similar name is found that will be shown in the emitted error message.
Creates a new error for a struct or variant that does not adhere to the supported shape.
Creates a new error for a field which has an unexpected literal type.
Creates a new error for a field which has an unexpected literal type. This will automatically
extract the literal type name from the passed-in Lit
and set the span to encompass only the
literal value.
Usage
This is most frequently used in overrides of the FromMeta::from_value
method.
use darling::{FromMeta, Error, Result};
use syn::{Lit, LitStr};
pub struct Foo(String);
impl FromMeta for Foo {
fn from_value(value: &Lit) -> Result<Self> {
if let Lit::Str(ref lit_str) = *value {
Ok(Foo(lit_str.value()))
} else {
Err(Error::unexpected_lit_type(value))
}
}
}
Creates a new error for a value which doesn’t match a set of expected literals.
Creates a new error for a list which did not get enough items to proceed.
Creates a new error when a list got more items than it supports. The max
argument
is the largest number of items the receiver could accept.
Error instance methods
Check if this error is associated with a span in the token stream.
Tie a span to the error if none is already present. This is used in darling::FromMeta
and other traits to attach errors to the most specific possible location in the input
source code.
All darling
-built impls, either from the crate or from the proc macro, will call this
when appropriate during parsing, so it should not be necessary to call this unless you have
overridden:
FromMeta::from_meta
FromMeta::from_nested_meta
FromMeta::from_value
Adds a location to the error, such as a field or variant. Locations must be added in reverse order of specificity.
Adds a location to the error, such as a field or variant. Locations must be added in reverse order of specificity. This is a helper function to avoid repeating path to string logic.
Gets the number of individual errors in this error.
This function never returns 0
, as it’s impossible to construct
a multi-error from an empty Vec
.
Write this error and any children as compile errors into a TokenStream
to
be returned by the proc-macro.
The behavior of this method will be slightly different if the diagnostics
feature
is enabled: In that case, the diagnostics will be emitted immediately by this call,
and an empty TokenStream
will be returned.
Return these tokens unmodified to avoid disturbing the attached span information.
Usage
// in your proc-macro function
let opts = match MyOptions::from_derive_input(&ast) {
Ok(val) => val,
Err(err) => {
return err.write_errors();
}
}
Trait Implementations
use the Display impl or to_string()
replaced by Error::source, which can support downcasting
The lower-level source of this error, if any. Read more