@@ -36,6 +36,15 @@ fn docs_link(diag: &mut Diag<'_, ()>, lint: &'static Lint) {
36
36
/// Usually it's nicer to provide more context for lint messages.
37
37
/// Be sure the output is understandable when you use this method.
38
38
///
39
+ /// NOTE: only lint-level attributes at the `LintPass::check_*` node from which you are calling this
40
+ /// will be considered.
41
+ /// This can be confusing if the given span is at a different place, because users won't know where
42
+ /// `#[allow]` or `#[expect]` attributes need to be placed.
43
+ ///
44
+ /// This can happen if, for example, you are in `LintPass::check_block` and you are emitting a lint
45
+ /// for a particular expression within that block.
46
+ /// In those cases, consider using [`span_lint_hir`], and pass the `HirId` of that expression.
47
+ ///
39
48
/// # Example
40
49
///
41
50
/// ```ignore
@@ -61,6 +70,15 @@ pub fn span_lint<T: LintContext>(cx: &T, lint: &'static Lint, sp: impl Into<Mult
61
70
///
62
71
/// If you change the signature, remember to update the internal lint `CollapsibleCalls`
63
72
///
73
+ /// NOTE: only lint-level attributes at the `LintPass::check_*` node from which you are calling this
74
+ /// will be considered.
75
+ /// This can be confusing if the given span is at a different place, because users won't know where
76
+ /// `#[allow]` or `#[expect]` attributes need to be placed.
77
+ ///
78
+ /// This can happen if, for example, you are in `LintPass::check_block` and you are emitting a lint
79
+ /// for a particular expression within that block.
80
+ /// In those cases, consider using [`span_lint_hir`], and pass the `HirId` of that expression.
81
+ ///
64
82
/// # Example
65
83
///
66
84
/// ```text
@@ -99,6 +117,15 @@ pub fn span_lint_and_help<T: LintContext>(
99
117
///
100
118
/// If you change the signature, remember to update the internal lint `CollapsibleCalls`
101
119
///
120
+ /// NOTE: only lint-level attributes at the `LintPass::check_*` node from which you are calling this
121
+ /// will be considered.
122
+ /// This can be confusing if the given span is at a different place, because users won't know where
123
+ /// `#[allow]` or `#[expect]` attributes need to be placed.
124
+ ///
125
+ /// This can happen if, for example, you are in `LintPass::check_block` and you are emitting a lint
126
+ /// for a particular expression within that block.
127
+ /// In those cases, consider using [`span_lint_hir`], and pass the `HirId` of that expression.
128
+ ///
102
129
/// # Example
103
130
///
104
131
/// ```text
@@ -139,6 +166,15 @@ pub fn span_lint_and_note<T: LintContext>(
139
166
///
140
167
/// If you need to customize your lint output a lot, use this function.
141
168
/// If you change the signature, remember to update the internal lint `CollapsibleCalls`
169
+ ///
170
+ /// NOTE: only lint-level attributes at the `LintPass::check_*` node from which you are calling this
171
+ /// will be considered.
172
+ /// This can be confusing if the given span is at a different place, because users won't know where
173
+ /// `#[allow]` or `#[expect]` attributes need to be placed.
174
+ ///
175
+ /// This can happen if, for example, you are in `LintPass::check_block` and you are emitting a lint
176
+ /// for a particular expression within that block.
177
+ /// In those cases, consider using [`span_lint_hir`], and pass the `HirId` of that expression.
142
178
pub fn span_lint_and_then < C , S , F > ( cx : & C , lint : & ' static Lint , sp : S , msg : & str , f : F )
143
179
where
144
180
C : LintContext ,
@@ -155,22 +191,25 @@ where
155
191
/// Like [`span_lint`], but allows providing the `HirId` of the node that caused us to emit this
156
192
/// lint.
157
193
///
158
- /// The `HirId` is used for checking lint level attributes.
194
+ /// The `HirId` is used for checking lint level attributes and to fulfill lint expectations defined
195
+ /// via the `#[expect]` attribute.
159
196
///
160
197
/// For example:
161
198
/// ```ignore
162
- /// fn f() { /* '1 */
199
+ /// fn f() { /* <node_1> */
163
200
///
164
201
/// #[allow(clippy::some_lint)]
165
- /// let _x = /* '2 */;
202
+ /// let _x = /* <expr_1> */;
166
203
/// }
167
204
/// ```
168
- /// If `some_lint` does its analysis in `LintPass::check_fn` (at `'1`) and emits a lint at `'2`
169
- /// using [`span_lint`], then allowing the lint at `'2` as attempted in the snippet will not work!
205
+ /// If `some_lint` does its analysis in `LintPass::check_fn` (at `<node_1>`) and emits a lint at
206
+ /// `<expr_1>` using [`span_lint`], then allowing the lint at `<expr_1>` as attempted in the snippet
207
+ /// will not work!
170
208
/// Even though that is where the warning points at, which would be confusing to users.
171
209
///
172
- /// Instead, use this function and also pass the `HirId` of the node at `'2`, which will let the
173
- /// compiler check lint level attributes at `'2` as one would expect, and the `#[allow]` will work.
210
+ /// Instead, use this function and also pass the `HirId` of `<expr_1>`, which will let
211
+ /// the compiler check lint level attributes at the place of the expression and
212
+ /// the `#[allow]` will work.
174
213
pub fn span_lint_hir ( cx : & LateContext < ' _ > , lint : & ' static Lint , hir_id : HirId , sp : Span , msg : & str ) {
175
214
#[ expect( clippy:: disallowed_methods) ]
176
215
cx. tcx . node_span_lint ( lint, hir_id, sp, msg. to_string ( ) , |diag| {
@@ -181,22 +220,25 @@ pub fn span_lint_hir(cx: &LateContext<'_>, lint: &'static Lint, hir_id: HirId, s
181
220
/// Like [`span_lint_and_then`], but allows providing the `HirId` of the node that caused us to emit
182
221
/// this lint.
183
222
///
184
- /// The `HirId` is used for checking lint level attributes.
223
+ /// The `HirId` is used for checking lint level attributes and to fulfill lint expectations defined
224
+ /// via the `#[expect]` attribute.
185
225
///
186
226
/// For example:
187
227
/// ```ignore
188
- /// fn f() { /* '1 */
228
+ /// fn f() { /* <node_1> */
189
229
///
190
230
/// #[allow(clippy::some_lint)]
191
- /// let _x = /* '2 */;
231
+ /// let _x = /* <expr_1> */;
192
232
/// }
193
233
/// ```
194
- /// If `some_lint` does its analysis in `LintPass::check_fn` (at `'1`) and emits a lint at `'2`
195
- /// using [`span_lint_and_then`], then allowing the lint at `'2` as attempted in the snippet will
196
- /// not work! Even though that is where the warning points at, which would be confusing to users.
234
+ /// If `some_lint` does its analysis in `LintPass::check_fn` (at `<node_1>`) and emits a lint at
235
+ /// `<expr_1>` using [`span_lint`], then allowing the lint at `<expr_1>` as attempted in the snippet
236
+ /// will not work!
237
+ /// Even though that is where the warning points at, which would be confusing to users.
197
238
///
198
- /// Instead, use this function and also pass the `HirId` of the node at `'2`, which will let the
199
- /// compiler check lint level attributes at `'2` as one would expect, and the `#[allow]` will work.
239
+ /// Instead, use this function and also pass the `HirId` of `<expr_1>`, which will let
240
+ /// the compiler check lint level attributes at the place of the expression and
241
+ /// the `#[allow]` will work.
200
242
pub fn span_lint_hir_and_then (
201
243
cx : & LateContext < ' _ > ,
202
244
lint : & ' static Lint ,
@@ -220,6 +262,15 @@ pub fn span_lint_hir_and_then(
220
262
///
221
263
/// If you change the signature, remember to update the internal lint `CollapsibleCalls`
222
264
///
265
+ /// NOTE: only lint-level attributes at the `LintPass::check_*` node from which you are calling this
266
+ /// will be considered.
267
+ /// This can be confusing if the given span is at a different place, because users won't know where
268
+ /// `#[allow]` or `#[expect]` attributes need to be placed.
269
+ ///
270
+ /// This can happen if, for example, you are in `LintPass::check_block` and you are emitting a lint
271
+ /// for a particular expression within that block.
272
+ /// In those cases, consider using [`span_lint_hir`], and pass the `HirId` of that expression.
273
+ ///
223
274
/// # Example
224
275
///
225
276
/// ```text
0 commit comments