Validate paths in `disallowed_*` configurations #14397

smoelius · 2025-03-12T16:48:27Z

This PR resolves #11432 by checking that paths resolve in disallowed_* configurations.

It also does some lightweight validation of definition kinds. For example, only paths that resolve to DefKind::Macro definitions are allowed in disallowed_macro configurations.

~~The PR is currently two commits. The first is #14376 (cc: @Jarcho), which I submitted just a few days ago. The second commit is everything else.~~

Side note: For me, the most difficult part of this PR was getting the spans of the individual DisallowedPath configurations. There is some discussion at toml-rs/toml#840, if interested.

changelog: validate paths in disallowed_* configurations

rustbot · 2025-03-12T16:48:32Z

r? @Manishearth

rustbot has assigned @Manishearth.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Manishearth · 2025-03-12T17:26:28Z

r? clippy

rather busy today, may not get to this soon

smoelius · 2025-03-31T12:15:01Z

Rebased and updated the description now that #14376 has been merged.

flip1995 · 2025-03-31T17:32:40Z

r? @samueltardieu

samueltardieu

This was very interesting to review. I have a few remarks and nits.

Also, could you remove the + use<'_, REPLACEMENT_ALLOWED> in types.rs:77 while you're editing the file? It should not be needed at all with Rust 2024 RPIT capture rules, both self's lifetime and REPLACEMENT_ALLOWED should be captured by default.

samueltardieu · 2025-03-31T21:42:42Z

clippy_config/src/types.rs

