Queries: `Added<Foo>` in filter position conflicts with `&mut Foo` in query position

[nicopap]

Bevy version

• 0.6
• 0.7

Code

use bevy::prelude::*;

#[derive(Component)]
struct A;
#[derive(Component)]
struct B;
fn main() {
    App::new().add_system(hello_world_system).run();
}

fn hello_world_system(aaas: Query<&A, Added<B>>, bees: Query<&mut B>) {
    println!("hello world");
}

What should happen

cargo run this should print "hello world". As I never access B in aaas, there should be no conflict between bees and aaas.

What happened instead

thread 'main' panicked at 'error[B0001]: Query<&mut bevy_exclusion_bug::B, ()> in system bevy_exclusion_bug::hello_world_system accesses component(s) bevy_exclusion_bug::B in a way that conflicts with a previous system parameter. Consider using `Without<T>` to create disjoint Queries or merging conflicting Queries into a `ParamSet`.', /home/gibonus/.local/share/cargo/registry/src/github.com-1ecc6299db9ec823/bevy_ecs-0.7.0/src/system/system_param.rs:173:5

Additional information

Initially found out by @linkmauve in nicopap/ui-navigation#21. I'm fairly certain the example worked at one point without crashing. I'll investigate further and report here.

[DJMcNab]

When this worked previously, it was unsound (since changed and added are both stored inline in ComponentTicks).
Consider:

fn hello_world_system(aaas: Query<(), Added<B>>, bees: Query<(Entity, &mut B)>) {
    for (not, the) in bees {
        // 'the' now owns a `Ticks`, which contains an exclusive reference to `ComponentTicks` for `B` of `not`

        // Oh no, this line reads the `ComponentTicks` for `B` of `not`, even though an exclusive reference 
        // to it exists. Undefined behaviour.
        aaas.get(not);
    }
}

That is, this is expected.

[nicopap]

Thank you for the precision (and also insanely fast response). This is going to be difficult for me to migrate my code to account for that change. But the limitation makes perfect sense.

[DJMcNab]

It's not ideal, but you can either use ParamSet, or make the second filter contained Added<B> (which returns a boolean of whether it was added). That would look like:

fn hello_world_system(aaas: Query<(&A, Entity)>, bees: Query<&mut B, Added<B>>) {
    for (a, entity) in aaas {
         if bees.get(entity).is_some() {
             // You know `a` has `B` added.
         }
    }
}

Alternatively, you can try and combine them all into one query, which might be easier.

[nicopap]

Yeah, so I've a SystemParam (BunchQueries<'w,'s>) with a bunch of queries defined in module A (including a Query<&mut Foo>), and a system in module B that both uses that SystemParam and another query that filters with Added<Foo>. The "workaround" I decided to go with is split the BunchQueries in a collection of SystemParams so queries that are used together are within individual SystemParam, and have a more fine-grained query in module B's system (and functions defined in module A that accepted a &BunchQueries).

Though I'll probably come up later with a cleaner design.

[alice-i-cecile]

Reopening. This represents a fundamental flaw in our access model.

We need four nested access levels:

1. Reads presence/absence
2. Reads values
3. Writes values
4. Writes presence absence

Added uses level 1, but currently requires level 2.

[DJMcNab]

Why wouldn't that just re-introduce the unsoundness explained above?

[alice-i-cecile]

I think the right solution here is to split apart the added and changed ticks. Messing with the added ticks should require level 4 permission, but requires level 3 permission as is.

Because level 1 and 4 permissions are incompatible, there's no soundness problems.