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

Extend flowistry to types with interior mutability #53

Open
jyn514 opened this issue May 6, 2022 · 4 comments
Open

Extend flowistry to types with interior mutability #53

jyn514 opened this issue May 6, 2022 · 4 comments

Comments

@jyn514
Copy link

jyn514 commented May 6, 2022

You mentioned two things during your thesis defense:

  1. There are two analyses that flowistry supports: whole-program analysis, and (very accurate) heuristics using the lifetime annotations people already provide for the borrow checker.
  2. The lifetime annotations only work for exterior mutability; things like AtomicUsize::set are not considered by flowistry to affect the data flow of the program.

I think it would be possible to extend this to interior mutability by using the intra-procedural analysis that looks into dependencies, but only for types which have interior mutability. The compiler already knows statically which types have interior mutability, because they have to contain an UnsafeCell (anything else is already undefined behavior).

@WaffleLapkin
Copy link

The compiler already knows statically which types have interior mutability, because they have to contain an UnsafeCell (anything else is already undefined behavior).

That's true only for owned types though, something like NonNull<T> or *mut T can also mutate the value.

@jyn514
Copy link
Author

jyn514 commented May 9, 2022

@WaffleLapkin those types aren't using interior mutability, they're using unsafe. Writing to a *mut T when you only have a &T is undefined behavior. So flowistry can just treat them like normal types.

@WaffleLapkin
Copy link

@jyn514 pointers can point to the heap, they not necessarily come from &T . Or they can actually point to an UnsafeCell somewhere, they were just casted to point to T (that's ok because UnsafeCell is repr(transparent)).

@jyn514
Copy link
Author

jyn514 commented May 9, 2022

@WaffleLapkin ah, sure. But I think it's ok to support interior mutability without first supporting raw pointers, the second will be much more difficult (it probably will require whole-program analysis).

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

2 participants