null analysis

[rosefromthedead]

It would be good to avoid wrapping every pointer in Option unless the C side had explicit null checks or assignments. The checks are currently represented as .is_null(), but none of our benchmarks seem to contain any null assignments. A naive way of doing it might be easy to implement, but to be rigorous we'd need to consider control flow to catch cases like this:

fn f() -> *mut T {
    let mut p = ...;
    if p.is_null() {
        p = malloc(...);
    }
    return p;
}

here, p could be null at the start of the function, but we can show that it isn't null when it's returned, so it's best to conclude that this function can't return null. It seems likely to me that SSA would help with this. I'll have a go at implementing this, but any thoughts on it are welcome

[rosefromthedead]

I've had a first go at this and I think it can be done using two mir dataflow passes and a bit of graph work at the end

[KomaEc]

That's very nice! You mentioned that SSA could help, are you planning to use core/crustr_analysis/src/ssa? Maybe I shall give an overview of the current implementation details? Anyway let's discuss more on Friday about this

[KomaEc]

My impression is that precise null check/fix is hard on languages like C or Java, because of unrestricted aliasing. But maybe we don't need that precision: any transformations that lead to less Option wrapper is good.

[rosefromthedead]

Null analysis is almost done now. There is not yet a way of inferring the function return place nullability, because the analysis works backwards and return places are not accessed after assignment. I have a plan for how to infer return place results using inter function analysis though. I think there are also some cases causing panics that I need to look at.

[rosefromthedead]

I think that the aliasing problem is almost not relevant because we infer results based on pointer usage, and it will be very rare for a new aliasing pointer to be created but not used.