2020-05-28 13:45:24 +00: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 11:33:31 +00: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 13:45:24 +00:00
|
|
|
- [Checking if a type implements a specific trait](#checking-if-a-type-implements-a-specific-trait)
|
2021-07-01 16:17:38 +00:00
|
|
|
- [Checking if a type defines a specific method](#checking-if-a-type-defines-a-specific-method)
|
2021-12-06 11:33:31 +00:00
|
|
|
- [Dealing with macros](#dealing-with-macros-and-expansions)
|
2020-05-28 13:45:24 +00: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 14:31:47 +00:00
|
|
|
- [Diagnostic items](https://rustc-dev-guide.rust-lang.org/diagnostics/diagnostic-items.html)
|
2020-05-28 13:45:24 +00: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 11:33:31 +00:00
|
|
|
## Retrieving the type of an expression
|
2020-05-28 13:45:24 +00:00
|
|
|
|
2022-06-16 15:39:06 +00:00
|
|
|
Sometimes you may want to retrieve the type `Ty` of an expression `Expr`, for
|
|
|
|
example to answer following questions:
|
2020-05-28 13:45:24 +00:00
|
|
|
|
|
|
|
- which type does this expression correspond to (using its [`TyKind`][TyKind])?
|
2020-06-25 23:56:23 +00:00
|
|
|
- is it a sized type?
|
2020-05-28 13:45:24 +00:00
|
|
|
- is it a primitive type?
|
|
|
|
- does it implement a trait?
|
|
|
|
|
2022-06-16 15:39:06 +00:00
|
|
|
This operation is performed using the [`expr_ty()`][expr_ty] method from the
|
|
|
|
[`TypeckResults`][TypeckResults] struct, that gives you access to the underlying
|
|
|
|
structure [`Ty`][Ty].
|
2020-05-28 13:45:24 +00:00
|
|
|
|
|
|
|
Example of use:
|
|
|
|
```rust
|
2020-06-25 20:41:36 +00:00
|
|
|
impl LateLintPass<'_> for MyStructLint {
|
|
|
|
fn check_expr(&mut self, cx: &LateContext<'_>, expr: &Expr<'_>) {
|
2020-05-28 13:45:24 +00:00
|
|
|
// Get type of `expr`
|
2020-07-17 08:47:04 +00:00
|
|
|
let ty = cx.typeck_results().expr_ty(expr);
|
2020-05-28 13:45:24 +00: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!"),
|
|
|
|
_ => ()
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
```
|
|
|
|
|
2022-06-16 15:39:06 +00:00
|
|
|
Similarly in [`TypeckResults`][TypeckResults] methods, you have the
|
|
|
|
[`pat_ty()`][pat_ty] method to retrieve a type from a pattern.
|
2020-05-28 13:45:24 +00:00
|
|
|
|
|
|
|
Two noticeable items here:
|
2020-10-23 20:16:59 +00: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
|
2022-06-16 15:39:06 +00:00
|
|
|
created by type checking step, it includes useful information such as types of
|
|
|
|
expressions, ways to resolve methods and so on.
|
2020-05-28 13:45:24 +00:00
|
|
|
|
2021-12-06 11:33:31 +00:00
|
|
|
## Checking if an expr is calling a specific method
|
2020-06-09 14:36:01 +00:00
|
|
|
|
2022-06-16 15:39:06 +00:00
|
|
|
Starting with an `expr`, you can check whether it is calling a specific method
|
|
|
|
`some_method`:
|
2020-06-09 14:36:01 +00:00
|
|
|
|
|
|
|
```rust
|
2022-01-13 12:18:19 +00:00
|
|
|
impl<'tcx> LateLintPass<'tcx> for MyStructLint {
|
2020-06-25 20:41:36 +00:00
|
|
|
fn check_expr(&mut self, cx: &LateContext<'tcx>, expr: &'tcx hir::Expr<'_>) {
|
2022-05-21 11:24:00 +00:00
|
|
|
// Check our expr is calling a method
|
|
|
|
if let hir::ExprKind::MethodCall(path, _, [_self_arg, ..]) = &expr.kind
|
2020-06-09 14:36:01 +00:00
|
|
|
// Check the name of this method is `some_method`
|
2022-05-21 11:24:00 +00:00
|
|
|
&& path.ident.name == sym!(some_method)
|
2021-12-06 11:33:31 +00:00
|
|
|
// Optionally, check the type of the self argument.
|
|
|
|
// - See "Checking for a specific type"
|
2022-05-21 11:24:00 +00:00
|
|
|
{
|
2020-06-09 14:36:01 +00:00
|
|
|
// ...
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
```
|
|
|
|
|
2021-12-06 11:33:31 +00:00
|
|
|
## Checking for a specific type
|
|
|
|
|
2022-06-16 15:39:06 +00:00
|
|
|
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.
|
2021-12-06 11:33:31 +00:00
|
|
|
|
|
|
|
```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 13:45:24 +00:00
|
|
|
|
2022-06-16 15:39:06 +00: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 13:45:24 +00:00
|
|
|
|
|
|
|
```rust
|
2021-09-08 14:31:47 +00:00
|
|
|
use clippy_utils::{implements_trait, is_trait_method, match_trait_method, paths};
|
|
|
|
use rustc_span::symbol::sym;
|
2020-05-28 13:45:24 +00:00
|
|
|
|
2020-06-25 20:41:36 +00:00
|
|
|
impl LateLintPass<'_> for MyStructLint {
|
|
|
|
fn check_expr(&mut self, cx: &LateContext<'_>, expr: &Expr<'_>) {
|
2021-09-08 14:31:47 +00: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 13:45:24 +00:00
|
|
|
}
|
|
|
|
|
2021-09-08 14:31:47 +00:00
|
|
|
// 2. Using lang items with the expression type
|
2020-07-17 08:47:04 +00:00
|
|
|
let ty = cx.typeck_results().expr_ty(expr);
|
2020-05-28 13:45:24 +00: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 14:31:47 +00:00
|
|
|
|
|
|
|
// 3. Using the type path with the expression
|
|
|
|
// we use `match_trait_method` function from Clippy's utils
|
2021-12-06 11:33:31 +00:00
|
|
|
// (This method should be avoided if possible)
|
2021-09-08 14:31:47 +00:00
|
|
|
if match_trait_method(cx, expr, &paths::INTO) {
|
|
|
|
// `expr` implements `Into` trait
|
|
|
|
}
|
2020-05-28 13:45:24 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
```
|
|
|
|
|
2021-09-08 14:31:47 +00:00
|
|
|
> Prefer using diagnostic and lang items, if the target trait has one.
|
2020-05-28 13:45:24 +00:00
|
|
|
|
2022-06-16 15:39:06 +00:00
|
|
|
We access lang items through the type context `tcx`. `tcx` is of type
|
|
|
|
[`TyCtxt`][TyCtxt] and is defined in the `rustc_middle` crate. A list of defined
|
|
|
|
paths for Clippy can be found in [paths.rs][paths]
|
2020-05-28 13:45:24 +00:00
|
|
|
|
2021-12-06 11:33:31 +00:00
|
|
|
## Checking if a type defines a specific method
|
2020-06-09 14:36:01 +00:00
|
|
|
|
|
|
|
To check if our type defines a method called `some_method`:
|
|
|
|
|
|
|
|
```rust
|
2022-06-04 11:34:07 +00:00
|
|
|
use clippy_utils::ty::is_type_diagnostic_item;
|
|
|
|
use clippy_utils::return_ty;
|
2020-06-09 14:36:01 +00:00
|
|
|
|
2020-06-25 20:41:36 +00:00
|
|
|
impl<'tcx> LateLintPass<'tcx> for MyTypeImpl {
|
|
|
|
fn check_impl_item(&mut self, cx: &LateContext<'tcx>, impl_item: &'tcx ImplItem<'_>) {
|
2022-05-21 11:24:00 +00:00
|
|
|
// Check if item is a method/function
|
|
|
|
if let ImplItemKind::Fn(ref signature, _) = impl_item.kind
|
2020-06-09 14:36:01 +00:00
|
|
|
// Check the method is named `some_method`
|
2022-05-21 11:24:00 +00:00
|
|
|
&& impl_item.ident.name == sym!(some_method)
|
2020-06-09 14:36:01 +00:00
|
|
|
// We can also check it has a parameter `self`
|
2022-05-21 11:24:00 +00:00
|
|
|
&& signature.decl.implicit_self.has_implicit_self()
|
2020-06-09 14:36:01 +00:00
|
|
|
// We can go further and even check if its return type is `String`
|
2022-05-21 11:24:00 +00:00
|
|
|
&& is_type_diagnostic_item(cx, return_ty(cx, impl_item.hir_id), sym!(string_type))
|
|
|
|
{
|
|
|
|
// ...
|
2020-06-09 14:36:01 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
```
|
|
|
|
|
2021-12-06 11:33:31 +00:00
|
|
|
## Dealing with macros and expansions
|
2020-05-28 13:45:24 +00:00
|
|
|
|
2021-12-06 11:33:31 +00:00
|
|
|
Keep in mind that macros are already expanded and desugaring is already applied
|
2022-06-16 15:39:06 +00:00
|
|
|
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 13:45:24 +00:00
|
|
|
|
2022-06-16 15:39:06 +00: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 13:45:24 +00:00
|
|
|
|
2021-12-06 11:33:31 +00:00
|
|
|
```rust
|
|
|
|
if expr.span.from_expansion() {
|
|
|
|
// just forget it
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
```
|
2020-05-28 13:45:24 +00:00
|
|
|
|
2022-06-16 15:39:06 +00: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.
|
|
|
|
|
|
|
|
```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.
|
|
|
|
|
|
|
|
|
|
|
|
- `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.
|
|
|
|
|
|
|
|
You may want to use it for example to not start linting in macros from other
|
|
|
|
crates
|
|
|
|
|
|
|
|
```rust
|
|
|
|
#[macro_use]
|
|
|
|
extern crate a_crate_with_macros;
|
|
|
|
|
|
|
|
// `foo` is defined in `a_crate_with_macros`
|
|
|
|
foo!("bar");
|
|
|
|
|
|
|
|
// if we lint the `match` of `foo` call and test its span
|
|
|
|
assert_eq!(in_external_macro(cx.sess(), match_span), true);
|
|
|
|
```
|
|
|
|
|
|
|
|
- `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 13:45:24 +00:00
|
|
|
|
2021-12-06 11:33:31 +00:00
|
|
|
```rust
|
|
|
|
macro_rules! m {
|
|
|
|
($a:expr, $b:expr) => {
|
|
|
|
if $a.is_some() {
|
|
|
|
$b;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2020-05-28 13:45:24 +00:00
|
|
|
|
2021-12-06 11:33:31 +00:00
|
|
|
let x: Option<u32> = Some(42);
|
|
|
|
m!(x, x.unwrap());
|
2020-05-28 13:45:24 +00:00
|
|
|
|
2021-12-06 11:33:31 +00: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 17:40:06 +00:00
|
|
|
assert_eq!(x_is_some_span.ctxt(), x_unwrap_span.ctxt());
|
2021-12-06 11:33:31 +00:00
|
|
|
```
|
2020-05-28 13:45:24 +00: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-25 03:13:38 +00:00
|
|
|
[Ty]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.Ty.html
|
2020-05-28 13:45:24 +00:00
|
|
|
[TyKind]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.TyKind.html
|
2020-07-17 08:47:04 +00: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 13:45:24 +00: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 08:47:04 +00:00
|
|
|
[pat_ty]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.TypeckResults.html#method.pat_ty
|
2022-07-03 15:35:24 +00:00
|
|
|
[paths]: https://doc.rust-lang.org/nightly/nightly-rustc/clippy_utils/paths/index.html
|