Checks all your documentation for spelling and grammar mistakes with hunspell and a nlprule based checker for grammar
Rust
364
1,210 commits
updated May 18, 2026
Check your spelling with hunspell and/or nlprule.
Run cargo spellcheck --fix or cargo spellcheck fix to fix all your
documentation comments in order to avoid nasty typos all over your source tree.
Meant as a helper simplifying review as well as improving CI checks after a
learning phase for custom/topic specific lingo.
cargo-spellcheck is also a valuable tool to run from git commit hooks or CI/CD
systems.
cargo spellcheck check
error: spellcheck
--> src/main.rs:44
|
44 | Fun facets shalld cause some erroris.
| ^^^^^^
| - shall or shall d
|
cargo spellcheck fix
error: spellcheck(Hunspell)
--> /media/supersonic1t/projects/cargo-spellcheck/src/literalset.rs:291
|
291 | Returns literl within the Err variant if not adjacent
| ^^^^^^
(13/14) Apply this suggestion [y,n,q,a,d,j,e,?]?
lite
litter
litterer
liter l
liters
literal
liter
» a custom replacement literal
cargo install --locked cargo-spellcheck
The --locked flag is the preferred way of installing to get the tested set of
dependencies.
on OS X, you need to ensure that libclang.dylib can be found by the linker
which can be achieved by setting DYLB_FALLBACK_LIBRARY_PATH:
export DYLD_FALLBACK_LIBRARY_PATH= \
"$(xcode-select --print-path)/Toolchains/XcodeDefault.xctoolchain/usr/lib/"
In Linux, the file is libclang.so which can be installed via:
apt-get install libclang-dev
Afterwards, you can set the variable LIBCLANG_PATH via:
export LIBCLANG_PATH=/usr/lib/llvm-14/lib/
cargo spellcheck completions for autodetection of your current shell via
$SHELL,
or
cargo spellcheck completions --shell zsh
to explicitly specify your shell type.
Commonly it's use like this from your shell's .rc* file:
source <(cargo spellcheck completions)
Contributions are very welcome!
Generally the preferred way of doing so, is to comment in an issue that you would like to tackle the implementation/fix.
This is usually followed by an initial PR where the implementation is then discussed and iteratively refined. No need to get it all correct the first time!
Rust
100.0%
Checks all your documentation for spelling and grammar mistakes with hunspell and a nlprule based checker for grammar
Rust
364
1,210 commits
updated May 18, 2026
Check your spelling with hunspell and/or nlprule.
Run cargo spellcheck --fix or cargo spellcheck fix to fix all your
documentation comments in order to avoid nasty typos all over your source tree.
Meant as a helper simplifying review as well as improving CI checks after a
learning phase for custom/topic specific lingo.
cargo-spellcheck is also a valuable tool to run from git commit hooks or CI/CD
systems.
cargo spellcheck check
error: spellcheck
--> src/main.rs:44
|
44 | Fun facets shalld cause some erroris.
| ^^^^^^
| - shall or shall d
|
cargo spellcheck fix
error: spellcheck(Hunspell)
--> /media/supersonic1t/projects/cargo-spellcheck/src/literalset.rs:291
|
291 | Returns literl within the Err variant if not adjacent
| ^^^^^^
(13/14) Apply this suggestion [y,n,q,a,d,j,e,?]?
lite
litter
litterer
liter l
liters
literal
liter
» a custom replacement literal
cargo install --locked cargo-spellcheck
The --locked flag is the preferred way of installing to get the tested set of
dependencies.
on OS X, you need to ensure that libclang.dylib can be found by the linker
which can be achieved by setting DYLB_FALLBACK_LIBRARY_PATH:
export DYLD_FALLBACK_LIBRARY_PATH= \
"$(xcode-select --print-path)/Toolchains/XcodeDefault.xctoolchain/usr/lib/"
In Linux, the file is libclang.so which can be installed via:
apt-get install libclang-dev
Afterwards, you can set the variable LIBCLANG_PATH via:
export LIBCLANG_PATH=/usr/lib/llvm-14/lib/
cargo spellcheck completions for autodetection of your current shell via
$SHELL,
or
cargo spellcheck completions --shell zsh
to explicitly specify your shell type.
Commonly it's use like this from your shell's .rc* file:
source <(cargo spellcheck completions)
Contributions are very welcome!
Generally the preferred way of doing so, is to comment in an issue that you would like to tackle the implementation/fix.
This is usually followed by an initial PR where the implementation is then discussed and iteratively refined. No need to get it all correct the first time!
Rust
100.0%