Skip to content

Commit eb5ce85

Browse files
committed
mention span_lint_hir in span_lint and add a reason to disallowed_methods
1 parent fa4e3aa commit eb5ce85

File tree

3 files changed

+77
-20
lines changed

3 files changed

+77
-20
lines changed

clippy.toml

+8-5
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,10 @@
11
avoid-breaking-exported-api = false
22

3-
# use the various `clippy_utils::diagnostics::span_lint_*` functions instead, which also add a link to the docs
4-
disallowed-methods = [
5-
"rustc_lint::context::LintContext::span_lint",
6-
"rustc_middle::ty::context::TyCtxt::node_span_lint",
7-
]
3+
[[disallowed-methods]]
4+
path = "rustc_lint::context::LintContext::span_lint"
5+
reason = "this function does not add a link to our documentation, please use the `clippy_utils::diagnostics::span_lint*` functions instead"
6+
7+
8+
[[disallowed-methods]]
9+
path = "rustc_middle::ty::context::TyCtxt::node_span_lint"
10+
reason = "this function does not add a link to our documentation, please use the `clippy_utils::diagnostics::span_lint_hir*` functions instead"

clippy_utils/src/diagnostics.rs

+66-15
Original file line numberDiff line numberDiff line change
@@ -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.
142178
pub fn span_lint_and_then<C, S, F>(cx: &C, lint: &'static Lint, sp: S, msg: &str, f: F)
143179
where
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.
174213
pub 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.
200242
pub 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

tests/ui-internal/disallow_span_lint.stderr

+3
Original file line numberDiff line numberDiff line change
@@ -4,6 +4,7 @@ error: use of a disallowed method `rustc_lint::context::LintContext::span_lint`
44
LL | cx.span_lint(lint, span, msg, |_| {});
55
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
66
|
7+
= note: this function does not add a link to our documentation, please use the `clippy_utils::diagnostics::span_lint*` functions instead (from clippy.toml)
78
= note: `-D clippy::disallowed-methods` implied by `-D warnings`
89
= help: to override `-D warnings` add `#[allow(clippy::disallowed_methods)]`
910

@@ -12,6 +13,8 @@ error: use of a disallowed method `rustc_middle::ty::context::TyCtxt::node_span_
1213
|
1314
LL | tcx.node_span_lint(lint, hir_id, span, msg, |_| {});
1415
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
16+
|
17+
= note: this function does not add a link to our documentation, please use the `clippy_utils::diagnostics::span_lint_hir*` functions instead (from clippy.toml)
1518

1619
error: aborting due to 2 previous errors
1720

0 commit comments

Comments
 (0)