What causes "expected type" in diesel-rs/diesel?

Replace the text after `=` with a valid Rust type (path or generic)

expected type

Error message

expected type

What it means

After the `=` token is consumed, `parse_eq_type` tries to parse a `syn::Type`. If that parse fails, the underlying syn error (which can be vague since many tokens could start a type) is replaced with this clearer 'expected type' message at the same span.

Solutions

Replace the text after `=` with a valid Rust type (path or generic)
Quote generic types correctly if using turbofish-like syntax in paths
Check the token after `=` for stray commas or literals

Example fix

// before
#[diesel(sql_type = "text")]
// after
#[diesel(sql_type = Text)]

Defensive patterns

Strategy: type-guard

Type guard

fn is_valid_type_token(s: &str) -> bool {
    syn::parse_str::<syn::Type>(s).is_ok()
}

Try / catch

match syn::parse_str::<syn::Type>(src) {
    Ok(t) => t,
    Err(e) => panic!("#[diesel(...)] expected a Rust type after `=`: {}", e),
}

Prevention

Use a real type path (e.g. MyType) after `=`, not strings or numbers
Compile-check types by importing them at the call site
Keep generic syntax valid Rust

When it happens

Trigger: Writing `#[diesel(sql_type = 42)]`, `#[diesel(sql_type = ,)]`, or any tokens after `=` that are not valid Rust type syntax.

Common situations: Passing a literal or expression where a type is required; forgetting to import/qualify a path correctly is usually OK syntactically, but garbage tokens are not.

Understand the failure class

Background: "Invalid ... format", "must be in format X", "does not look like a ..." — invalid argument format errors across CLI tools and libraries — this error's family across 17 libraries.

Related errors

AI-assisted analysis of diesel-rs/diesel@6fa6ed01b2 (2026-09-07). Data as JSON: /api/errors/057d25761521d202. Report an issue: GitHub.

Appendix: source

Thrown at diesel_attribute_parser/src/util.rs:48

}

/// Specialized version of `parse_eq` for `syn::Type` with a customized error message for readability.
/// This is useful because a great variety of tokens would be valid to parse as a `syn::Type`.
pub fn parse_eq_type(input: ParseStream, help: &str) -> Result<syn::Type> {
    if input.is_empty() {
        return Err(syn::Error::new(
            input.span(),
            format!(
                "unexpected end of input, expected `=`\n\
                 help: the correct format looks like `#[diesel({help})]`",
            ),
        ));
    }

    input.parse::<Eq>()?;
    input
        .parse::<Type>()
        .map_err(|e| syn::Error::new(e.span(), "expected type"))
}

pub fn parse_paren<T: Parse>(input: ParseStream, help: &str) -> Result<T> {
    if input.is_empty() {
        return Err(syn::Error::new(
            input.span(),
            format!(
                "unexpected end of input, expected parentheses\n\
                 help: the correct format looks like `#[diesel({help})]`",
            ),
        ));
    }

    let content;
    parenthesized!(content in input);
    content.parse()
}

View on GitHub (pinned to 6fa6ed01b2)