Unexpected highlights from Flowistry

[Will Crichton]

If you use Flowistry and it highlights something unexpectedly -- either it misses something you expect to be highlighted, or it highlights something that seems irrelevant -- please post a screenshot here!

[Glenn Willen]

Filed #52 about trait default method implementations.

Also, it seems to not see code that's under #[cfg(test)], which @connorff mentioned maybe taking a look at.

[Justus Adam]

It highlights inconsistently between regular function returns and lambda function returns.

In both these cases I have the variable r selected:

And unlike the + it does correctly detect this method call

But it is unable to detect this one

[Justus Adam]

I have another one for you.

This is the code without anything selected

And here is what happens when you select the y variable.

Now I would have expected that this would also highlight the return statement, since y obviously has an influence on the value that is returned there. maybe this is out of scope but I was under the impression that due to provenance you can trace the reference back to its origin (i.e. x and not just the vector v).

PS: I also tried it using a println! instead of a return, just in case it was hitting the same return issue from above.

[Will Crichton]

@JustusAdam I fixed the for_each issue in 10d9118. The lambda issue seems like a source mapping problem -- I will check that out soon.

[Justus Adam]

I've found what I believe to be an overtainting issue related to the interactions of aggregates and pointers.

The minimal example is this:

struct Point { x: i32, y: i32 }

fn wrong_with_pointer(p: &mut Point) {
    let x = 0;
    let y = 1;
    let i_m_here_so_you_see_highlighting_works = 9;

    *p = Point { x, y};

    let x1 = p.x;

    x1;
}

fn correct_without_pointer() {

    let x = 0;
    let y = 1;
    let p2 = Point { x, y};

    let x0 = p2.x;

    x0;

}

In the correct (non-pointer) case when selecting the last statement we get the following highlight:

It understands that y has no bearing on that statement.

However if we augment the example to access x through a pointer to the Point we get the following highlight:

E.g. once the pointer is involved we lose the field sensitivity.

[Justus Adam]

Some more weird behavior from pointers.

So I am using this test code

fn test() {
    let mut x = 0;
    let mut y = 9;
    let mut ptr = &mut x;

    let test = *ptr;

    ptr = &mut y;

    *ptr = 20;

    assert_eq!(x, 0);
}

Which gives the following highlight

I expected this to go wrong as I expected an overapproximation wrt. the modifications through a pointer, because conflicts are based on regions and thus not flow sensitive? The test case I think shows that but also another oddity which is that the original assignment of ptr = &mut x is not shown as a dependency. While both the second assignment ptr = &mut y and y = 9 are though technically neither has an influence on the value of x in the assert.

I think I know why it has this outcome and that this will be filed as an "expected wrong" highlight but I thought I'd report it anyway.