3 You are probably here because you want to add a new lint to Clippy. If this is
4 the first time you're contributing to Clippy, this document guides you through
5 creating an example lint from scratch.
7 To get started, we will create a lint that detects functions called `foo`,
8 because that's clearly a non-descriptive name.
10 - [Adding a new lint](#adding-a-new-lint)
12 - [Getting Started](#getting-started)
13 - [Defining Our Lint](#defining-our-lint)
14 - [Standalone](#standalone)
15 - [Specific Type](#specific-type)
16 - [Tests Location](#tests-location)
18 - [Cargo lints](#cargo-lints)
19 - [Rustfix tests](#rustfix-tests)
20 - [Testing manually](#testing-manually)
21 - [Lint declaration](#lint-declaration)
22 - [Lint registration](#lint-registration)
23 - [Lint passes](#lint-passes)
24 - [Emitting a lint](#emitting-a-lint)
25 - [Adding the lint logic](#adding-the-lint-logic)
26 - [Specifying the lint's minimum supported Rust version (MSRV)](#specifying-the-lints-minimum-supported-rust-version-msrv)
27 - [Author lint](#author-lint)
28 - [Print HIR lint](#print-hir-lint)
29 - [Documentation](#documentation)
30 - [Running rustfmt](#running-rustfmt)
31 - [Debugging](#debugging)
32 - [PR Checklist](#pr-checklist)
33 - [Adding configuration to a lint](#adding-configuration-to-a-lint)
34 - [Cheat Sheet](#cheat-sheet)
38 See the [Basics](basics.md#get-the-code) documentation.
42 There is a bit of boilerplate code that needs to be set up when creating a new
43 lint. Fortunately, you can use the Clippy dev tools to handle this for you. We
44 are naming our new lint `foo_functions` (lints are generally written in snake
45 case), and we don't need type information, so it will have an early pass type
46 (more on this later). If you're unsure if the name you chose fits the lint,
47 take a look at our [lint naming guidelines][lint_naming].
50 To get started, there are two ways to define our lint.
53 Command: `cargo dev new_lint --name=foo_functions --pass=early --category=pedantic`
54 (category will default to nursery if not provided)
56 This command will create a new file: `clippy_lints/src/foo_functions.rs`, as well
57 as [register the lint](#lint-registration).
60 Command: `cargo dev new_lint --name=foo_functions --type=functions --category=pedantic`
62 This command will create a new file: `clippy_lints/src/{type}/foo_functions.rs`.
64 Notice how this command has a `--type` flag instead of `--pass`. Unlike a standalone
65 definition, this lint won't be registered in the traditional sense. Instead, you will
66 call your lint from within the type's lint pass, found in `clippy_lints/src/{type}/mod.rs`.
68 A "type" is just the name of a directory in `clippy_lints/src`, like `functions` in
69 the example command. These are groupings of lints with common behaviors, so if your
70 lint falls into one, it would be best to add it to that type.
73 Both commands will create a file: `tests/ui/foo_functions.rs`. For cargo lints,
74 two project hierarchies (fail/pass) will be created by default under `tests/ui-cargo`.
76 Next, we'll open up these files and add our lint!
80 Let's write some tests first that we can execute while we iterate on our lint.
82 Clippy uses UI tests for testing. UI tests check that the output of Clippy is
83 exactly as expected. Each test is just a plain Rust file that contains the code
84 we want to check. The output of Clippy is compared against a `.stderr` file.
85 Note that you don't have to create this file yourself, we'll get to generating
86 the `.stderr` files further down.
88 We start by opening the test file created at `tests/ui/foo_functions.rs`.
90 Update the file with some examples to get started:
93 #![warn(clippy::foo_functions)]
100 pub fn food(&self) {}
103 // Default trait methods
116 // We also don't want to lint method calls
123 Now we can run the test with `TESTNAME=foo_functions cargo uitest`, currently
124 this test is meaningless though.
126 While we are working on implementing our lint, we can keep running the UI test.
127 That allows us to check if the output is turning into what we want.
129 Once we are satisfied with the output, we need to run `cargo dev bless` to
130 update the `.stderr` file for our lint. Please note that, we should run
131 `TESTNAME=foo_functions cargo uitest` every time before running `cargo dev
132 bless`. Running `TESTNAME=foo_functions cargo uitest` should pass then. When we
133 commit our lint, we need to commit the generated `.stderr` files, too. In
134 general, you should only commit files changed by `cargo dev bless` for the
135 specific lint you are creating/editing. Note that if the generated files are
136 empty, they should be removed.
138 > _Note:_ you can run multiple test files by specifying a comma separated list:
139 > `TESTNAME=foo_functions,test2,test3`.
143 For cargo lints, the process of testing differs in that we are interested in the
144 `Cargo.toml` manifest file. We also need a minimal crate associated with that
147 If our new lint is named e.g. `foo_categories`, after running `cargo dev
148 new_lint` we will find by default two new crates, each with its manifest file:
150 * `tests/ui-cargo/foo_categories/fail/Cargo.toml`: this file should cause the
151 new lint to raise an error.
152 * `tests/ui-cargo/foo_categories/pass/Cargo.toml`: this file should not trigger
155 If you need more cases, you can copy one of those crates (under
156 `foo_categories`) and rename it.
158 The process of generating the `.stderr` file is the same, and prepending the
159 `TESTNAME` variable to `cargo uitest` works too.
163 If the lint you are working on is making use of structured suggestions, the test
164 file should include a `// run-rustfix` comment at the top. This will
165 additionally run [rustfix] for that test. Rustfix will apply the suggestions
166 from the lint to the code of the test file and compare that to the contents of a
169 Use `cargo dev bless` to automatically generate the `.fixed` file after running
172 [rustfix]: https://github.com/rust-lang/rustfix
176 Manually testing against an example file can be useful if you have added some
177 `println!`s and the test suite output becomes unreadable. To try Clippy with
178 your local modifications, run
181 cargo dev lint input.rs
184 from the working copy root. With tests in place, let's have a look at
185 implementing our lint now.
189 Let's start by opening the new file created in the `clippy_lints` crate at
190 `clippy_lints/src/foo_functions.rs`. That's the crate where all the lint code
191 is. This file has already imported some initial things we will need:
194 use rustc_lint::{EarlyLintPass, EarlyContext};
195 use rustc_session::{declare_lint_pass, declare_tool_lint};
196 use rustc_ast::ast::*;
199 The next step is to update the lint declaration. Lints are declared using the
200 [`declare_clippy_lint!`][declare_clippy_lint] macro, and we just need to update
201 the auto-generated lint declaration to have a real description, something like
205 declare_clippy_lint! {
208 /// ### Why is this bad?
214 #[clippy::version = "1.29.0"]
217 "function named `foo`, which is not a descriptive name"
221 * The section of lines prefixed with `///` constitutes the lint documentation
222 section. This is the default documentation style and will be displayed [like
223 this][example_lint_page]. To render and open this documentation locally in a
224 browser, run `cargo dev serve`.
225 * The `#[clippy::version]` attribute will be rendered as part of the lint
226 documentation. The value should be set to the current Rust version that the
227 lint is developed in, it can be retrieved by running `rustc -vV` in the
228 rust-clippy directory. The version is listed under *release*. (Use the version
229 without the `-nightly`) suffix.
230 * `FOO_FUNCTIONS` is the name of our lint. Be sure to follow the [lint naming
231 guidelines][lint_naming] here when naming your lint. In short, the name should
232 state the thing that is being checked for and read well when used with
233 `allow`/`warn`/`deny`.
234 * `pedantic` sets the lint level to `Allow`. The exact mapping can be found
235 [here][category_level_mapping]
236 * The last part should be a text that explains what exactly is wrong with the
239 The rest of this file contains an empty implementation for our lint pass, which
240 in this case is `EarlyLintPass` and should look like this:
243 // clippy_lints/src/foo_functions.rs
245 // .. imports and lint declaration ..
247 declare_lint_pass!(FooFunctions => [FOO_FUNCTIONS]);
249 impl EarlyLintPass for FooFunctions {}
252 [declare_clippy_lint]: https://github.com/rust-lang/rust-clippy/blob/557f6848bd5b7183f55c1e1522a326e9e1df6030/clippy_lints/src/lib.rs#L60
253 [example_lint_page]: https://rust-lang.github.io/rust-clippy/master/index.html#redundant_closure
254 [lint_naming]: https://rust-lang.github.io/rfcs/0344-conventions-galore.html#lints
255 [category_level_mapping]: https://github.com/rust-lang/rust-clippy/blob/557f6848bd5b7183f55c1e1522a326e9e1df6030/clippy_lints/src/lib.rs#L110
259 When using `cargo dev new_lint`, the lint is automatically registered and
260 nothing more has to be done.
262 When declaring a new lint by hand and `cargo dev update_lints` is used, the lint
263 pass may have to be registered manually in the `register_plugins` function in
264 `clippy_lints/src/lib.rs`:
267 store.register_early_pass(|| Box::new(foo_functions::FooFunctions));
270 As one may expect, there is a corresponding `register_late_pass` method
271 available as well. Without a call to one of `register_early_pass` or
272 `register_late_pass`, the lint pass in question will not be run.
274 One reason that `cargo dev update_lints` does not automate this step is that
275 multiple lints can use the same lint pass, so registering the lint pass may
276 already be done when adding a new lint. Another reason that this step is not
277 automated is that the order that the passes are registered determines the order
278 the passes actually run, which in turn affects the order that any emitted lints
283 Writing a lint that only checks for the name of a function means that we only
284 have to deal with the AST and don't have to deal with the type system at all.
285 This is good, because it makes writing this particular lint less complicated.
287 We have to make this decision with every new Clippy lint. It boils down to using
288 either [`EarlyLintPass`][early_lint_pass] or [`LateLintPass`][late_lint_pass].
290 In short, the `LateLintPass` has access to type information while the
291 `EarlyLintPass` doesn't. If you don't need access to type information, use the
292 `EarlyLintPass`. The `EarlyLintPass` is also faster. However linting speed
293 hasn't really been a concern with Clippy so far.
295 Since we don't need type information for checking the function name, we used
296 `--pass=early` when running the new lint automation and all the imports were
299 [early_lint_pass]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/trait.EarlyLintPass.html
300 [late_lint_pass]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/trait.LateLintPass.html
304 With UI tests and the lint declaration in place, we can start working on the
305 implementation of the lint logic.
307 Let's start by implementing the `EarlyLintPass` for our `FooFunctions`:
310 impl EarlyLintPass for FooFunctions {
311 fn check_fn(&mut self, cx: &EarlyContext<'_>, fn_kind: FnKind<'_>, span: Span, _: NodeId) {
312 // TODO: Emit lint here
317 We implement the [`check_fn`][check_fn] method from the
318 [`EarlyLintPass`][early_lint_pass] trait. This gives us access to various
319 information about the function that is currently being checked. More on that in
320 the next section. Let's worry about the details later and emit our lint for
321 *every* function definition first.
323 Depending on how complex we want our lint message to be, we can choose from a
324 variety of lint emission functions. They can all be found in
325 [`clippy_utils/src/diagnostics.rs`][diagnostics].
327 `span_lint_and_help` seems most appropriate in this case. It allows us to
328 provide an extra help message and we can't really suggest a better name
329 automatically. This is how it looks:
332 impl EarlyLintPass for FooFunctions {
333 fn check_fn(&mut self, cx: &EarlyContext<'_>, fn_kind: FnKind<'_>, span: Span, _: NodeId) {
338 "function named `foo`",
340 "consider using a more meaningful name"
346 Running our UI test should now produce output that contains the lint message.
348 According to [the rustc-dev-guide], the text should be matter of fact and avoid
349 capitalization and periods, unless multiple sentences are needed. When code or
350 an identifier must appear in a message or label, it should be surrounded with
351 single grave accents \`.
353 [check_fn]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/trait.EarlyLintPass.html#method.check_fn
354 [diagnostics]: https://github.com/rust-lang/rust-clippy/blob/master/clippy_utils/src/diagnostics.rs
355 [the rustc-dev-guide]: https://rustc-dev-guide.rust-lang.org/diagnostics.html
357 ## Adding the lint logic
359 Writing the logic for your lint will most likely be different from our example,
360 so this section is kept rather short.
362 Using the [`check_fn`][check_fn] method gives us access to [`FnKind`][fn_kind]
363 that has the [`FnKind::Fn`] variant. It provides access to the name of the
364 function/method via an [`Ident`][ident].
366 With that we can expand our `check_fn` method to:
369 impl EarlyLintPass for FooFunctions {
370 fn check_fn(&mut self, cx: &EarlyContext<'_>, fn_kind: FnKind<'_>, span: Span, _: NodeId) {
371 if is_foo_fn(fn_kind) {
376 "function named `foo`",
378 "consider using a more meaningful name"
385 We separate the lint conditional from the lint emissions because it makes the
386 code a bit easier to read. In some cases this separation would also allow to
387 write some unit tests (as opposed to only UI tests) for the separate function.
389 In our example, `is_foo_fn` looks like:
392 // use statements, impl EarlyLintPass, check_fn, ..
394 fn is_foo_fn(fn_kind: FnKind<'_>) -> bool {
396 FnKind::Fn(_, ident, ..) => {
397 // check if `fn` name is `foo`
398 ident.name.as_str() == "foo"
401 FnKind::Closure(..) => false
406 Now we should also run the full test suite with `cargo test`. At this point
407 running `cargo test` should produce the expected output. Remember to run `cargo
408 dev bless` to update the `.stderr` file.
410 `cargo test` (as opposed to `cargo uitest`) will also ensure that our lint
411 implementation is not violating any Clippy lints itself.
413 That should be it for the lint implementation. Running `cargo test` should now
416 [fn_kind]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/visit/enum.FnKind.html
417 [`FnKind::Fn`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/visit/enum.FnKind.html#variant.Fn
418 [ident]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/symbol/struct.Ident.html
420 ## Specifying the lint's minimum supported Rust version (MSRV)
422 Sometimes a lint makes suggestions that require a certain version of Rust. For
423 example, the `manual_strip` lint suggests using `str::strip_prefix` and
424 `str::strip_suffix` which is only available after Rust 1.45. In such cases, you
425 need to ensure that the MSRV configured for the project is >= the MSRV of the
426 required Rust feature. If multiple features are required, just use the one with
429 First, add an MSRV alias for the required feature in [`clippy_utils::msrvs`].
430 This can be accessed later as `msrvs::STR_STRIP_PREFIX`, for example.
435 1,45,0 { STR_STRIP_PREFIX }
439 In order to access the project-configured MSRV, you need to have an `msrv` field
440 in the LintPass struct, and a constructor to initialize the field. The `msrv`
441 value is passed to the constructor in `clippy_lints/lib.rs`.
444 pub struct ManualStrip {
445 msrv: Option<RustcVersion>,
450 pub fn new(msrv: Option<RustcVersion>) -> Self {
456 The project's MSRV can then be matched against the feature MSRV in the LintPass
457 using the `meets_msrv` utility function.
460 if !meets_msrv(self.msrv, msrvs::STR_STRIP_PREFIX) {
465 The project's MSRV can also be specified as an inner attribute, which overrides
466 the value from `clippy.toml`. This can be accounted for using the
467 `extract_msrv_attr!(LintContext)` macro and passing
468 `LateContext`/`EarlyContext`.
471 impl<'tcx> LateLintPass<'tcx> for ManualStrip {
472 fn check_expr(&mut self, cx: &LateContext<'tcx>, expr: &'tcx Expr<'_>) {
475 extract_msrv_attr!(LateContext);
479 Once the `msrv` is added to the lint, a relevant test case should be added to
480 `tests/ui/min_rust_version_attr.rs` which verifies that the lint isn't emitted
481 if the project's MSRV is lower.
483 As a last step, the lint should be added to the lint documentation. This is done
484 in `clippy_lints/src/utils/conf.rs`:
488 /// Lint: LIST, OF, LINTS, <THE_NEWLY_ADDED_LINT>. The minimum rust version that the project supports
489 (msrv: Option<String> = None),
494 [`clippy_utils::msrvs`]: https://doc.rust-lang.org/nightly/nightly-rustc/clippy_utils/msrvs/index.html
498 If you have trouble implementing your lint, there is also the internal `author`
499 lint to generate Clippy code that detects the offending pattern. It does not
500 work for all of the Rust syntax, but can give a good starting point.
502 The quickest way to use it, is the [Rust playground:
503 play.rust-lang.org][author_example]. Put the code you want to lint into the
504 editor and add the `#[clippy::author]` attribute above the item. Then run Clippy
505 via `Tools -> Clippy` and you should see the generated code in the output below.
507 [Here][author_example] is an example on the playground.
509 If the command was executed successfully, you can copy the code over to where
510 you are implementing your lint.
512 [author_example]: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=9a12cb60e5c6ad4e3003ac6d5e63cf55
516 To implement a lint, it's helpful to first understand the internal
517 representation that rustc uses. Clippy has the `#[clippy::dump]` attribute that
518 prints the [_High-Level Intermediate Representation (HIR)_] of the item,
519 statement, or expression that the attribute is attached to. To attach the
520 attribute to expressions you often need to enable
521 `#![feature(stmt_expr_attributes)]`.
523 [Here][print_hir_example] you can find an example, just select _Tools_ and run
526 [_High-Level Intermediate Representation (HIR)_]: https://rustc-dev-guide.rust-lang.org/hir.html
527 [print_hir_example]: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=daf14db3a7f39ca467cd1b86c34b9afb
531 The final thing before submitting our PR is to add some documentation to our
534 Please document your lint with a doc comment akin to the following:
537 declare_clippy_lint! {
539 /// Checks for ... (describe what the lint matches).
541 /// ### Why is this bad?
542 /// Supply the reason for linting the code.
547 /// // A short example of code that triggers the lint
552 /// // A short example of improved code that doesn't trigger the lint
554 #[clippy::version = "1.29.0"]
557 "function named `foo`, which is not a descriptive name"
561 Once your lint is merged, this documentation will show up in the [lint
564 [lint_list]: https://rust-lang.github.io/rust-clippy/master/index.html
568 [Rustfmt] is a tool for formatting Rust code according to style guidelines. Your
569 code has to be formatted by `rustfmt` before a PR can be merged. Clippy uses
570 nightly `rustfmt` in the CI.
572 It can be installed via `rustup`:
575 rustup component add rustfmt --toolchain=nightly
578 Use `cargo dev fmt` to format the whole codebase. Make sure that `rustfmt` is
579 installed for the nightly toolchain.
581 [Rustfmt]: https://github.com/rust-lang/rustfmt
585 If you want to debug parts of your lint implementation, you can use the [`dbg!`]
586 macro anywhere in your code. Running the tests should then include the debug
587 output in the `stdout` part.
589 [`dbg!`]: https://doc.rust-lang.org/std/macro.dbg.html
593 Before submitting your PR make sure you followed all of the basic requirements:
595 <!-- Sync this with `.github/PULL_REQUEST_TEMPLATE` -->
597 - \[ ] Followed [lint naming conventions][lint_naming]
598 - \[ ] Added passing UI tests (including committed `.stderr` file)
599 - \[ ] `cargo test` passes locally
600 - \[ ] Executed `cargo dev update_lints`
601 - \[ ] Added lint documentation
602 - \[ ] Run `cargo dev fmt`
604 ## Adding configuration to a lint
606 Clippy supports the configuration of lints values using a `clippy.toml` file in
607 the workspace directory. Adding a configuration to a lint can be useful for
608 thresholds or to constrain some behavior that can be seen as a false positive
609 for some users. Adding a configuration is done in the following steps:
611 1. Adding a new configuration entry to [`clippy_lints::utils::conf`] like this:
616 /// <The configuration field doc comment>
617 (configuration_ident: Type = DefaultValue),
620 The doc comment is automatically added to the documentation of the listed
621 lints. The default value will be formatted using the `Debug` implementation
623 2. Adding the configuration value to the lint impl struct:
624 1. This first requires the definition of a lint impl struct. Lint impl
625 structs are usually generated with the `declare_lint_pass!` macro. This
626 struct needs to be defined manually to add some kind of metadata to it:
628 // Generated struct definition
629 declare_lint_pass!(StructName => [
633 // New manual definition struct
634 #[derive(Copy, Clone)]
635 pub struct StructName {}
637 impl_lint_pass!(StructName => [
642 2. Next add the configuration value and a corresponding creation method like
645 #[derive(Copy, Clone)]
646 pub struct StructName {
647 configuration_ident: Type,
653 pub fn new(configuration_ident: Type) -> Self {
660 3. Passing the configuration value to the lint impl struct:
662 First find the struct construction in the [`clippy_lints` lib file]. The
663 configuration value is now cloned or copied into a local value that is then
664 passed to the impl struct like this:
667 // Default generated registration:
668 store.register_*_pass(|| box module::StructName);
670 // New registration with configuration value
671 let configuration_ident = conf.configuration_ident.clone();
672 store.register_*_pass(move || box module::StructName::new(configuration_ident));
675 Congratulations the work is almost done. The configuration value can now be
676 accessed in the linting code via `self.configuration_ident`.
679 1. The default configured value can be tested like any normal lint in
681 2. The configuration itself will be tested separately in [`tests/ui-toml`].
682 Simply add a new subfolder with a fitting name. This folder contains a
683 `clippy.toml` file with the configuration value and a rust file that
684 should be linted by Clippy. The test can otherwise be written as usual.
686 [`clippy_lints::utils::conf`]: https://github.com/rust-lang/rust-clippy/blob/master/clippy_lints/src/utils/conf.rs
687 [`clippy_lints` lib file]: https://github.com/rust-lang/rust-clippy/blob/master/clippy_lints/src/lib.rs
688 [`tests/ui`]: https://github.com/rust-lang/rust-clippy/blob/master/tests/ui
689 [`tests/ui-toml`]: https://github.com/rust-lang/rust-clippy/blob/master/tests/ui-toml
693 Here are some pointers to things you are likely going to need for every lint:
695 * [Clippy utils][utils] - Various helper functions. Maybe the function you need
696 is already in here ([`is_type_diagnostic_item`], [`implements_trait`],
698 * [Clippy diagnostics][diagnostics]
699 * [Let chains][let-chains]
700 * [`from_expansion`][from_expansion] and
701 [`in_external_macro`][in_external_macro]
703 * [`Applicability`][applicability]
704 * [Common tools for writing lints](common_tools_writing_lints.md) helps with
706 * [The rustc-dev-guide][rustc-dev-guide] explains a lot of internal compiler
708 * [The nightly rustc docs][nightly_docs] which has been linked to throughout
711 For `EarlyLintPass` lints:
713 * [`EarlyLintPass`][early_lint_pass]
714 * [`rustc_ast::ast`][ast]
716 For `LateLintPass` lints:
718 * [`LateLintPass`][late_lint_pass]
721 While most of Clippy's lint utils are documented, most of rustc's internals lack
722 documentation currently. This is unfortunate, but in most cases you can probably
723 get away with copying things from existing similar lints. If you are stuck,
724 don't hesitate to ask on [Zulip] or in the issue/PR.
726 [utils]: https://doc.rust-lang.org/nightly/nightly-rustc/clippy_utils/index.html
727 [`is_type_diagnostic_item`]: https://doc.rust-lang.org/nightly/nightly-rustc/clippy_utils/ty/fn.is_type_diagnostic_item.html
728 [`implements_trait`]: https://doc.rust-lang.org/nightly/nightly-rustc/clippy_utils/ty/fn.implements_trait.html
729 [`snippet`]: https://doc.rust-lang.org/nightly/nightly-rustc/clippy_utils/source/fn.snippet.html
730 [let-chains]: https://github.com/rust-lang/rust/pull/94927
731 [from_expansion]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/struct.Span.html#method.from_expansion
732 [in_external_macro]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/lint/fn.in_external_macro.html
733 [span]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/struct.Span.html
734 [applicability]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/enum.Applicability.html
735 [rustc-dev-guide]: https://rustc-dev-guide.rust-lang.org/
736 [nightly_docs]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/
737 [ast]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ast/index.html
738 [ty]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/sty/index.html
739 [Zulip]: https://rust-lang.zulipchat.com/#narrow/stream/clippy