It can't. It uses ownership types in Rust to do the analysis. It can be fooled by Rust's interior mutability. Other languages don't have a type system that enables this.
If Eclipse's archaic(!) variable renaming feature for C++ can distinguish between related and unrelated variables which have the same name, you can implement this thing in almost any language.
Eclipse CDT has a real-time static analyzer for the code you're working on though. It's not as naive as it looks from a distance.
Are you adding one to an integer and adding two to another integer, or are you adding three to a single integer?
In other words are the two pointers actually pointing to the same variable? There's no way to know. When you select one pointer, should the other also be highlighted?
But in Rust you cannot have two mutable references to a single variable so the above cannot happen.
Variable renaming is a much much simpler task than this. Of course it is archaic and has existed for a long time.
From thinking about it and merely looking at the gif example... I think you could actually get there via language server alone - at least mostly?
It just highlights parts that interface with a symbol, right? And that's information the language server is supposed to expose.
You'd "just" have to make a x+1 mapping to highlight anything that's touching the symbol
To be clear, I'm just speculating here and not speaking with authority on the topic. It's possible I'm missing something which makes this approach infeasible in practice
It's not exactly rare to avoid mutability/use a functional style in application code, and even in mutable code, IME aliasing is rare. In some ways Rust's rules are kind of a formalization of what was already good practice in C. Variable scope is also usually small. Turns out things that are easier for the computer to analyze are also easier for people to analyze, so it's long been good practice to structure your code in easy to analyze ways.
LLMs are getting better and cheaper. It's ridiculous overkill for the task, but they could potentially do something like this and more sophisticated versions highlighting related code on other dimensions.
Programming languages are built upon mathematically defined and deterministic syntax. You can analyze them with formulae, take concrete and deterministic actions on the syntax tree.
There's no need to unleash a fuzzy and inefficient network on something designed to be deterministic and parseable.
Visual Studio is irritatingly doing the opposite. If it detects unused methods/variables it will make them darker (which in general is quite useful), but it also does so when you're still busy creating new methods and just haven't linked them to anything yet.
It can't. It uses ownership types in Rust to do the analysis. It can be fooled by Rust's interior mutability. Other languages don't have a type system that enables this.
If Eclipse's archaic(!) variable renaming feature for C++ can distinguish between related and unrelated variables which have the same name, you can implement this thing in almost any language.
Eclipse CDT has a real-time static analyzer for the code you're working on though. It's not as naive as it looks from a distance.
Consider this simple C code:
Are you adding one to an integer and adding two to another integer, or are you adding three to a single integer?
In other words are the two pointers actually pointing to the same variable? There's no way to know. When you select one pointer, should the other also be highlighted?
But in Rust you cannot have two mutable references to a single variable so the above cannot happen.
Variable renaming is a much much simpler task than this. Of course it is archaic and has existed for a long time.
2 replies →
From thinking about it and merely looking at the gif example... I think you could actually get there via language server alone - at least mostly?
It just highlights parts that interface with a symbol, right? And that's information the language server is supposed to expose.
You'd "just" have to make a x+1 mapping to highlight anything that's touching the symbol
To be clear, I'm just speculating here and not speaking with authority on the topic. It's possible I'm missing something which makes this approach infeasible in practice
You merely explain why you can't copy the implementation strategy.
But that says nothing about providing the same value to the user in other languages via different means.
You merely assume an alternative implementation strategy exists and that it provides the same value to the user.
But that says nothing about whether it actually can exist.
3 replies →
It's not exactly rare to avoid mutability/use a functional style in application code, and even in mutable code, IME aliasing is rare. In some ways Rust's rules are kind of a formalization of what was already good practice in C. Variable scope is also usually small. Turns out things that are easier for the computer to analyze are also easier for people to analyze, so it's long been good practice to structure your code in easy to analyze ways.
LLMs are getting better and cheaper. It's ridiculous overkill for the task, but they could potentially do something like this and more sophisticated versions highlighting related code on other dimensions.
Programming languages are built upon mathematically defined and deterministic syntax. You can analyze them with formulae, take concrete and deterministic actions on the syntax tree.
There's no need to unleash a fuzzy and inefficient network on something designed to be deterministic and parseable.
2 replies →
Shouldn't be too difficult for C# with Roslyn
Visual Studio is irritatingly doing the opposite. If it detects unused methods/variables it will make them darker (which in general is quite useful), but it also does so when you're still busy creating new methods and just haven't linked them to anything yet.