@@ -36,6 +36,15 @@ fn docs_link(diag: &mut Diag<'_, ()>, lint: &'static Lint) {
3636/// Usually it's nicer to provide more context for lint messages.
3737/// Be sure the output is understandable when you use this method.
3838///
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+ ///
3948/// # Example
4049///
4150/// ```ignore
@@ -61,6 +70,15 @@ pub fn span_lint<T: LintContext>(cx: &T, lint: &'static Lint, sp: impl Into<Mult
6170///
6271/// If you change the signature, remember to update the internal lint `CollapsibleCalls`
6372///
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+ ///
6482/// # Example
6583///
6684/// ```text
@@ -99,6 +117,15 @@ pub fn span_lint_and_help<T: LintContext>(
99117///
100118/// If you change the signature, remember to update the internal lint `CollapsibleCalls`
101119///
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+ ///
102129/// # Example
103130///
104131/// ```text
@@ -139,6 +166,15 @@ pub fn span_lint_and_note<T: LintContext>(
139166///
140167/// If you need to customize your lint output a lot, use this function.
141168/// 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.
142178pub fn span_lint_and_then < C , S , F > ( cx : & C , lint : & ' static Lint , sp : S , msg : & str , f : F )
143179where
144180 C : LintContext ,
@@ -155,22 +191,25 @@ where
155191/// Like [`span_lint`], but allows providing the `HirId` of the node that caused us to emit this
156192/// lint.
157193///
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.
159196///
160197/// For example:
161198/// ```ignore
162- /// fn f() { /* '1 */
199+ /// fn f() { /* <node_1> */
163200///
164201/// #[allow(clippy::some_lint)]
165- /// let _x = /* '2 */;
202+ /// let _x = /* <expr_1> */;
166203/// }
167204/// ```
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!
170208/// Even though that is where the warning points at, which would be confusing to users.
171209///
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.
174213pub fn span_lint_hir ( cx : & LateContext < ' _ > , lint : & ' static Lint , hir_id : HirId , sp : Span , msg : & str ) {
175214 #[ expect( clippy:: disallowed_methods) ]
176215 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
181220/// Like [`span_lint_and_then`], but allows providing the `HirId` of the node that caused us to emit
182221/// this lint.
183222///
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.
185225///
186226/// For example:
187227/// ```ignore
188- /// fn f() { /* '1 */
228+ /// fn f() { /* <node_1> */
189229///
190230/// #[allow(clippy::some_lint)]
191- /// let _x = /* '2 */;
231+ /// let _x = /* <expr_1> */;
192232/// }
193233/// ```
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.
197238///
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.
200242pub fn span_lint_hir_and_then (
201243 cx : & LateContext < ' _ > ,
202244 lint : & ' static Lint ,
@@ -220,6 +262,15 @@ pub fn span_lint_hir_and_then(
220262///
221263/// If you change the signature, remember to update the internal lint `CollapsibleCalls`
222264///
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+ ///
223274/// # Example
224275///
225276/// ```text
0 commit comments