Add a spell checker to rust-analyzer

[GilShoshan94]

Discussed in #14389

^{Originally posted by GilShoshan94 March 22, 2023}
Hi,

Now, we have a code formater with rustfmt, we have a linter with cargo check or cargo clippy, why not a spell checker?

....

Quoted from #14389 (comment)

For spell checker, a significant chunk of the logic indeed belongs to rust-analyzer. Specifically, rust-analyzer should:

separate keywords from identifiers
separate reference identifiers from definition identifiers. Typos should be checked only for definitions. Its compiler's job to point typos in the references.
separate declarations from definitions. Function names should be checked in traits, but not in trait impls.
find comments
unesape strings (values of string literals should be checked for typos, not the source syntax)

[raphaelricardo10]

Almost every IDE has a built-in spell checker.

For example, for VSCode:
https://marketplace.visualstudio.com/items?itemName=streetsidesoftware.code-spell-checker

It does the job really well and I use it in every single project.

[GilShoshan94]

@raphaelricardo10

That's not the same, the spell checker that you linked is a "simple" checker.
Yes it has some feature that makes it works nicely with code such as knowing how to parse CamelCase or sneak-case but it has no knowledge over the code as does an LSP such as rust-analyzer.

Also performance wise it is slower then one integrated inside r-a that would know what to check only.

I invite you to read the discussion #14389 if you are curious about the benefits to spell check in the LSP.

[ShellCode33]

I don't know how relevant this is but on neovim people usually rely on Tree-sitter to identify code sections where spell checking should be enabled (comments, docstrings, etc.).
Personally I'm not sure I want to rely on an LSP to spell check because 1/ they are way slower than Tree-sitter (it is nice to be able to spellcheck even if the LSP is not completely initialized, especially if you open a file only to add some doc), and 2/ Tree-sitter is an incremental parser, which means it can be used to identify spellcheck regions accurately even if your code doesn't compile.

Let's take the following example:

fn main() {
    some_func(
        arg1,
        arg2, // I want the spelcheker to be working even if I'm not done with the code yet
}

Would rust-analyzer still be able to pick up the fact that this is a comment where spellchecking should be enabled ? Even if the code is not valid yet ? This is probably a bad example, but you get my point

(fun fact: GitHub uses Tree-sitter to highlight the Rust code above)

[lnicola]

@ShellCode33 while probably not as fast as tree-sitter, rust-analyzer does support incremental parsing and has a real understanding of the code, unlike the TextMate grammars you might have encountered before.

If you give it a try, you'll find out that it does supports incomplete code like the one you've shown. So yes, it knows where the comments are.