Initialization analysis (bachelor work, draft)

[mglukhikh]

[LifeIsStrange]

Hi @maratdin7 friendly ping, I am an amateur that doesn't contribute to Kotlinc so don't pay much attention to my comment. Most importantly I might say things that are plain wrong, given my sparse knowledge, but I just wanted to say the following:

1. A big thank you for this work as the analysis you build seems extremely useful, especially for lateinit safety.
2. It is known that static analysis in general, especially dataflow driven one, related to e.g. tracking lifetimes (as in Rust) is easily a CPU intensive task. In fact some analyzers use a slighly bruteforce but very powerful/expressive technology named SAT/SMT solvers for this. (I wonder if Kotlinc would have use cases for one) Now I understand that your task is more limited in scope than static safe memory allocations/lifetime tracking, since this analysis is "only" about initialization safety. The closest thing that comes to my mind about this work is the widely used MSAN in C/C++ and MIRI for rust Wether it's at compile time, runtime or a opportunistic hybrid, the task of tracking and checking uninitialized accesses is CPU and memory intensive. For MSAN, IIRC it is at runtime and slow the program by a factor of 2 and increase memory use by ~2. As for MIRI I have no data. So my simple question is: what will the impact of those analysises be on compile time, runtime throughput and runtime memory use. Maybe some perf tests could be made. Either way, it's possible your analysis is very fast and if so I'm curious what make it faster than e.g. MSAN. Spoiler: being integrated directly in the compiler probably helps.
3. I see that you added tests for inner classes, I was wondering wether the analysies e.g. for lateinit works on nested functions too?
4. I'm assuming you write a thesis/paper accompanying this work? Do you have a link for me to find it once published?
5. I see that your analysis allow to make lateinit var safe. I understand it is a slighly out of scope with your current work, but if you want a suggestion for what to work on next, there is an unfortunate omission in the Kotlin language, one can write lateinit var, but not lateinit val... A workaround is to use by Lazy {} except it is not always applicable. As such, modifying Kotlinc to allow lateinit val would be a great improvement, which might become easier to do with your checkers/analysises.

[LifeIsStrange]

@mglukhikh I'm curious, why the closing?

[mglukhikh]

Because it's in fact just a draft, and at the moment I see no chances for it to be finished.