Proposal: Improve diagnostics when multi-component structs are incorrectly derived as Component instead of Bundle

[not-null-nil]

Summary

In Bevy ECS, it is easy to accidentally define a struct that looks like a Bundle but is incorrectly derived as Component, which leads to silent logic failures at runtime (e.g. Query<..., With> returning empty results).

This pattern produces no compile-time or runtime warnings, yet results in invalid entity composition.

Minimal example

#[derive(Component)]
struct EnemyBundle {
    enemy: Enemy,
    hex_coord: HexCoord,
    transform: Transform,
}

Spawn:

commands.spawn(EnemyBundle {
    enemy: Enemy { radius: 10.0 },
    hex_coord: HexCoord::default(),
    transform: Transform::default(),
});

Query:

Query<(Entity, &HexCoord), With<Enemy>>

Result:

Query returns empty
No warnings or errors
Root cause is non-obvious in larger codebases
Expected behavior

When a struct:

has multiple fields
and all fields implement Component
but is derived as Component

It is likely intended to be a Bundle.

Why this matters

This pattern is:

very easy to make
hard to debug
produces silent ECS mismatch (no entities in query)

It becomes especially problematic in:

large component-heavy architectures
gameplay prototyping phases
systems relying heavily on With filtering

[SkiFire13]

I would argue that even one component might be confusing given discussions like this one.

Anyway, I believe you could do it by adding a method on Component that uses autoref-specialization to determine whether any or all field components implement Component, then when the component is initialized we call the method. We should also add an attribute to silence it for false positives (e.g. if the component is supposed to be used to add the field component to other entities). And for compile time performance we should likely gate this behind debug_assertions