Open jyn514 opened 2 years ago
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.
@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.
@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 cast
ed to point to T
(that's ok because UnsafeCell
is repr(transparent)
).
@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).
You mentioned two things during your thesis defense:
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).