What causes "`from_reflect` already set to {}" in bevyengine/bevy?

Pick one mechanism: either `#[derive(FromReflect)]` (implies true) or an explicit `#[reflect(from_reflect = false)]`, not both

bevyengine/bevy · error · syn::Error

`from_reflect` already set to {}

Error message

`from_reflect` already set to {}

What it means

`#[reflect(from_reflect = <bool>)]` controls whether the `Reflect` derive also generates a `FromReflect` impl. The value is stored once; `parse_from_reflect` (crates/bevy_reflect/derive/src/container_attributes.rs:427) errors with "`from_reflect` already set to {previous}" if it is set again with a DIFFERENT value. Note the `FromReflect` derive forces the value to `true` (the mapper override in the source), so an explicit `false` combined with `#[derive(FromReflect)]` is the typical conflict.

Source

Thrown at crates/bevy_reflect/derive/src/container_attributes.rs:446

        &mut self,
        input: ParseStream,
        trait_: ReflectTraitToImpl,
    ) -> syn::Result<()> {
        let pair = input.parse::<MetaNameValue>()?;
        let extracted_bool = extract_bool(&pair.value, |lit| {
            // Override `lit` if this is a `FromReflect` derive.
            // This typically means a user is opting out of the default implementation
            // from the `Reflect` derive and using the `FromReflect` derive directly instead.
            if trait_ == ReflectTraitToImpl::FromReflect {
                LitBool::new(true, Span::call_site())
            } else {
                lit.clone()
            }
        })?;

        if let Some(existing) = &self.from_reflect_attrs.auto_derive {
            if existing.value() != extracted_bool.value() {
                return Err(syn::Error::new(
                    extracted_bool.span(),
                    format!("`{FROM_REFLECT_ATTR}` already set to {}", existing.value()),
                ));
            }
        } else {
            self.from_reflect_attrs.auto_derive = Some(extracted_bool);
        }

        Ok(())
    }

    /// Parse `type_path` attribute.
    ///
    /// Examples:
    /// - `#[reflect(type_path = false)]`
    fn parse_type_path(
        &mut self,
        input: ParseStream,

View on GitHub (pinned to 396ca72708)

Solutions

Pick one mechanism: either `#[derive(FromReflect)]` (implies true) or an explicit `#[reflect(from_reflect = false)]`, not both
If you need `false`, remove the `FromReflect` derive and implement `FromReflect` manually if still required
Keep a single `#[reflect(...)]` list so the setting appears once

Example fix

// before: derive forces true, attribute says false -> "`from_reflect` already set to false"
#[derive(Reflect, FromReflect)]
#[reflect(from_reflect = false)]
struct Foo;

// after: choose one opt-in
#[derive(FromReflect)] // implies from_reflect = true
struct Foo;

Defensive patterns

Strategy: validation

Validate before calling

null

Prevention

Never combine #[derive(FromReflect)] with #[reflect(from_reflect = false)]
Pick one opt-in mechanism per type and document it
When disabling auto-derives, grep the type for any derive or attribute that silently re-enables it

When it happens

Trigger: `#[derive(Reflect, FromReflect)]` together with `#[reflect(from_reflect = false)]` on the same type; or two contradictory settings like `#[reflect(from_reflect = true)]` and `#[reflect(from_reflect = false)]` across lists. Setting the same value twice is fine.

Common situations: Opting a type out of auto FromReflect while a derive or a second attribute still opts in; refactors that add `#[derive(FromReflect)]` to a type that previously carried `from_reflect = false` to dodge a field-bound issue.

Related errors

AI-assisted analysis of bevyengine/bevy@396ca72708 (2026-08-20). Data as JSON: /api/errors/5b23055c1aa494f7. Report an issue: GitHub.