This could be useful. I've been plugging away, on and off, on the concept of statically checked back-references for Rust. This is one of the biggest complaints that C/C++ people have about Rust - if A points to B, it's really hard to have a pointer from B to A.
This leads to unsafe workarounds.
You can do it safely with Rc, RefCell, Weak, borrow(), borrow_mut(), upgrade(), and downgrade(). It's verbose, adds run-time overhead, and there's the potential of panicking at run time on a double borrow. But the expressive power is there. This is work in progress, and I have some notes here.[2]
The thing that's hard to check statically that borrows are disjoint as to scope. Borrows have lifetime scopes. If those lifetime scopes do not overlap, the borrows do not clash. Checking this across function calls is hard. (Checking across generic function calls is worse.) The Flowistry approach might help.
The note that "Flowistry does not completely handle interior mutability" is a concern, because we're analyzing things that use RefCell.
The practical problem is to come up with a set of restrictions that are 1) sound, 2) checkable at compile time without too much compute effort, 3) allow programmers to do most of the legit things people want to do with back pointers, such as have a reference to the parent node in a tree, and 4) lead to usable diagnostic messages for problems.
Does this exist for larger/more informal dependency relationships within a function body in other programming languages?
For instance, if I highlight a parameter or variable foo, can I see not only all usages of foo itself, but usages of any variable that was derived from foo?
While borrow usage makes this foolproof, this type of visualization would be tremendously useful for even other types of code.
(As for Flowistry, I can see this being vital for anyone trying to maintain e.g. https://github.com/servo/servo/blob/main/components/layout/f... - perhaps the most daunting single file in a modern codebase I've ever seen! And yes, that's a 400-line function.)
I think (some will correct me if I'm wrong) the general term for this is flow analysis, and TypeScript does it under the hood so it can refine/narrow types. Not with visualisations though
looks fantastic, and rust is probably a great language for this since ownership restricts effects - even if you add it to python, you can't really trust it, because at runtime you can just run up a call stack and modify memory at any time. (though I would still definitely want it, as it's usually going to be correct)
Probably because "Visual Studio Code" is a Microsoft trademark, but the plugin works with all the IDEs based on the open source base (VSCodium, Cursor, etc.)
It wouldn't be weird to call an iPhone app an app for mobile phones. If I make an IntelliJ-only plugin, that's still an IDE plugin even if it doesn't work for all the IDEs in existence.
This is an interesting way to do micro context engineering. This is basically pulling in the minimum relevant code for your current concern, and then you can just sprinkle on some instructions and send off your prompt. Might work reasonably well for very small local models, or just generally cheap inferencing on the server.
Just the other day I was experimenting with moving over a big chunk of a C# codebase (heavy on allocations) to Rust, and the Rust code quickly became very cluttered. C# reads better but is a bit more verbose. Rust is more compact and sometimes very dense.
To make it easier to scan through long files, I wished for an extension that could make the traits appear a few shades darker. This might be even better. Going to give it a try tonight.
I like it. It's compensation for not coding with a style optimized for human reading but since not all the base codes you have would be even close to be described like that, then this is a good useful tool.
Actual paper: [1]
This could be useful. I've been plugging away, on and off, on the concept of statically checked back-references for Rust. This is one of the biggest complaints that C/C++ people have about Rust - if A points to B, it's really hard to have a pointer from B to A. This leads to unsafe workarounds.
You can do it safely with Rc, RefCell, Weak, borrow(), borrow_mut(), upgrade(), and downgrade(). It's verbose, adds run-time overhead, and there's the potential of panicking at run time on a double borrow. But the expressive power is there. This is work in progress, and I have some notes here.[2]
The thing that's hard to check statically that borrows are disjoint as to scope. Borrows have lifetime scopes. If those lifetime scopes do not overlap, the borrows do not clash. Checking this across function calls is hard. (Checking across generic function calls is worse.) The Flowistry approach might help. The note that "Flowistry does not completely handle interior mutability" is a concern, because we're analyzing things that use RefCell.
The practical problem is to come up with a set of restrictions that are 1) sound, 2) checkable at compile time without too much compute effort, 3) allow programmers to do most of the legit things people want to do with back pointers, such as have a reference to the parent node in a tree, and 4) lead to usable diagnostic messages for problems.
[1] https://arxiv.org/abs/2111.13662
[2] https://github.com/John-Nagle/technotes/blob/main/docs/rust/...
Does this exist for larger/more informal dependency relationships within a function body in other programming languages?
For instance, if I highlight a parameter or variable foo, can I see not only all usages of foo itself, but usages of any variable that was derived from foo?
While borrow usage makes this foolproof, this type of visualization would be tremendously useful for even other types of code.
(As for Flowistry, I can see this being vital for anyone trying to maintain e.g. https://github.com/servo/servo/blob/main/components/layout/f... - perhaps the most daunting single file in a modern codebase I've ever seen! And yes, that's a 400-line function.)
I think (some will correct me if I'm wrong) the general term for this is flow analysis, and TypeScript does it under the hood so it can refine/narrow types. Not with visualisations though
This is called program slicing in general
The author has a nice talk diving deep into the routines research and the plugin in a Rust East Coast talk here: https://youtu.be/aYmuMlzvjvc
looks fantastic, and rust is probably a great language for this since ownership restricts effects - even if you add it to python, you can't really trust it, because at runtime you can just run up a call stack and modify memory at any time. (though I would still definitely want it, as it's usually going to be correct)
(Author here) That's exactly why I built this for Rust, and why it's difficult to replicate in any other language.
Hey author, interested about your bio and work.
Any way to follow what you up to?
My personal site (https://willcrichton.net/), lab site (https://cel.cs.brown.edu/), and Mastodon page (https://mastodon.social/@tonofcrates) are all good ways to follow me!
Are you related to Alex Crichton?
Looks cool, but why say 'IDE' instead of just VSCode plugin?
Probably because "Visual Studio Code" is a Microsoft trademark, but the plugin works with all the IDEs based on the open source base (VSCodium, Cursor, etc.)
It says IDE plug-in
Yes, that's the question. It doesn't appear to support any IDEs except VSCode so why use the general term and give an incorrect impression?
Probably because it's based on an idea published in a paper, it's not limited to this particular repo
are we seriously nitpicking every single little thing???
Doesn't seem like a nitpick to me. I use only intellij which is an IDE.
It's like someone would say they created an app for mobile phones (*only for iPhone 17)
It wouldn't be weird to call an iPhone app an app for mobile phones. If I make an IntelliJ-only plugin, that's still an IDE plugin even if it doesn't work for all the IDEs in existence.
This is an interesting way to do micro context engineering. This is basically pulling in the minimum relevant code for your current concern, and then you can just sprinkle on some instructions and send off your prompt. Might work reasonably well for very small local models, or just generally cheap inferencing on the server.
I love this plugin btw.
Why not contribute to rust-analyzer's documentHighlight LSP method? It behaves very similar to what GIFs are showing.
Seems like a very specific feature to have plugin for.
https://microsoft.github.io/language-server-protocol/specifi...
Explained in README: https://github.com/willcrichton/flowistry#why-isnt-flowistry...
It needs MIR
I’ve always dreamed about this + also how the data flows from the outside (who calls this function)
Couldnt we re-use data from the compiler to help with that ?
as far as I understood from the corresponding talk, it uses data from the compiler
These kinds of tools should be standard in understanding code
Just the other day I was experimenting with moving over a big chunk of a C# codebase (heavy on allocations) to Rust, and the Rust code quickly became very cluttered. C# reads better but is a bit more verbose. Rust is more compact and sometimes very dense.
To make it easier to scan through long files, I wished for an extension that could make the traits appear a few shades darker. This might be even better. Going to give it a try tonight.
I like it. It's compensation for not coding with a style optimized for human reading but since not all the base codes you have would be even close to be described like that, then this is a good useful tool.
This looks very useful. I hope this gets developed even further and gets more upstream support eventually.
The idea of this seems to be really good, pulling focus to relevant parts of the code. Is something similar to this available for JS/TS?
this looks fantastic
would love this for typescript
Anyone have suggestions for similar tooling for other languages?
JetBrains IDEs :)
Super cool! I assume it plays nice with rust-analyzer?
is there anything like this for typescript/javascript?
Nice plugin, will try this out tomorrow!
[flagged]