]> git.lizzy.rs Git - rust.git/blob - clippy_lints/src/functions/mod.rs
Auto merge of #8937 - Jarcho:merge_match_passes, r=llogiq
[rust.git] / clippy_lints / src / functions / mod.rs
1 mod must_use;
2 mod not_unsafe_ptr_arg_deref;
3 mod result_unit_err;
4 mod too_many_arguments;
5 mod too_many_lines;
6
7 use rustc_hir as hir;
8 use rustc_hir::intravisit;
9 use rustc_lint::{LateContext, LateLintPass};
10 use rustc_session::{declare_tool_lint, impl_lint_pass};
11 use rustc_span::Span;
12
13 declare_clippy_lint! {
14     /// ### What it does
15     /// Checks for functions with too many parameters.
16     ///
17     /// ### Why is this bad?
18     /// Functions with lots of parameters are considered bad
19     /// style and reduce readability (“what does the 5th parameter mean?”). Consider
20     /// grouping some parameters into a new type.
21     ///
22     /// ### Example
23     /// ```rust
24     /// # struct Color;
25     /// fn foo(x: u32, y: u32, name: &str, c: Color, w: f32, h: f32, a: f32, b: f32) {
26     ///     // ..
27     /// }
28     /// ```
29     #[clippy::version = "pre 1.29.0"]
30     pub TOO_MANY_ARGUMENTS,
31     complexity,
32     "functions with too many arguments"
33 }
34
35 declare_clippy_lint! {
36     /// ### What it does
37     /// Checks for functions with a large amount of lines.
38     ///
39     /// ### Why is this bad?
40     /// Functions with a lot of lines are harder to understand
41     /// due to having to look at a larger amount of code to understand what the
42     /// function is doing. Consider splitting the body of the function into
43     /// multiple functions.
44     ///
45     /// ### Example
46     /// ```rust
47     /// fn im_too_long() {
48     ///     println!("");
49     ///     // ... 100 more LoC
50     ///     println!("");
51     /// }
52     /// ```
53     #[clippy::version = "1.34.0"]
54     pub TOO_MANY_LINES,
55     pedantic,
56     "functions with too many lines"
57 }
58
59 declare_clippy_lint! {
60     /// ### What it does
61     /// Checks for public functions that dereference raw pointer
62     /// arguments but are not marked `unsafe`.
63     ///
64     /// ### Why is this bad?
65     /// The function should probably be marked `unsafe`, since
66     /// for an arbitrary raw pointer, there is no way of telling for sure if it is
67     /// valid.
68     ///
69     /// ### Known problems
70     /// * It does not check functions recursively so if the pointer is passed to a
71     /// private non-`unsafe` function which does the dereferencing, the lint won't
72     /// trigger.
73     /// * It only checks for arguments whose type are raw pointers, not raw pointers
74     /// got from an argument in some other way (`fn foo(bar: &[*const u8])` or
75     /// `some_argument.get_raw_ptr()`).
76     ///
77     /// ### Example
78     /// ```rust,ignore
79     /// // Bad
80     /// pub fn foo(x: *const u8) {
81     ///     println!("{}", unsafe { *x });
82     /// }
83     ///
84     /// // Good
85     /// pub unsafe fn foo(x: *const u8) {
86     ///     println!("{}", unsafe { *x });
87     /// }
88     /// ```
89     #[clippy::version = "pre 1.29.0"]
90     pub NOT_UNSAFE_PTR_ARG_DEREF,
91     correctness,
92     "public functions dereferencing raw pointer arguments but not marked `unsafe`"
93 }
94
95 declare_clippy_lint! {
96     /// ### What it does
97     /// Checks for a `#[must_use]` attribute on
98     /// unit-returning functions and methods.
99     ///
100     /// ### Why is this bad?
101     /// Unit values are useless. The attribute is likely
102     /// a remnant of a refactoring that removed the return type.
103     ///
104     /// ### Examples
105     /// ```rust
106     /// #[must_use]
107     /// fn useless() { }
108     /// ```
109     #[clippy::version = "1.40.0"]
110     pub MUST_USE_UNIT,
111     style,
112     "`#[must_use]` attribute on a unit-returning function / method"
113 }
114
115 declare_clippy_lint! {
116     /// ### What it does
117     /// Checks for a `#[must_use]` attribute without
118     /// further information on functions and methods that return a type already
119     /// marked as `#[must_use]`.
120     ///
121     /// ### Why is this bad?
122     /// The attribute isn't needed. Not using the result
123     /// will already be reported. Alternatively, one can add some text to the
124     /// attribute to improve the lint message.
125     ///
126     /// ### Examples
127     /// ```rust
128     /// #[must_use]
129     /// fn double_must_use() -> Result<(), ()> {
130     ///     unimplemented!();
131     /// }
132     /// ```
133     #[clippy::version = "1.40.0"]
134     pub DOUBLE_MUST_USE,
135     style,
136     "`#[must_use]` attribute on a `#[must_use]`-returning function / method"
137 }
138
139 declare_clippy_lint! {
140     /// ### What it does
141     /// Checks for public functions that have no
142     /// `#[must_use]` attribute, but return something not already marked
143     /// must-use, have no mutable arg and mutate no statics.
144     ///
145     /// ### Why is this bad?
146     /// Not bad at all, this lint just shows places where
147     /// you could add the attribute.
148     ///
149     /// ### Known problems
150     /// The lint only checks the arguments for mutable
151     /// types without looking if they are actually changed. On the other hand,
152     /// it also ignores a broad range of potentially interesting side effects,
153     /// because we cannot decide whether the programmer intends the function to
154     /// be called for the side effect or the result. Expect many false
155     /// positives. At least we don't lint if the result type is unit or already
156     /// `#[must_use]`.
157     ///
158     /// ### Examples
159     /// ```rust
160     /// // this could be annotated with `#[must_use]`.
161     /// fn id<T>(t: T) -> T { t }
162     /// ```
163     #[clippy::version = "1.40.0"]
164     pub MUST_USE_CANDIDATE,
165     pedantic,
166     "function or method that could take a `#[must_use]` attribute"
167 }
168
169 declare_clippy_lint! {
170     /// ### What it does
171     /// Checks for public functions that return a `Result`
172     /// with an `Err` type of `()`. It suggests using a custom type that
173     /// implements `std::error::Error`.
174     ///
175     /// ### Why is this bad?
176     /// Unit does not implement `Error` and carries no
177     /// further information about what went wrong.
178     ///
179     /// ### Known problems
180     /// Of course, this lint assumes that `Result` is used
181     /// for a fallible operation (which is after all the intended use). However
182     /// code may opt to (mis)use it as a basic two-variant-enum. In that case,
183     /// the suggestion is misguided, and the code should use a custom enum
184     /// instead.
185     ///
186     /// ### Examples
187     /// ```rust
188     /// pub fn read_u8() -> Result<u8, ()> { Err(()) }
189     /// ```
190     /// should become
191     /// ```rust,should_panic
192     /// use std::fmt;
193     ///
194     /// #[derive(Debug)]
195     /// pub struct EndOfStream;
196     ///
197     /// impl fmt::Display for EndOfStream {
198     ///     fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
199     ///         write!(f, "End of Stream")
200     ///     }
201     /// }
202     ///
203     /// impl std::error::Error for EndOfStream { }
204     ///
205     /// pub fn read_u8() -> Result<u8, EndOfStream> { Err(EndOfStream) }
206     ///# fn main() {
207     ///#     read_u8().unwrap();
208     ///# }
209     /// ```
210     ///
211     /// Note that there are crates that simplify creating the error type, e.g.
212     /// [`thiserror`](https://docs.rs/thiserror).
213     #[clippy::version = "1.49.0"]
214     pub RESULT_UNIT_ERR,
215     style,
216     "public function returning `Result` with an `Err` type of `()`"
217 }
218
219 #[derive(Copy, Clone)]
220 pub struct Functions {
221     too_many_arguments_threshold: u64,
222     too_many_lines_threshold: u64,
223 }
224
225 impl Functions {
226     pub fn new(too_many_arguments_threshold: u64, too_many_lines_threshold: u64) -> Self {
227         Self {
228             too_many_arguments_threshold,
229             too_many_lines_threshold,
230         }
231     }
232 }
233
234 impl_lint_pass!(Functions => [
235     TOO_MANY_ARGUMENTS,
236     TOO_MANY_LINES,
237     NOT_UNSAFE_PTR_ARG_DEREF,
238     MUST_USE_UNIT,
239     DOUBLE_MUST_USE,
240     MUST_USE_CANDIDATE,
241     RESULT_UNIT_ERR,
242 ]);
243
244 impl<'tcx> LateLintPass<'tcx> for Functions {
245     fn check_fn(
246         &mut self,
247         cx: &LateContext<'tcx>,
248         kind: intravisit::FnKind<'tcx>,
249         decl: &'tcx hir::FnDecl<'_>,
250         body: &'tcx hir::Body<'_>,
251         span: Span,
252         hir_id: hir::HirId,
253     ) {
254         too_many_arguments::check_fn(cx, kind, decl, span, hir_id, self.too_many_arguments_threshold);
255         too_many_lines::check_fn(cx, kind, span, body, self.too_many_lines_threshold);
256         not_unsafe_ptr_arg_deref::check_fn(cx, kind, decl, body, hir_id);
257     }
258
259     fn check_item(&mut self, cx: &LateContext<'tcx>, item: &'tcx hir::Item<'_>) {
260         must_use::check_item(cx, item);
261         result_unit_err::check_item(cx, item);
262     }
263
264     fn check_impl_item(&mut self, cx: &LateContext<'tcx>, item: &'tcx hir::ImplItem<'_>) {
265         must_use::check_impl_item(cx, item);
266         result_unit_err::check_impl_item(cx, item);
267     }
268
269     fn check_trait_item(&mut self, cx: &LateContext<'tcx>, item: &'tcx hir::TraitItem<'_>) {
270         too_many_arguments::check_trait_item(cx, item, self.too_many_arguments_threshold);
271         not_unsafe_ptr_arg_deref::check_trait_item(cx, item);
272         must_use::check_trait_item(cx, item);
273         result_unit_err::check_trait_item(cx, item);
274     }
275 }