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/...

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.)

Seems like a very specific feature to have plugin for.

https://microsoft.github.io/language-server-protocol/specifi...

Couldnt we re-use data from the compiler to help with that ?

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.

would love this for typescript

I love this plugin btw.