As I read this chapter I think it would be useful if here was extension who would add and update permissions on variables, so I could visually see permissions variable have and need for some methods or functions. But I had not seen such extension. Would it be even possible to make one like this?
I'd say you already have everything you need. Personally, I'd say rust-analyzer and Even Better TOML are all you need for a pleasant Rust experience in VS Code.
I don't quite understand the term permissions in this context but have you realized that rust-analyzer already highlights variables and methods differently depending on there mutability? AFAIK the standard is to for rust-analyzer to underline mutable variables and methods.
Nice. Now I can learn more about permissions using Aquascope Playground, because it looks like it will be hard to install and use installed version.
But it looks like it does not work very well. Even in Book it has bugs in this code.
fn main ()
{
let mut s = String::from("Hello");
let s_ref = &s;
println!("{s_ref}");
}
It shows that s lost R permission because of s_ref, but if I change it to this
fn main ()
{
let mut s = String::from("Hello");
let s_ref = &s;
println!("{s}");
println!("{s_ref}");
}
s is printed to terminal and it retains R permission. Unless Rust removes all permissions from variable if it is not used below and retains some permissions if it is used.
I have seen on youtube someone use extension who shows syntax error as text on line where is error.
For example if you don't add semicolon it will add "Syntax Error: expected SEMICOLON" at the end of line. Now VS Code only adds some red line at the missing semicolon place, but it is so small it is hard to see.
Permissions is nice, but now I think it may be impossible to add to VS Code, because they are dynamic and may change every line. For example this code
fn main ()
{
let mut s = 5;
let s_ref = &s;
s += 1;
println!("{s}");
println!("{s_ref}");
}
s is mutable, but only before and after s_ref variable. This code will not be compiled by compiler, because s can't be mutated in this place. If I moved s +=1; line below println!("{s_ref}"); it would compile. Because variable s will lose write (W) permission because of s_ref variable and will get it back after last time s_ref is used.
It seems like the tool is still a little rough around the edges as it's still under development.
Just guessing here, but maybe the borrow checker implementation they use (Polonius, it seems) just doesn't want to do extra work here. Since s is not used anymore, there's usually no point in spending time figuring out what you can do with it, and so you get this somewhat confusing output.