Skip to content

FilteredEntityRef/FilteredEntityMut's access is empty when used in composite queries #14349

Open
@SkiFire13

Description

@SkiFire13

Bevy version

Both 0.14.0 and af865e7

What you did

#[derive(Component)]
struct Foo;

let mut world = World::new();

let foo_id = world.init_component::<Foo>();

world.spawn(Foo);

// With just `FilteredEntityRef` it works fine.
let mut query = QueryBuilder::<FilteredEntityRef>::new(&mut world)
    .ref_id(foo_id)
    .build();
let entity_ref = query.single(&world);
assert!(entity_ref.access().has_read(foo_id));
assert!(entity_ref.get::<Foo>().is_some());

// Inside any tuple it does not work, even 1-element tuples.
let mut query = QueryBuilder::<(FilteredEntityRef,)>::new(&mut world)
    .ref_id(foo_id)
    .build();
let (entity_ref,) = query.single(&world);
assert!(entity_ref.access().has_read(foo_id));
assert!(entity_ref.get::<Foo>().is_some());

What went wrong

It seems that when FilteredEntityRef/FilteredEntityMut are nested inside a tuple the access is not properly set. Indeed the implementation of WorldQuery for tuples does not call the set_access method used by FilteredEntityRef/FilteredEntityMut. However the fix doesn't seem as simple as just calling it, since may ignore any potential conflict between the FilteredEntity* and the other QueryDatas in the query.

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-ECSEntities, components, systems, and eventsC-BugAn unexpected or incorrect behaviorC-UsabilityA targeted quality-of-life change that makes Bevy easier to useD-StraightforwardSimple bug fixes and API improvements, docs, test and examplesS-Ready-For-ImplementationThis issue is ready for an implementation PR. Go for it!X-UncontroversialThis work is generally agreed upon

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions