flowistry
flowistry copied to clipboard
Unexpected highlights from Flowistry
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!
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.
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
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.
@JustusAdam I fixed the for_each
issue in 10d9118. The lambda issue seems like a source mapping problem -- I will check that out soon.
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.
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
![Screen Shot 2023-03-10 at 12 24 36 AM](https://user-images.githubusercontent.com/5824532/224230806-fffac0b3-53b9-415a-a8c5-031a8dc9b32a.png)
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.