Hello, I'm a relatively new programmer trying to learn Rust, and I can't seem to understand one feature of the rust-analyzer.
According to the RA documentation, unlinked files will not have IDE features available.
That means I don't have features, such as intellisense and autocomplete, to help me while writing code in an unlinked file. (I’m using VSCode)
I can see why the file linking helps with the overall writing of software, as that means the hints and autocompletions will be more comprehensive thanks to RA's understanding of the overall code structure.
In that case, how do experienced programmers or Rust developers go about planning and writing Rust code? For example, do you figure out the entire code structure first, do the necessary file linking, then get down to work?
It's much more incremental than that. When I find a want a new module, I either
- If it's a module for new code, I write
mod child; in the parent module, then run the "create module" assist on that item to create the appropriate file.
- If it's a module for existing code, I use the "extract module" assist. (Sometimes, anyway. I forget it exists and do the former plus copy paste a lot.)
Even if r-a supported as much of its functionality as possible in unlinked files, it still wouldn't be possible to check that the code would really compile if it was in the module tree, because the compiler analyzes the whole crate at once. And that limits how much value could be added here, because:
I believe that in general, it's wise to keep your code it in a state where it compiles, as much as possible during your work. Thus, if I think I have a plan, I should write a small piece of it (creating any modules as necessary) and observe (via check-on-save) that that piece compiles; then write the next piece, and so on. Very frequently, the plan will change for reasons the compiler tells me, like “oh, if I did this it would cause that type to be exposed in the public API; do I want to do that? Does the type also need to change to be a clean public item?”
And there's not a lot of benefit in being able to write a file of substantial source code without deciding where it should go in the module tree and writing the corresponding
mod. You can always move it later.
Thank you for the responses @kpreid @CAD97
Based on your replies, I think my mental model of r-a was different from its intended purpose.
I was previously focused on just the in-editor assistance of r-a in the form of hints, lints, and autocompletions, whereas it seems like r-a is more of an assistant for building entire Rust programs, meaning how the different files and modules compile together to form the final program (on top of the aforementioned features).
I think my confusion stems from a tutorial I was following. The structure of the code in the tutorial was already well defined, and the walkthrough starts from building a module without first laying out all the different module connections necessary for r-a to determine whether the code will compile. Thus, r-a lists the file as unlinked and doesn’t provide hints and autocompletes. Now I know r-a is hinting that this file is currently not useful in the context of the application.
whereas it seems like r-a is more of an assistant for building entire Rust programs
Not really; it's more that “entire programs” — or more precisely, entire crates — are how you develop Rust code. It's not possible to provide “hints, lints, and autocompletions” without the context of the rest of the crate and its dependencies. rust-analyzer is not specifically focused on entire crates over files; all Rust tools will work on entire crates (with occasional exceptions, like that you can run
rustfmt on a single source file).
I see, thanks for clarifying! Your explanation is very helpful.
I’m still wrapping my head around the idea of crates, which hopefully will become clearer as I develop more with Rust.