Hello! I'm a 3rd year CS student. I've been playing around with Rust for 2 years, and professionally working with it for 5 months. Next semester (starting in October) I'll be writing my first research paper and I'd like to do something Rust related.
Although as far as I know there is only a few professors in my uni who have heard of Rust, there are a lot of them interested in programming languages, functional programming, compilers, static analysis and other things that I think I could use as the central topic and then sneak some Rust in as the preferred language.
Some ideas I had were to write about behavioral types, such as typestates and session types, or something related to the borrow checker and what it achieves especially in concurrent applications.
Any other ideas of something interesting that I could research and write about? It doesn't have to be super specific, I was told to think of topics of interest and I guess I'll get some guidance afterwards once I have a starting idea.
Panics in Rust add code bloat, complicated unwinding code, and complicate reasoning about control flow, which is dangerous in unsafe code. So I'd love to see some research trying to minimize panics in Rust programs.
For example, a static analysis proving absence of panics in Rust code. This is hard, because it needs analyzing which code is reachable given run-time inputs.
Another thing I'd love to see solved in Rust, is an optimization pass coalescing panics. This has four bounds checks with four unique panicking paths:
There's the no-panic crate that prevents the code from compiling, detecting panics at link time. And then there's rustig that's an actual static analysis tool, recursively iterating through all of the functions, finding paths that lead to functions that can panic. I'm not sure I'd be able to add any more value than rustig, since the way they do it is how I'd do it too.
As for the second suggestion, I don't really have experience with compilers and how such optimizations work, but it seems interesting, so I guess I'd have a reason to start learning that. I'll try to look into it!
It surprises me to hear this. Usually, you'd do some research first, and then, if the research gives something interesting, write a paper. I mean, you can start the paper writing process quite soon when you have an interesting idea, but you cannot really start before you have any novel ideas. Failure is part of the research process (what you try doesn't always work — it rarely works, even), so you normally cannot make plans like "I want to write a paper, let me choose a subject first".
Well, technically, I'll just do research for some subject that I kind of choose. The research paper part is just what I assumed would happen afterwards, but I guess that's not always the case.
There's the no-panic crate that prevents the code from compiling, detecting panics at link time. And then there's rustig that's an actual static analysis tool, recursively iterating through all of the functions, finding paths that lead to functions that can panic. I'm not sure I'd be able to add any more value than rustig, since the way they do it is how I'd do it too.
Cool, I haven't heard of rustig before, thanks.
There is also a new tool called redpen by @ekuber. It is a "Rust code linter" that happens to implement the detection of panics with some beautiful error messages (it supports other lints as well):
It's a plain reachability lint, it doesn't do additional analysis but it supports setting developer assertions that a lint won't trigger even if it is reachable. I haven't audited std to minimize false positives, but some use-cases want to ensure no possible reach of panics. Also, the output in the example is from a simplistic HIR checker, and am working now on a post-monomorphization MIR based one (that is working, I'm just cleaning it up now so it can be used for other checks like allocation failures).
(it supports other lints as well):