Don't ignore default query filters for EntityRef or EntityMut

[chescock]

Objective

Don't ignore default query filters for EntityRef or EntityMut.

Currently, Query<EntityRef> will include entities with a Disabled component, even though queries like Query<()> or Query<Entity> would not. This was noticed in #19711 (comment).

Solution

Change Access::contains to completely ignore read access and just look at filters and archetypal access. Filters covers With, Without, &, and &mut, while archetypal covers Has and Allows.

Note that Option<&Disabled> will no longer count as a use of Disabled, though.

[Trashtalk217]

Minor nit

[Trashtalk217]

Shouldn't it be something like has_component_read_or_exception, now it sounds like the component has something called a read_exception, which sounds like a Java error.

[Trashtalk217]

Maybe an has_component_exception would be even cleaner, but probably more tricky because this part of the code is perf sensitive

[alice-i-cecile]

A comment here on why this works would be helpful: this is quite mysterious.

[alice-i-cecile]

has_component_read_exception is very unclear to me, but this is simple and seems to work (yay tests). If you can find a better name and improve the docs / comments to clarify why this works I'll approve this :)

[chescock]

I'm having trouble wording things well, but maybe I can simplify it instead. I realized EntityRefExcept was a red herring here: It's surprising that EntityRefExcept<Disabled> doesn't turn off the filter, but nobody is actually going to write that.

It might work more cleanly if we completely ignore read access and just look at filters and archetypal access. Filters covers With, Without, &, and &mut, while archetypal covers Has and Allows.

That won't count Option<&Disabled> as a use, though. Is that an important case to handle? My impression is that query filters will be for marker components where you'll want to use Has<Disabled> anyway. And it's consistent with edge cases like (EntityRef, Option<&Disabled>). But it is a bit surprising!

[alice-i-cecile]

That won't count Option<&Disabled> as a use, though. Is that an important case to handle? My impression is that query filters will be for marker components where you'll want to use Has anyway

Yes, Has is much more important than Option here :)