The core runner for RSLint responsible for the bulk of the linter’s work.
The crate is not RSLint-specific and can be used from any project. The runner is responsible
for taking a list of rules, and source code and running the linter on it. It is important to decouple
the CLI work and the low level linting work from eachother to be able to reuse the linter facilities.
Therefore, the core runner should never do anything
The structure at the core of the crate is the
CST rules run on a single file and its concrete syntax tree produced by
The rules have a couple of restrictions for clarity and speed, these include:
- all cst rules must be
Syncso they can be run in parallel
- rules may never rely on the results of other rules, this is impossible because rules are run in parallel
- rules should never make any network or file requests
To run a single rule you can find the rule you want in the
groups module and submodules within. Then
to run a rule in full on a syntax tree you can use
Rules can also be run on individual nodes using the functions on
⚠️ note however that many rules rely on checking tokens or the root and running on single nodes
may yield incorrect results, you should only do this if you know about the rule’s implementation.
pub use crate::directives::apply_top_level_directives;
pub use crate::directives::skip_node;
pub use crate::directives::Directive;
Automatic rule fixing utilities
Directives used to configure or ignore rules. These take place of comments over nodes or comments at the top level.
All of the groups of built in rules in the linter.
Commonly used items by rules. These include some AST definitions, and utilities.
General utilities to make linting easier.
A macro to easily generate rule boilerplate code.
Macro for easily making a rule group hashmap.
This will call
::new() on each rule.
A macro for generating linter rule tests.
A utility structure for housing CST rules for a linting run.
A diagnostic message that can give information like errors or warnings.
A structure representing either a concrete (in-disk) or virtual (temporary/non-disk) js, ts, or mjs file.
The result of linting a file.
Context given to a rule when running it.
The result of running a single rule on a syntax tree.
The overall result of running a single rule or linting a file.
The level configured for a rule.
A severity level for diagnostic messages.
A tag describing properties present on a rule, such as if the rule is recommended or if it runs on only some languages.
The main type of rule run by the runner. The rule takes individual
nodes inside of a Concrete Syntax Tree and checks them.
It may also take individual syntax tokens.
Rule must be all be
Sync, because rules are run in parallel.
A trait describing rules for which their configuration can be automatically deduced (inferred) using parsed syntax trees
A generic trait which describes things common to a rule regardless on what they run on.
A value which can be used as the range inside of a diagnostic.
Get a group’s rules by the group name.
Get all of the built in rules which can have their options inferred using multiple syntax nodes
Inferable for more information.
Get a rule by its kebab-case name.
Get a rule and its documentation.
Get a suggestion for an incorrect rule name for things such as “did you mean …?”
Lint a file with a specific rule store.
Run a single run on an entire parsed file.