2020-05-28 08:45:24 -05:00
|
|
|
# Common tools for writing lints
|
|
|
|
|
|
|
|
You may need following tooltips to catch up with common operations.
|
|
|
|
|
|
|
|
- [Common tools for writing lints](#common-tools-for-writing-lints)
|
|
|
|
- [Retrieving the type of an expression](#retrieving-the-type-of-an-expression)
|
2021-12-06 05:33:31 -06:00
|
|
|
- [Checking if an expr is calling a specific method](#checking-if-an-expr-is-calling-a-specific-method)
|
|
|
|
- [Checking for a specific type](#checking-for-a-specific-type)
|
2020-05-28 08:45:24 -05:00
|
|
|
- [Checking if a type implements a specific trait](#checking-if-a-type-implements-a-specific-trait)
|
2021-07-01 11:17:38 -05:00
|
|
|
- [Checking if a type defines a specific method](#checking-if-a-type-defines-a-specific-method)
|
2021-12-06 05:33:31 -06:00
|
|
|
- [Dealing with macros](#dealing-with-macros-and-expansions)
|
2020-05-28 08:45:24 -05:00
|
|
|
|
|
|
|
Useful Rustc dev guide links:
|
|
|
|
- [Stages of compilation](https://rustc-dev-guide.rust-lang.org/compiler-src.html#the-main-stages-of-compilation)
|
2021-09-08 09:31:47 -05:00
|
|
|
- [Diagnostic items](https://rustc-dev-guide.rust-lang.org/diagnostics/diagnostic-items.html)
|
2020-05-28 08:45:24 -05:00
|
|
|
- [Type checking](https://rustc-dev-guide.rust-lang.org/type-checking.html)
|
|
|
|
- [Ty module](https://rustc-dev-guide.rust-lang.org/ty.html)
|
|
|
|
|
2021-12-06 05:33:31 -06:00
|
|
|
## Retrieving the type of an expression
|
2020-05-28 08:45:24 -05:00
|
|
|
|
|
|
|
Sometimes you may want to retrieve the type `Ty` of an expression `Expr`, for example to answer following questions:
|
|
|
|
|
|
|
|
- which type does this expression correspond to (using its [`TyKind`][TyKind])?
|
2020-06-25 18:56:23 -05:00
|
|
|
- is it a sized type?
|
2020-05-28 08:45:24 -05:00
|
|
|
- is it a primitive type?
|
|
|
|
- does it implement a trait?
|
|
|
|
|
2020-07-17 03:47:04 -05:00
|
|
|
This operation is performed using the [`expr_ty()`][expr_ty] method from the [`TypeckResults`][TypeckResults] struct,
|
Overhaul `TyS` and `Ty`.
Specifically, change `Ty` from this:
```
pub type Ty<'tcx> = &'tcx TyS<'tcx>;
```
to this
```
pub struct Ty<'tcx>(Interned<'tcx, TyS<'tcx>>);
```
There are two benefits to this.
- It's now a first class type, so we can define methods on it. This
means we can move a lot of methods away from `TyS`, leaving `TyS` as a
barely-used type, which is appropriate given that it's not meant to
be used directly.
- The uniqueness requirement is now explicit, via the `Interned` type.
E.g. the pointer-based `Eq` and `Hash` comes from `Interned`, rather
than via `TyS`, which wasn't obvious at all.
Much of this commit is boring churn. The interesting changes are in
these files:
- compiler/rustc_middle/src/arena.rs
- compiler/rustc_middle/src/mir/visit.rs
- compiler/rustc_middle/src/ty/context.rs
- compiler/rustc_middle/src/ty/mod.rs
Specifically:
- Most mentions of `TyS` are removed. It's very much a dumb struct now;
`Ty` has all the smarts.
- `TyS` now has `crate` visibility instead of `pub`.
- `TyS::make_for_test` is removed in favour of the static `BOOL_TY`,
which just works better with the new structure.
- The `Eq`/`Ord`/`Hash` impls are removed from `TyS`. `Interned`s impls
of `Eq`/`Hash` now suffice. `Ord` is now partly on `Interned`
(pointer-based, for the `Equal` case) and partly on `TyS`
(contents-based, for the other cases).
- There are many tedious sigil adjustments, i.e. adding or removing `*`
or `&`. They seem to be unavoidable.
2022-01-24 21:13:38 -06:00
|
|
|
that gives you access to the underlying structure [`Ty`][Ty].
|
2020-05-28 08:45:24 -05:00
|
|
|
|
|
|
|
Example of use:
|
|
|
|
```rust
|
2020-06-25 15:41:36 -05:00
|
|
|
impl LateLintPass<'_> for MyStructLint {
|
|
|
|
fn check_expr(&mut self, cx: &LateContext<'_>, expr: &Expr<'_>) {
|
2020-05-28 08:45:24 -05:00
|
|
|
// Get type of `expr`
|
2020-07-17 03:47:04 -05:00
|
|
|
let ty = cx.typeck_results().expr_ty(expr);
|
2020-05-28 08:45:24 -05:00
|
|
|
// Match its kind to enter its type
|
|
|
|
match ty.kind {
|
|
|
|
ty::Adt(adt_def, _) if adt_def.is_struct() => println!("Our `expr` is a struct!"),
|
|
|
|
_ => ()
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
```
|
|
|
|
|
2020-07-17 03:47:04 -05:00
|
|
|
Similarly in [`TypeckResults`][TypeckResults] methods, you have the [`pat_ty()`][pat_ty] method
|
2020-05-28 08:45:24 -05:00
|
|
|
to retrieve a type from a pattern.
|
|
|
|
|
|
|
|
Two noticeable items here:
|
2020-10-23 15:16:59 -05:00
|
|
|
- `cx` is the lint context [`LateContext`][LateContext]. The two most useful
|
|
|
|
data structures in this context are `tcx` and the `TypeckResults` returned by
|
|
|
|
`LateContext::typeck_results`, allowing us to jump to type definitions and
|
|
|
|
other compilation stages such as HIR.
|
|
|
|
- `typeck_results`'s return value is [`TypeckResults`][TypeckResults] and is
|
|
|
|
created by type checking step, it includes useful information such as types
|
|
|
|
of expressions, ways to resolve methods and so on.
|
2020-05-28 08:45:24 -05:00
|
|
|
|
2021-12-06 05:33:31 -06:00
|
|
|
## Checking if an expr is calling a specific method
|
2020-06-09 09:36:01 -05:00
|
|
|
|
|
|
|
Starting with an `expr`, you can check whether it is calling a specific method `some_method`:
|
|
|
|
|
|
|
|
```rust
|
2022-01-13 06:18:19 -06:00
|
|
|
impl<'tcx> LateLintPass<'tcx> for MyStructLint {
|
2020-06-25 15:41:36 -05:00
|
|
|
fn check_expr(&mut self, cx: &LateContext<'tcx>, expr: &'tcx hir::Expr<'_>) {
|
2022-05-09 08:23:16 -05:00
|
|
|
// Check our expr is calling a method
|
|
|
|
if let hir::ExprKind::MethodCall(path, _, [_self_arg, ..]) = &expr.kind
|
2020-06-09 09:36:01 -05:00
|
|
|
// Check the name of this method is `some_method`
|
2022-05-09 08:23:16 -05:00
|
|
|
&& path.ident.name == sym!(some_method)
|
2021-12-06 05:33:31 -06:00
|
|
|
// Optionally, check the type of the self argument.
|
|
|
|
// - See "Checking for a specific type"
|
2022-05-09 08:23:16 -05:00
|
|
|
{
|
2020-06-09 09:36:01 -05:00
|
|
|
// ...
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
```
|
|
|
|
|
2021-12-06 05:33:31 -06:00
|
|
|
## Checking for a specific type
|
|
|
|
|
|
|
|
There are three ways to check if an expression type is a specific type we want to check for.
|
|
|
|
All of these methods only check for the base type, generic arguments have to be checked separately.
|
|
|
|
|
|
|
|
```rust
|
|
|
|
use clippy_utils::ty::{is_type_diagnostic_item, is_type_lang_item};
|
|
|
|
use clippy_utils::{paths, match_def_path};
|
|
|
|
use rustc_span::symbol::sym;
|
|
|
|
use rustc_hir::LangItem;
|
|
|
|
|
|
|
|
impl LateLintPass<'_> for MyStructLint {
|
|
|
|
fn check_expr(&mut self, cx: &LateContext<'_>, expr: &Expr<'_>) {
|
|
|
|
// Getting the expression type
|
|
|
|
let ty = cx.typeck_results().expr_ty(expr);
|
|
|
|
|
|
|
|
// 1. Using diagnostic items
|
|
|
|
// The last argument is the diagnostic item to check for
|
|
|
|
if is_type_diagnostic_item(cx, ty, sym::Option) {
|
|
|
|
// The type is an `Option`
|
|
|
|
}
|
|
|
|
|
|
|
|
// 2. Using lang items
|
|
|
|
if is_type_lang_item(cx, ty, LangItem::RangeFull) {
|
|
|
|
// The type is a full range like `.drain(..)`
|
|
|
|
}
|
|
|
|
|
|
|
|
// 3. Using the type path
|
|
|
|
// This method should be avoided if possible
|
|
|
|
if match_def_path(cx, def_id, &paths::RESULT) {
|
|
|
|
// The type is a `core::result::Result`
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
```
|
|
|
|
|
|
|
|
Prefer using diagnostic items and lang items where possible.
|
|
|
|
|
|
|
|
## Checking if a type implements a specific trait
|
2020-05-28 08:45:24 -05:00
|
|
|
|
2021-09-08 09:31:47 -05:00
|
|
|
There are three ways to do this, depending on if the target trait has a diagnostic item, lang item or neither.
|
2020-05-28 08:45:24 -05:00
|
|
|
|
|
|
|
```rust
|
2021-09-08 09:31:47 -05:00
|
|
|
use clippy_utils::{implements_trait, is_trait_method, match_trait_method, paths};
|
|
|
|
use rustc_span::symbol::sym;
|
2020-05-28 08:45:24 -05:00
|
|
|
|
2020-06-25 15:41:36 -05:00
|
|
|
impl LateLintPass<'_> for MyStructLint {
|
|
|
|
fn check_expr(&mut self, cx: &LateContext<'_>, expr: &Expr<'_>) {
|
2021-09-08 09:31:47 -05:00
|
|
|
// 1. Using diagnostic items with the expression
|
|
|
|
// we use `is_trait_method` function from Clippy's utils
|
|
|
|
if is_trait_method(cx, expr, sym::Iterator) {
|
|
|
|
// method call in `expr` belongs to `Iterator` trait
|
2020-05-28 08:45:24 -05:00
|
|
|
}
|
|
|
|
|
2021-09-08 09:31:47 -05:00
|
|
|
// 2. Using lang items with the expression type
|
2020-07-17 03:47:04 -05:00
|
|
|
let ty = cx.typeck_results().expr_ty(expr);
|
2020-05-28 08:45:24 -05:00
|
|
|
if cx.tcx.lang_items()
|
|
|
|
// we are looking for the `DefId` of `Drop` trait in lang items
|
|
|
|
.drop_trait()
|
|
|
|
// then we use it with our type `ty` by calling `implements_trait` from Clippy's utils
|
|
|
|
.map_or(false, |id| implements_trait(cx, ty, id, &[])) {
|
|
|
|
// `expr` implements `Drop` trait
|
|
|
|
}
|
2021-09-08 09:31:47 -05:00
|
|
|
|
|
|
|
// 3. Using the type path with the expression
|
|
|
|
// we use `match_trait_method` function from Clippy's utils
|
2021-12-06 05:33:31 -06:00
|
|
|
// (This method should be avoided if possible)
|
2021-09-08 09:31:47 -05:00
|
|
|
if match_trait_method(cx, expr, &paths::INTO) {
|
|
|
|
// `expr` implements `Into` trait
|
|
|
|
}
|
2020-05-28 08:45:24 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
```
|
|
|
|
|
2021-09-08 09:31:47 -05:00
|
|
|
> Prefer using diagnostic and lang items, if the target trait has one.
|
2020-05-28 08:45:24 -05:00
|
|
|
|
|
|
|
We access lang items through the type context `tcx`. `tcx` is of type [`TyCtxt`][TyCtxt] and is defined in the `rustc_middle` crate.
|
2021-09-08 09:31:47 -05:00
|
|
|
A list of defined paths for Clippy can be found in [paths.rs][paths]
|
2020-05-28 08:45:24 -05:00
|
|
|
|
2021-12-06 05:33:31 -06:00
|
|
|
## Checking if a type defines a specific method
|
2020-06-09 09:36:01 -05:00
|
|
|
|
|
|
|
To check if our type defines a method called `some_method`:
|
|
|
|
|
|
|
|
```rust
|
2022-05-24 07:53:08 -05:00
|
|
|
use clippy_utils::ty::is_type_diagnostic_item;
|
|
|
|
use clippy_utils::return_ty;
|
2020-06-09 09:36:01 -05:00
|
|
|
|
2020-06-25 15:41:36 -05:00
|
|
|
impl<'tcx> LateLintPass<'tcx> for MyTypeImpl {
|
|
|
|
fn check_impl_item(&mut self, cx: &LateContext<'tcx>, impl_item: &'tcx ImplItem<'_>) {
|
2022-05-09 08:23:16 -05:00
|
|
|
// Check if item is a method/function
|
|
|
|
if let ImplItemKind::Fn(ref signature, _) = impl_item.kind
|
2020-06-09 09:36:01 -05:00
|
|
|
// Check the method is named `some_method`
|
2022-05-09 08:23:16 -05:00
|
|
|
&& impl_item.ident.name == sym!(some_method)
|
2020-06-09 09:36:01 -05:00
|
|
|
// We can also check it has a parameter `self`
|
2022-05-09 08:23:16 -05:00
|
|
|
&& signature.decl.implicit_self.has_implicit_self()
|
2020-06-09 09:36:01 -05:00
|
|
|
// We can go further and even check if its return type is `String`
|
2022-05-09 08:23:16 -05:00
|
|
|
&& is_type_diagnostic_item(cx, return_ty(cx, impl_item.hir_id), sym!(string_type))
|
|
|
|
{
|
|
|
|
// ...
|
2020-06-09 09:36:01 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
```
|
|
|
|
|
2021-12-06 05:33:31 -06:00
|
|
|
## Dealing with macros and expansions
|
2020-05-28 08:45:24 -05:00
|
|
|
|
2021-12-06 05:33:31 -06:00
|
|
|
Keep in mind that macros are already expanded and desugaring is already applied
|
|
|
|
to the code representation that you are working with in Clippy. This unfortunately causes a lot of
|
|
|
|
false positives because macro expansions are "invisible" unless you actively check for them.
|
|
|
|
Generally speaking, code with macro expansions should just be ignored by Clippy because that code can be
|
|
|
|
dynamic in ways that are difficult or impossible to see.
|
|
|
|
Use the following functions to deal with macros:
|
2020-05-28 08:45:24 -05:00
|
|
|
|
2021-12-06 05:33:31 -06:00
|
|
|
- `span.from_expansion()`: detects if a span is from macro expansion or desugaring.
|
|
|
|
Checking this is a common first step in a lint.
|
2020-05-28 08:45:24 -05:00
|
|
|
|
2021-12-06 05:33:31 -06:00
|
|
|
```rust
|
|
|
|
if expr.span.from_expansion() {
|
|
|
|
// just forget it
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
```
|
2020-05-28 08:45:24 -05:00
|
|
|
|
2021-12-06 05:33:31 -06:00
|
|
|
- `span.ctxt()`: the span's context represents whether it is from expansion, and if so, which macro call expanded it.
|
|
|
|
It is sometimes useful to check if the context of two spans are equal.
|
2020-05-28 08:45:24 -05:00
|
|
|
|
2021-12-06 05:33:31 -06:00
|
|
|
```rust
|
|
|
|
// expands to `1 + 0`, but don't lint
|
|
|
|
1 + mac!()
|
|
|
|
```
|
|
|
|
```rust
|
|
|
|
if left.span.ctxt() != right.span.ctxt() {
|
|
|
|
// the coder most likely cannot modify this expression
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
```
|
|
|
|
Note: Code that is not from expansion is in the "root" context. So any spans where `from_expansion` returns `true` can
|
|
|
|
be assumed to have the same context. And so just using `span.from_expansion()` is often good enough.
|
2020-05-28 08:45:24 -05:00
|
|
|
|
|
|
|
|
2021-12-06 05:33:31 -06:00
|
|
|
- `in_external_macro(span)`: detect if the given span is from a macro defined in a foreign crate.
|
|
|
|
If you want the lint to work with macro-generated code, this is the next line of defense to avoid macros
|
|
|
|
not defined in the current crate. It doesn't make sense to lint code that the coder can't change.
|
2020-05-28 08:45:24 -05:00
|
|
|
|
2021-12-06 05:33:31 -06:00
|
|
|
You may want to use it for example to not start linting in macros from other crates
|
2020-05-28 08:45:24 -05:00
|
|
|
|
2021-12-06 05:33:31 -06:00
|
|
|
```rust
|
|
|
|
#[macro_use]
|
|
|
|
extern crate a_crate_with_macros;
|
2020-05-28 08:45:24 -05:00
|
|
|
|
2021-12-06 05:33:31 -06:00
|
|
|
// `foo` is defined in `a_crate_with_macros`
|
|
|
|
foo!("bar");
|
2020-05-28 08:45:24 -05:00
|
|
|
|
2021-12-06 05:33:31 -06:00
|
|
|
// if we lint the `match` of `foo` call and test its span
|
|
|
|
assert_eq!(in_external_macro(cx.sess(), match_span), true);
|
|
|
|
```
|
2020-05-28 08:45:24 -05:00
|
|
|
|
2022-02-10 11:40:06 -06:00
|
|
|
- `span.ctxt()`: the span's context represents whether it is from expansion, and if so, what expanded it
|
|
|
|
|
|
|
|
One thing `SpanContext` is useful for is to check if two spans are in the same context. For example,
|
|
|
|
in `a == b`, `a` and `b` have the same context. In a `macro_rules!` with `a == $b`, `$b` is expanded to some
|
|
|
|
expression with a different context from `a`.
|
2020-05-28 08:45:24 -05:00
|
|
|
|
2021-12-06 05:33:31 -06:00
|
|
|
```rust
|
|
|
|
macro_rules! m {
|
|
|
|
($a:expr, $b:expr) => {
|
|
|
|
if $a.is_some() {
|
|
|
|
$b;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2020-05-28 08:45:24 -05:00
|
|
|
|
2021-12-06 05:33:31 -06:00
|
|
|
let x: Option<u32> = Some(42);
|
|
|
|
m!(x, x.unwrap());
|
2020-05-28 08:45:24 -05:00
|
|
|
|
2021-12-06 05:33:31 -06:00
|
|
|
// These spans are not from the same context
|
|
|
|
// x.is_some() is from inside the macro
|
|
|
|
// x.unwrap() is from outside the macro
|
2022-02-10 11:40:06 -06:00
|
|
|
assert_eq!(x_is_some_span.ctxt(), x_unwrap_span.ctxt());
|
2021-12-06 05:33:31 -06:00
|
|
|
```
|
2020-05-28 08:45:24 -05:00
|
|
|
|
Overhaul `TyS` and `Ty`.
Specifically, change `Ty` from this:
```
pub type Ty<'tcx> = &'tcx TyS<'tcx>;
```
to this
```
pub struct Ty<'tcx>(Interned<'tcx, TyS<'tcx>>);
```
There are two benefits to this.
- It's now a first class type, so we can define methods on it. This
means we can move a lot of methods away from `TyS`, leaving `TyS` as a
barely-used type, which is appropriate given that it's not meant to
be used directly.
- The uniqueness requirement is now explicit, via the `Interned` type.
E.g. the pointer-based `Eq` and `Hash` comes from `Interned`, rather
than via `TyS`, which wasn't obvious at all.
Much of this commit is boring churn. The interesting changes are in
these files:
- compiler/rustc_middle/src/arena.rs
- compiler/rustc_middle/src/mir/visit.rs
- compiler/rustc_middle/src/ty/context.rs
- compiler/rustc_middle/src/ty/mod.rs
Specifically:
- Most mentions of `TyS` are removed. It's very much a dumb struct now;
`Ty` has all the smarts.
- `TyS` now has `crate` visibility instead of `pub`.
- `TyS::make_for_test` is removed in favour of the static `BOOL_TY`,
which just works better with the new structure.
- The `Eq`/`Ord`/`Hash` impls are removed from `TyS`. `Interned`s impls
of `Eq`/`Hash` now suffice. `Ord` is now partly on `Interned`
(pointer-based, for the `Equal` case) and partly on `TyS`
(contents-based, for the other cases).
- There are many tedious sigil adjustments, i.e. adding or removing `*`
or `&`. They seem to be unavoidable.
2022-01-24 21:13:38 -06:00
|
|
|
[Ty]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.Ty.html
|
2020-05-28 08:45:24 -05:00
|
|
|
[TyKind]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.TyKind.html
|
2020-07-17 03:47:04 -05:00
|
|
|
[TypeckResults]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TypeckResults.html
|
|
|
|
[expr_ty]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TypeckResults.html#method.expr_ty
|
2020-05-28 08:45:24 -05:00
|
|
|
[LateContext]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/struct.LateContext.html
|
|
|
|
[TyCtxt]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.TyCtxt.html
|
2020-07-17 03:47:04 -05:00
|
|
|
[pat_ty]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.TypeckResults.html#method.pat_ty
|
2021-02-25 04:25:22 -06:00
|
|
|
[paths]: ../clippy_utils/src/paths.rs
|