GraphiteEditor/Graphite · error · syn::Error

Failed to parse input type for #[implementation(...)]. Expec

Error message

Failed to parse input type for #[implementation(...)]. Expected a valid Rust type.
Error: {}

What it means

Inside the node-graph macro, each entry of #[implementations(...)] on a node parameter is parsed by syn as `Type -> Type`. This error wraps syn's failure for the tokens before the `->`: they must form a valid Rust type. It is spanned to the attribute and appends syn's own message, which names the offending token.

Source

Thrown at node-graph/node-macro/src/parsing.rs:355

	pub input_type: Type,
	pub output_type: Type,
	/// The peeled `Item` element of `output_type`, if the lazy input's `Output` is declared `Item<T>`.
	pub output_element: Option<Type>,
	pub implementations: Punctuated<Implementation, Comma>,
}

#[derive(Clone, Debug)]
pub(crate) struct Input {
	pub(crate) pat_ident: PatIdent,
	pub(crate) ty: Type,
	pub(crate) implementations: Punctuated<Type, Comma>,
	pub(crate) context_features: Vec<Ident>,
}

impl Parse for Implementation {
	fn parse(input: ParseStream) -> syn::Result<Self> {
		let input_type: Type = input.parse().map_err(|e| {
			Error::new(
				input.span(),
				formatdoc!(
					"Failed to parse input type for #[implementation(...)]. Expected a valid Rust type.
					Error: {}",
					e,
				),
			)
		})?;
		let arrow: RArrow = input.parse().map_err(|_| {
			Error::new(
				input.span(),
				indoc!(
					"Expected `->` arrow after input type in #[implementations(...)] on a field of type `impl Node`.
					The correct syntax is `InputType -> OutputType`."
				),
			)
		})?;
		let output_type: Type = input.parse().map_err(|e| {

View on GitHub (pinned to c507b35645)

Solutions

1. Rewrite the entry as `InputType -> OutputType`, e.g. #[implementations(f32 -> f64)]
2. Read the appended "Error: {e}" line — syn names the exact token it could not parse
3. Confirm the input type is a real, in-scope Rust type where the node is defined
4. Compare against a known-good list like #[implementations(i32 -> f64, String -> Vec<u8>)]

Example fix

// before
#[implementations(-> f64)]
fn my_node(input: f64) -> f64 { /* ... */ }

// after
#[implementations(f64 -> f64)]
fn my_node(input: f64) -> f64 { /* ... */ }

When it happens

Trigger: #[implementations(-> f64)] with the input type omitted; a literal or expression where a type belongs, e.g. #[implementations(3 -> f64)]; a typo'd or out-of-scope type path; unclosed generics such as Vec< before the arrow.

Common situations: Hand-authoring a new node's implementation list; porting nodes written against an older macro grammar; generic type paths referencing parameters not in scope where the node is defined.

Understand the failure class

• Parsing and encoding errors: unexpected token, malformed input — why parsers reject input and how to find the real culprit.

Related errors

• Expected `->` arrow after input type in #[implementations(..
• Failed to parse output type for #[implementation(...)]. Expe
• Failed to parse node_fn attributes: {e}
• Failed to parse implementations for argument '{name}': {e}
• Invalid #[implementations(...)] for argument `{}`. Expected

AI-assisted analysis of GraphiteEditor/Graphite@c507b35645 (2026-08-16). Data as JSON: /api/errors/4831b162aefc959b. Report an issue: GitHub.