Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[PDG] Alias analysis causes imprecise PDGs #93

Open
JustusAdam opened this issue Feb 12, 2024 · 0 comments
Open

[PDG] Alias analysis causes imprecise PDGs #93

JustusAdam opened this issue Feb 12, 2024 · 0 comments

Comments

@JustusAdam
Copy link
Contributor

JustusAdam commented Feb 12, 2024

The lifetime based alias analysis inserts on-existent dependencies when a called function's lifetime annotations claim such a dependency exists.

Consider the following example

fn insert_ref<'v, 't: 'v, T>(v: &mut Vec<&'v T>, t: &'t T) {}
fn main() {
    let x = /* some object */;
    let mut v = Vec::new();
    insert_ref(&mut v, &x);
    read(&v);
}

The resulting PDG has an edge from x to the &v argument of read, even though x is never added to the vector.

Implications on async

Perhaps more worryingly this also occurs when async functions are used.

async fn handle(ud1: &UserData, ud2: &mut UserData) {
    read(ud1);
    write(ud2);
}

async fn main() {
    let mut ud1 = get_user_data();
    let mut ud2 = get_user_data();
    handle(&ud1, &mut ud2).await;
}

// external functions
fn read<T>(read: &T);
fn write<T>(written: &mut T);

In this example the PDG shows a connection ud1 -> written which does not actually exist.

Similarly, and perhaps more concerning, the same effect is also visible in the caller, e.g.

async fn handle(ud1: &UserData, ud2: &mut UserData) {
}

async fn main() {
    let mut ud1 = get_user_data();
    let mut ud2 = get_user_data();
    handle(&ud1, &mut ud2).await;
    read(ud1);
    write(ud2);
}

Also has a ud1 -> written edge.

This seems to be caused by into_future and new_unchecked, which is called automatically by the await desugaring.

@JustusAdam JustusAdam changed the title Alias analysis causes imprecise PDGs [PDG] Alias analysis causes imprecise PDGs Feb 12, 2024
JustusAdam added a commit to brownsys/paralegal that referenced this issue Feb 14, 2024
Unified test template with skip template, now uses #[ignore]
Test template instantiations now simply forward fragments
Marker tests are skipped completely for now
Debugged last tests cases, issues are reported in willcrichton/flowistry#93 and willcrichton/flowistry#94
Fixed propagating marker skip from async function to their generators
Added new test cases for discovered issues
JustusAdam added a commit to brownsys/paralegal that referenced this issue Feb 21, 2024
## What Changed?

- Data and control flow graph construction moves into the Flowistry
crate.
- Removes `df`, inlining logic and the algebra.
- Entails an update of the rustc toolchain (to achieve parity with
flowistry).
- Graph contains all program locations, not just function calls.
- Control flow is non-transitive
- The PDG now tracks individual places instead of abstract function
arguments. This improves field sensitivity across function calls.
- Forge output is gone

## Why Does It Need To?

Field sensitivity is now handled as the initial analysis constructs the
PDG and in fewer lines of code.

## Caveats

At the time of this merge, the following regressions in the PDG have not
been fixed yet

- willcrichton/flowistry#95
- willcrichton/flowistry#94
- willcrichton/flowistry#93
- And while Will fixed the strong updates
willcrichton/flowistry#90 the second issue
mentioned there is still present.

## Checklist

- [x] Above description has been filled out so that upon quash merge we
have a
  good record of what changed.
- [x] New functions, methods, types are documented. Old documentation is
updated
  if necessary
- [ ] Documentation in Notion has been updated
- [ ] Tests for new behaviors are provided
  - [ ] New test suites (if any) ave been added to the CI tests (in
`.github/workflows/rust.yml`) either as compiler test or integration
test.
*Or* justification for their omission from CI has been provided in this
PR
    description.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant