Re:RustViz: Generates Visualizations of Rust Lifetime and Bo...
by tialaramex on Monday July 05, 2021 @07:46PM
(#27742894)
This is pretty limited right now, judging from their own documentation:
- No branching logic
- No looping
- No explicit lifetime annotation
The academic paper also suggests they haven't (yet) gone as far as to actually assess whether this helps in the only role it could have at this early stage - assist newbies.
With the above limitations a confused but otherwise competent Rust programmer likely will not find this useful, their problem almost certainly involves a loop or branch before they got into trouble and didn't understand the lifetimes.
So until this can cope with looping and branching the key question is whether it can help a Day One Rust programmer to grok lifetimes stuff early, and avoid the case that seems to happen to some people where they're "fighting the borrow checker" because they don't understand what their code means so they're only ever following suggestions in the diagnostics from the compiler.
However even if they struggle to automate this, developing a schema and a library of standard examples, might help lifetime diagrams become "a thing" the way some places teach children to graph sentence grammar. That would also help other languages with lifetime problems - where the language will not tell you that your code is nonsense, it will just break unexpectedly because not only did you have no idea what the lifetime of this Object is when you wrote the program, neither does your compiler or interpreter.
Re:RustViz: Generates Visualizations of Rust Lifetime and Bo...
by Animats on Monday July 05, 2021 @08:06PM
(#27743019)
It's nice, but I suspect more an educational tool than a working programmer's tool. Rustc has good lifetime diagnostics, so it's not that huge a problem.
What I'd like to see is something that does static analysis for reference-counted items. To access a reference-counted item, you often have to call .borrow(), which checks to see if someone else already has it borrowed. This panics on a conflict. That's a good problem for static analysis - is the .borrow() always safe, always going to fail, or unknown? Much of the time, it's always safe and could be optimized out.
Re:RustViz: Generates Visualizations of Rust Lifetime and Bo...
by zozbot234 on Monday July 05, 2021 @08:16PM
(#27743069)
> What I'd like to see is something that does static analysis for reference-counted items.
This ought to be doable with GhostCell and similar efforts. https://plv.mpi-sws.org/rustbelt/ghostcell/ It doesn't cover the entire spectrum of "borrow safety proofs" but it can be used to address simple cases.
- No branching logic
- No looping
- No explicit lifetime annotation
The academic paper also suggests they haven't (yet) gone as far as to actually assess whether this helps in the only role it could have at this early stage - assist newbies.
With the above limitations a confused but otherwise competent Rust programmer likely will not find this useful, their problem almost certainly involves a loop or branch before they got into trouble and didn't understand the lifetimes.
So until this can cope with looping and branching the key question is whether it can help a Day One Rust programmer to grok lifetimes stuff early, and avoid the case that seems to happen to some people where they're "fighting the borrow checker" because they don't understand what their code means so they're only ever following suggestions in the diagnostics from the compiler.
However even if they struggle to automate this, developing a schema and a library of standard examples, might help lifetime diagrams become "a thing" the way some places teach children to graph sentence grammar. That would also help other languages with lifetime problems - where the language will not tell you that your code is nonsense, it will just break unexpectedly because not only did you have no idea what the lifetime of this Object is when you wrote the program, neither does your compiler or interpreter.
What I'd like to see is something that does static analysis for reference-counted items. To access a reference-counted item, you often have to call .borrow(), which checks to see if someone else already has it borrowed. This panics on a conflict. That's a good problem for static analysis - is the .borrow() always safe, always going to fail, or unknown? Much of the time, it's always safe and could be optimized out.
This ought to be doable with GhostCell and similar efforts. https://plv.mpi-sws.org/rustbelt/ghostcell/ It doesn't cover the entire spectrum of "borrow safety proofs" but it can be used to address simple cases.
> RustViz generates SVG files with graphical indicators that integrate with mdbook to render visualizations of data-flow in Rust programs.
https://arxiv.org/abs/2011.09012