+                    .dcx()
+                    .span_warn(span, format!("primitive types are not allowed: {path}"));
+            } else if !disallowed_path.allow_invalid {
+                tcx.sess.dcx().span_warn(span, format!("`{path}` is invalid"));


"is invalid" seems vague. Should it be something along the line of "does not designate an existing item"?

I changed "is invalid" to "may not refer to an existing definition" everywhere.

I went with "may not" instead of "does not" because the existence depends on the compiler used. For example, the rustc_private paths in Clippy's clippy.toml will exist only if a nightly compiler is used.

I went with "definitions" instead of "items" mainly because it sounds more natural to me. But also this list from the Rust Reference suggests "definitions" is more specific than "items", and I think it applies to all of our cases.

I'm not wed to either and I'll change them if you feel strongly.

I like the change in the message shown to the user. However, in the configuration file, I find it quite lengthy. Maybe there allow-invalid would be fine, as long as the config option doc explains what it does. WDYT?

Sounds good to me.

samueltardieu · 2025-03-31T22:18:36Z

clippy_config/src/types.rs

+        FxHashMap::default();
+    for disallowed_path in disallowed_paths {
+        let path = disallowed_path.path();
+        let mut reses = clippy_utils::def_path_res(tcx, &path.split("::").collect::<Vec<_>>());


resolutions might be an easier name to read and understand.

samueltardieu · 2025-03-31T22:22:05Z

clippy_lints/src/disallowed_methods.rs

-            {
-                (id, expr.span)
-            },
+            // Previous versions of this lint checked the `DefKind` in the next arm. However, that is no longer


Nit: I don't think it is appropriate to talk about "previous versions" in comments. Explanations of change should be in the commit message, while explanation about the current code (if needed) should be in comments.

samueltardieu · 2025-03-31T22:47:02Z

clippy_config/src/types.rs

+            if found_def_id {
+                tcx.sess
+                    .dcx()
+                    .span_warn(span, format!("`{path}` is not of an appropriate kind"));


You can give a better message by, for example:

giving this function an extra &str parameter predicate_description (here: "a type")

storing an Option<DefId> in found_def_id instead of a bool

using tcx.def_descr_article() and tcx.def_descr()
to generate a warning message such as:

warning: `std::result::Result::Err`: expected a type, found a tuple variant --> /home/sam/Dev/rust-clippy/tests/ui-toml/toml_invalid_path/clippy.toml:1:1 | LL | / [[disallowed-types]] LL | | path = "std::result::Result::Err" | |_________________________________^

samueltardieu · 2025-03-31T22:49:30Z

clippy_config/src/conf.rs

@@ -517,9 +572,11 @@ define_Conf! {
    #[conf_deprecated("Please use `cognitive-complexity-threshold` instead", cognitive_complexity_threshold)]
    cyclomatic_complexity_threshold: u64 = 25,
    /// The list of disallowed macros, written as fully qualified paths.
+    #[disallowed_path_replacements_allowed = true]


This is really hard to parse. I had to think twice to distinguish between disallowed(path_replacements_allowed) and disallowed_path_replacements: allowed.

What about something like allow_path_replacements_suggestions?

Your point is very well taken. But, for context, disallowed_path_replacements_allowed is the concatenation of DisallowedPath and the REPLACEMENTS_ALLOWED const parameter, made lower-snake-case.

That attribute is meant to serve as both a declaration (i.e., "disallowed paths are used in this configuration") and the setting of the REPLACEMENTS_ALLOWED parameter.

I'm struggling with allow_path_replacements_suggestions because, to me, it does not sound like a declaration.

I changed all of the attributes to disallowed_path_allow_replacements. Is that better?

samueltardieu · 2025-03-31T23:03:47Z

clippy_config/src/conf.rs

+        (value, value_span)
+    }};
+
+    ($map:expr, $ty:ty, $errors:expr, $file:expr, $replacements_allowed:expr) => {{


I would have found it clearer if you add started the pattern with something like (disallowed_paths => …), to clearly show that this is something used by this lint family, instead of relying on matching the extra argument.

I'm trying to apply a "trick" that I learned from the default_text macro defined in the same file.

Specifically, on this line, the replacements_allowed argument is included only if the disallowed_path_replacements_allowed attribute was used:

deserialize!(map, $ty, errors, self.0 $(, $replacements_allowed)?);

In this way, the presence/absence of that argument selects between the two arms in the deserialize! macro.

Your suggestion is to use a keyword to choose between the two arms, correct?

I take your point that the present code is subtle and non-obvious. But, to be honest, I cannot immediately see how to make the keyword approach work. Could you offer me some more guidance? Or is there a way to make the present code more clear?

(Sorry if the "trick" explanation was unnecessary.)

Yes, I've noticed that (that was my "instead of relying on matching the extra argument" point). The idea with the keyword would be to make it clearer that this specific branch will be used by the disallowed_* lints.

But since you get the replacements_allowed from the defineConf macro, it is right that it would be more complicated to use such a keyword. You can forget about the suggestion.

samueltardieu · 2025-04-01T00:03:37Z

@rustbot author

samueltardieu · 2025-04-01T16:22:25Z

Btw @smoelius, you'll need to rebase on master after #14514 has been merged, so that lintcheck can run.

samueltardieu

Thanks for your quick reaction to the feedback. This looks good to me, and a real improvement.

Could you please squash the commits into one? I'll then merge it.

samueltardieu · 2025-04-01T18:42:55Z

Just a nitpick: it looks like you kept "Addressed review comments", as well as the parameter change in the commit message when squashing. Can you just edit it to its purpose, i.e. "Validate path in …"?

smoelius · 2025-04-01T19:11:29Z

Thanks!

…onfiguration Starting with Rust 1.88.0 (expected 2025-06-26) [1], Clippy may start warning about paths that do not resolve in the `disallowed_macros` configuration: warning: `kernel::dbg` does not refer to an existing macro --> .clippy.toml:10:5 | 10 | { path = "kernel::dbg", reason = "the `dbg!` macro is intended as a debugging tool" }, | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This is a lint we requested at [2], due to the trouble debugging the lint due to false negatives (e.g. [3]), which we use to emulate `clippy::dbg_macro` [4]. See commit 8577c9d ("rust: replace `clippy::dbg_macro` with `disallowed_macros`") for more details. Given the false negatives are not resolved yet, it is expected that Clippy complains about not finding this macro. Thus, until the false negatives are fixed (and, even then, probably we will need to wait for the MSRV to raise enough), use the escape hatch to allow an invalid path. Cc: [email protected] # Needed in 6.12.y and later (Rust is pinned in older LTSs). Link: rust-lang/rust-clippy#14397 [1] Link: rust-lang/rust-clippy#11432 [2] Link: rust-lang/rust-clippy#11431 [3] Link: rust-lang/rust-clippy#11303 [4] Signed-off-by: Miguel Ojeda <[email protected]>

RGBCube · 2025-05-03T00:50:49Z

This seems to have false-positives if I'm using the lint correctly, I'm on clippy 0.1.88 (3350c1eb3f 2025-05-01).

smoelius · 2025-05-03T01:16:07Z

@RGBCube Can you share the code used to produce that screenshot?

RGBCube · 2025-05-03T02:07:31Z

@RGBCube Can you share the code used to produce that screenshot?

It's at https://github.com/cull-os/carcass/blob/d3db2eb953acbbce7fb1420c92f2103be5a7d7ff/cab/cab-format/src/width.rs#L39, trying to get a MRE right now.

RGBCube · 2025-05-03T02:30:38Z

Found the problem, it checks against crate dependencies, instead of scanning the workspace lock. This happens when you:

Have package foo in a workspace which depends on unicode_width
Have package bar in the same workspace that doesn't depend on unicode_width
Clippy check package bar: cargo clippy --package bar

You of course get the error when you run clippy normally without --package, as it checks every one individually.

I think checking the top-level Cargo.lock would fix this. Though I am not sure how you would handle aliases properly (like if foo did unic_width = { package = "unicode-width", ... } and clippy.toml banned unic_width::*)

Or maybe aggregate the dependencies when checking multiple packages at once, to check against?

Fixes rust-lang#14397 (comment)

smoelius · 2025-05-04T13:26:49Z

@RGBCube Thanks for the detailed analysis, which made the issue very easy to reproduce. 🙏

@samueltardieu

Fixes #14397 (comment) r? @samueltardieu changelog: Don't warn about clippy.toml disallowed paths for crates that were not loaded

…onfiguration Starting with Rust 1.88.0 (expected 2025-06-26) [1], Clippy may start warning about paths that do not resolve in the `disallowed_macros` configuration: warning: `kernel::dbg` does not refer to an existing macro --> .clippy.toml:10:5 | 10 | { path = "kernel::dbg", reason = "the `dbg!` macro is intended as a debugging tool" }, | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This is a lint we requested at [2], due to the trouble debugging the lint due to false negatives (e.g. [3]), which we use to emulate `clippy::dbg_macro` [4]. See commit 8577c9d ("rust: replace `clippy::dbg_macro` with `disallowed_macros`") for more details. Given the false negatives are not resolved yet, it is expected that Clippy complains about not finding this macro. Thus, until the false negatives are fixed (and, even then, probably we will need to wait for the MSRV to raise enough), use the escape hatch to allow an invalid path. Cc: [email protected] # Needed in 6.12.y and later (Rust is pinned in older LTSs). Link: rust-lang/rust-clippy#14397 [1] Link: rust-lang/rust-clippy#11432 [2] Link: rust-lang/rust-clippy#11431 [3] Link: rust-lang/rust-clippy#11303 [4] Reviewed-by: Alice Ryhl <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]>

rustbot assigned Manishearth Mar 12, 2025

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties label Mar 12, 2025

rustbot assigned flip1995 and unassigned Manishearth Mar 12, 2025

smoelius force-pushed the validate-paths branch from cdca98d to a7edf7d Compare March 31, 2025 12:13

rustbot assigned samueltardieu and unassigned flip1995 Mar 31, 2025

samueltardieu reviewed Mar 31, 2025

View reviewed changes

rustbot added S-waiting-on-author Status: This is awaiting some action from the author. (Use `@rustbot ready` to update this status) and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties labels Apr 1, 2025

samueltardieu mentioned this pull request Apr 1, 2025

Install cmake to restore lintcheck runs #14514

Merged

Manishearth requested a review from samueltardieu April 1, 2025 16:11

samueltardieu added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties and removed S-waiting-on-author Status: This is awaiting some action from the author. (Use `@rustbot ready` to update this status) labels Apr 1, 2025

rustbot added has-merge-commits PR has merge commits, merge with caution. S-waiting-on-author Status: This is awaiting some action from the author. (Use `@rustbot ready` to update this status) labels Apr 1, 2025

This comment has been minimized.

Sign in to view

smoelius force-pushed the validate-paths branch from 41b6f32 to 1aec8f7 Compare April 1, 2025 16:55

rustbot removed has-merge-commits PR has merge commits, merge with caution. S-waiting-on-author Status: This is awaiting some action from the author. (Use `@rustbot ready` to update this status) labels Apr 1, 2025

smoelius force-pushed the validate-paths branch from 1aec8f7 to f3f25b6 Compare April 1, 2025 18:24

samueltardieu approved these changes Apr 1, 2025

View reviewed changes

smoelius force-pushed the validate-paths branch from f3f25b6 to a122faa Compare April 1, 2025 18:39

Validate paths in disallowed_* configurations

dc7d9ec

smoelius force-pushed the validate-paths branch from a122faa to dc7d9ec Compare April 1, 2025 18:54

samueltardieu added this pull request to the merge queue Apr 1, 2025

Merged via the queue into rust-lang:master with commit e975563 Apr 1, 2025
11 checks passed

smoelius deleted the validate-paths branch April 1, 2025 19:19

ojeda mentioned this pull request Apr 1, 2025

Clippy wanted features & bugfixes Rust-for-Linux/linux#349

Open

46 tasks

smoelius added a commit to smoelius/rust-clippy that referenced this pull request May 4, 2025

Don't warn about unloaded crates

7b7a9a6

Fixes rust-lang#14397 (comment)

smoelius mentioned this pull request May 4, 2025

Don't warn about unloaded crates #14733

Merged

github-merge-queue bot pushed a commit that referenced this pull request May 4, 2025

Don't warn about unloaded crates (#14733)

ea13461

Fixes #14397 (comment) r? @samueltardieu changelog: Don't warn about clippy.toml disallowed paths for crates that were not loaded

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Validate paths in `disallowed_*` configurations #14397

Validate paths in `disallowed_*` configurations #14397

smoelius commented Mar 12, 2025 •

edited

Loading

rustbot commented Mar 12, 2025

Manishearth commented Mar 12, 2025

smoelius commented Mar 31, 2025 •

edited

Loading

flip1995 commented Mar 31, 2025

samueltardieu left a comment

samueltardieu Mar 31, 2025

smoelius Apr 1, 2025

samueltardieu Apr 1, 2025

smoelius Apr 1, 2025

samueltardieu Mar 31, 2025

samueltardieu Mar 31, 2025

samueltardieu Mar 31, 2025 •

edited

Loading

samueltardieu Mar 31, 2025

smoelius Apr 1, 2025

samueltardieu Mar 31, 2025

smoelius Apr 1, 2025 •

edited

Loading

samueltardieu Apr 1, 2025

samueltardieu commented Apr 1, 2025

samueltardieu commented Apr 1, 2025

This comment has been minimized.

samueltardieu left a comment

samueltardieu commented Apr 1, 2025

smoelius commented Apr 1, 2025

RGBCube commented May 3, 2025

smoelius commented May 3, 2025

RGBCube commented May 3, 2025 •

edited

Loading

RGBCube commented May 3, 2025 •

edited

Loading

smoelius commented May 4, 2025

Validate paths in disallowed_* configurations #14397

Validate paths in disallowed_* configurations #14397

Conversation

smoelius commented Mar 12, 2025 • edited Loading

rustbot commented Mar 12, 2025

Manishearth commented Mar 12, 2025

smoelius commented Mar 31, 2025 • edited Loading

flip1995 commented Mar 31, 2025

samueltardieu left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

samueltardieu Mar 31, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

smoelius Apr 1, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

samueltardieu commented Apr 1, 2025

samueltardieu commented Apr 1, 2025

This comment has been minimized.

samueltardieu left a comment

Choose a reason for hiding this comment

samueltardieu commented Apr 1, 2025

smoelius commented Apr 1, 2025

RGBCube commented May 3, 2025

smoelius commented May 3, 2025

RGBCube commented May 3, 2025 • edited Loading

RGBCube commented May 3, 2025 • edited Loading

smoelius commented May 4, 2025

Validate paths in `disallowed_*` configurations #14397

Validate paths in `disallowed_*` configurations #14397

smoelius commented Mar 12, 2025 •

edited

Loading

smoelius commented Mar 31, 2025 •

edited

Loading

samueltardieu Mar 31, 2025 •

edited

Loading

smoelius Apr 1, 2025 •

edited

Loading

RGBCube commented May 3, 2025 •

edited

Loading

RGBCube commented May 3, 2025 •

edited

Loading