Let FilteredEntity(Ref|Mut) receive access when nested.
#18236
Conversation
alice-i-cecile
added
C-Feature
|
|
||
| let mut entity = new_query.single_mut(&mut world).unwrap(); | ||
| let (_entity, mut entity) = new_query.single_mut(&mut world).unwrap(); |
There was a problem hiding this comment.
This variable naming is very confusing.
| access: &mut Access<ComponentId>, | ||
| available_access: &Access<ComponentId>, | ||
| ) { | ||
| state.clone_from(available_access); |
There was a problem hiding this comment.
Comment here please: this is pretty tricky to understand when skimming out of context.
| @@ -838,6 +818,40 @@ impl<T: SparseSetIndex> Access<T> { | |||
| } | |||
| } | |||
|
|
|||
| /// Performs an in-place union of `other` into `self`, where either set may be inverted. | |||
There was a problem hiding this comment.
I'd like more docs here, explaining what the right logic is. The union terminology is very precise, but doesn't help people understand what that means in practice.
| } | ||
| } | ||
|
|
||
| /// Performs an in-place set difference of `other` from `self`, where either set may be inverted. |
There was a problem hiding this comment.
Same request for more docs here.
There was a problem hiding this comment.
As far as I can tell this is correct, and mildly useful. I'd like to move forward with this, but this makes an already confusing bit of the code base more confusing. I've left suggestion for more docs, but I'd also like to see some unit tests for the invertable union / difference methods.
Those are pretty rough to mess up, and seem very testable!
alice-i-cecile
added
S-Waiting-on-Author
Objective
Let
FilteredEntityRefandFilteredEntityMutreceive access when nested inside tuples or#[derive(QueryData)]types. Make sure to exclude any access that would conflict with other subqueries!Fixes #14349
Solution
Replace
WorldQuery::set_access(state, access)with a new method,QueryData::provide_extra_access(state, access, available_access), that passes both the total available access and the currently used access. This is called afterWorldQuery::update_component_access(), so any access used by ordinary subqueries will be known.FilteredEntityRefandFilteredEntityMutcan use the combination to determine how much access they can safely take, while tuples can safely pass those parameters directly to their subqueries.This requires a new
Access::remove_conflicting_access()method that can be used to remove any access that would conflict with existing access. Implementing this method was easier by first factoring some common set manipulation code out ofAccess::extend. I can extract that refactoring to a separate PR if desired.Have
FilteredEntity(Ref|Mut)storeAccessinstead ofFilteredAccessbecause they do not need to keep track of the filter. This was necessary in an early draft but no longer is. I left it in because it's small and I'm touching that code anyway, but I can extract it to a separate PR if desired.