feat: Add profile-specific configuration for disallowed methods and types by Lallapallooza · Pull Request #15779 · rust-lang/rust-clippy

Lallapallooza · 2025-09-29T15:17:02Z

Add profile-scoped disallow lists for methods and types, wiring the new configuration tables through a shared resolver that can be toggled with #[clippy::disallowed_profile] attributes.

extend clippy_config::Conf to parse [disallowed-methods-profiles.] and [disallowed-types-profiles.] tables through reusable helpers
introduce clippy_utils::disallowed_profiles to resolve #[clippy::disallowed_profile(s)] attributes with caching, diagnostics for bad inputs, and shared symbol registrations
teach DisallowedMethods and DisallowedTypes to honor active profiles, reuse the combined profile set, and annotate diagnostics with the triggering profile name
add UI TOML coverage for per-profile behavior and refresh the unknown-key fixture for the new configuration entries
register the new attributes and symbols so tool attributes remain recognized and pedantic lints stay clean

changelog: [disallowed_methods]: allow selecting per-scope disallow lists via disallowed-methods-profiles and the clippy::disallowed_profile attribute
changelog: [disallowed_types]: allow selecting per-scope disallow lists via disallowed-types-profiles and the clippy::disallowed_profile attribute

rustbot · 2025-09-29T15:17:07Z

r? @blyxyas

rustbot has assigned @blyxyas.
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

Lallapallooza · 2025-10-08T21:33:05Z

@blyxyas ping

blyxyas · 2025-10-09T22:00:30Z

Hi @Lallapallooza,
Sorry for the delayed feedback, I'm currently a bit busy but I'll work on sending a review for this pull request soon.
Thanks for your contribution!

blyxyas

I'll recount what I understand here, so a user uses a special configuration for settings profiles in their clippy.toml so any function can opt-in to those profiles, enabling warnings to those designated disallows in that function.

For example, one might want to disallow functions that may execute arbitrary code from a string input, into user-input-handling functions, and this is a way to achieve via Clippy warning of those uses.

Am I correct, have I forgotten/misunderstood something? If that's the case, we might be interested in generalizing this a bit so that both (1.) we can use profiles for other lints without the need of adding a special attribute for each lint, and (2.) people can use the general idea of profiles in Clippy to segment their source code for several lints at the same time.

Also, @ojeda could this be interesting for the Rust4Linux project? Should I give it priority?

View changes since this review

Lallapallooza · 2025-10-11T02:01:37Z

You read it correctly. This PR introduces profile-scoped disallow lists in clippy.toml and a per-item opt-in attribute that activates one or more named profiles for the annotated item (fn/mod). Currently, only disallowed_methods and disallowed_types consult these profiles.

I agree that generalizing this is a good idea. I can follow up with a patch if that would be useful. Do you have any preferences for the design or the user interface (i.e., how Clippy users would enable and use profiles)?

ojeda · 2025-10-11T23:10:24Z

Thanks @blyxyas for the ping! It is an interesting idea. IIUC, currently this can only be done at a crate granularity, right? So it is essentially a way to make Clippy more granular -- I agree that generalizing it makes sense. I will try to think if we could use it in Rust for Linux (@Lallapallooza What are the use cases that motivated this? It may help to give some in the docs to inspire others -- thanks!).

Lallapallooza · 2025-10-13T21:36:31Z

Hi @ojeda. My initial contribution was motivated by a need in my project to disallow host-side operations (e.g., any conversion from a device tensor to a host tensor) in specific context (e.g. dir crates/lib/cuda/) so that such code fails to compile.

blyxyas · 2025-10-13T22:52:39Z

Do you have any preferences for the design or the user interface

I'll ask both the entire team, and the style team to see if they have anything to say. In Clippy we don't really have an in-house attribute style guide, so maybe they have some feedback about how this could be implemented.

ojeda · 2025-10-13T23:08:13Z

Thanks @Lallapallooza, that is good to know (if you have more cases you can think of, then it would be great to hear about them, of course).

blyxyas · 2025-11-12T03:04:47Z

Hi Lallapallooza, I've talked with the team and I'm going to proceed with the review. Also, sorry for the delayed response, I've just returned from vacation.

I was thinking that this may be useful for this message thread

After learning about disallowed_names ("foo", "bar" and others that are
in fact classical documentation favorites), I also think it would be
very nice to allow those in documentation.

I thought that we already had a configuration option for this, but it seems that we don't have one. So I think that this feature can also support this use case.

Lallapallooza · 2025-11-17T14:58:04Z

@blyxyas Thanks, I have rebased pr.

blyxyas · 2025-11-20T23:48:54Z

I thought that we already had a configuration option for this, but it seems that we don't have one. So I think that this feature can also support this use case.

I'm walking back this statement, we already have another pull request taking care of this. So we won't focus on that front here.

#15600

blyxyas

We'll need some interface changes to be more ergonomic, but apart from that, this looks great!

View changes since this review

rustbot · 2025-11-24T23:07:16Z

Reminder, once the PR becomes ready for a review, use @rustbot ready.

Lallapallooza · 2025-12-14T05:22:25Z

Hi! I have addressed all comments, could you please check again.

blyxyas

Some more thoughts ฅ(´・ω・｀)ฅ

View changes since this review

blyxyas · 2025-12-16T21:57:51Z

+    pub fn active_profiles(&mut self, cx: &LateContext<'_>, hir_id: HirId) -> Option<&ProfileSelection> {
+        if self.cache.contains_key(&hir_id) {
+            return self.cache.get(&hir_id).and_then(|selection| selection.as_ref());
+        }


self.cache.contains_key is only self.cache.get().is_some(), so it's performing the same lookup two times. It should be something more akin to:

if let Some(selection) = self.cache.get(&hir_id) { return selection; }

added a NOTE why it's needed

blyxyas · 2025-12-17T18:50:17Z

    std::mem::drop(value); //~ ERROR: use of a disallowed method `std::mem::drop`
 }

+#[expect(clippy::disallowed_methods)]


We also need expects for the unknown_profile lint, and trying it before and after the profile attribute.

Added tests in both disallowed_profiles_methods and disallowed_profiles_types covering #[expect(...)] placed before and after #[clippy::disallowed_profile("unknown_...")].

blyxyas · 2025-12-17T19:44:36Z

+    profiles: FxHashMap<Symbol, TypeLookup>,
+    known_profiles: FxHashSet<Symbol>,


Why is profiles different from known_profiles? Is there a difference between these two? Seems that known_profiles is just a set from the keys of profiles.

They're intentionally different: known_profiles holds every name declared in [profiles.*], while profiles only holds those that contribute entries to this lint.

The distinction is what suppresses an "unknown profile" warning when a profile only defines entries for the other lint.

Added field-level comments to make this explicit. Thanks

blyxyas · 2025-12-17T19:51:23Z

+        let mut active_profiles = SmallVec::<[Symbol; 2]>::new();
+        let mut unknown_profiles = SmallVec::<[ProfileEntry; 2]>::new();
+        if let Some(selection) = self.profile_cache.active_profiles(cx, hir_id) {
+            for entry in selection.iter() {
+                if self.profiles.contains_key(&entry.name) {
+                    active_profiles.push(entry.name);
+                } else if !self.known_profiles.contains(&entry.name) {
+                    unknown_profiles.push(*entry);
+                }
+            }
+        }
+
+        for entry in unknown_profiles {
+            self.warn_unknown_profile(cx, &entry);
+        }


If we are going to lint them one by one anyways, this self.warn_unknown_profile should be above.

Suggested change

let mut active_profiles = SmallVec::<[Symbol; 2]>::new();

let mut unknown_profiles = SmallVec::<[ProfileEntry; 2]>::new();

if let Some(selection) = self.profile_cache.active_profiles(cx, hir_id) {

for entry in selection.iter() {

if self.profiles.contains_key(&entry.name) {

active_profiles.push(entry.name);

} else if !self.known_profiles.contains(&entry.name) {

unknown_profiles.push(*entry);

}

}

}

for entry in unknown_profiles {

self.warn_unknown_profile(cx, &entry);

}

let mut active_profiles = SmallVec::<[Symbol; 2]>::new();

let mut unknown_profiles = SmallVec::<[ProfileEntry; 2]>::new();

if let Some(selection) = self.profile_cache.active_profiles(cx, hir_id) {

for entry in selection.iter() {

if self.profiles.contains_key(&entry.name) {

active_profiles.push(entry.name);

} else {

self.warn_unknown_profile(cx, &entry);

}

}

}

Done, thanks! Dropped the intermediate unknown_profiles SmallVec and warn inline.

I had to copy entries out of the cache first because warn_unknown_profile takes &mut self and the active_profiles borrow holds &mut self.profile_cache.

blyxyas · 2025-12-17T19:57:20Z

+use rustc_span::{Span, Symbol};
+
+#[derive(Copy, Clone)]
+pub struct ProfileEntry {


We'll need some documentation here, what is the entry for? What does it represent?

Added a doc comment explaining that each entry represents one profile-name argument from a #[clippy::disallowed_profile(s)] attribute. Thanks!

blyxyas · 2025-12-17T20:20:54Z

+        if let Some(selection) = self.profile_cache.active_profiles(cx, hir_id) {
+            for entry in selection.iter() {
+                if self.profiles.contains_key(&entry.name) {
+                    active_profiles.push(entry.name);
+                } else if !self.known_profiles.contains(&entry.name) {
+                    unknown_profiles.push(*entry);
+                }
+            }
+        }


Suggested change

if let Some(selection) = self.profile_cache.active_profiles(cx, hir_id) {

for entry in selection.iter() {

if self.profiles.contains_key(&entry.name) {

active_profiles.push(entry.name);

} else if !self.known_profiles.contains(&entry.name) {

unknown_profiles.push(*entry);

}

}

}

if let Some(selection) = self.profile_cache.active_profiles(cx, hir_id) {

active_profiles = selection.iter().filter(|profile| {

if !self.profiles.contains_key(&profile.name) { self.warn_unknown_profile(cx, &profile); false}; true

})

}

Applied the inline-warn refactor from the sibling thread. Kept the known_profiles guard so that profiles used for the other lint don't get flagged as unknown here.

Lallapallooza · 2026-04-21T00:48:58Z

Hi @blyxyas, sorry for leaving this PR sitting for so long.

I've rebased onto current master and addressed all the outstanding review comments (docs on ProfileEntry/ProfileSelection, the profiles vs known_profiles distinction, inlining the unknown-profile warning, and the #[expect] before/after tests).

Replies are in each thread. Whenever you have a moment, could you take another look? Thanks again for the reviews. 🙏

Lallapallooza · 2026-06-04T20:03:35Z

@blyxyas Hi, could you check my patch again please.

blyxyas

LGTM, thanks! ❤️
Thanks for taking this amazing contribution until the end, I think that it will heavily improve workflows, and there are many people interested in this kind of configuration option. I might make a blog post about it.

View changes since this review

- document `ProfileEntry` and `ProfileSelection` - explain why `profiles` and `known_profiles` are separate - emit unknown-profile warning inline (drop intermediate SmallVec) - add tests covering `#[expect]` before/after `#[clippy::disallowed_profile]` with an unknown profile name, for both methods and types lints - sort_by -> sort_by_key to satisfy dogfood

rustbot · 2026-06-09T11:45:33Z

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

Lallapallooza · 2026-06-09T11:58:59Z

@blyxyas Thanks! I rebased MR and now it's mergeable.

rustbot assigned blyxyas Sep 29, 2025

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

blyxyas reviewed Oct 10, 2025

View reviewed changes

This comment has been minimized.

Sign in to view

Lallapallooza force-pushed the disallowed-profiles branch from a8c3a91 to 0ff61e7 Compare November 17, 2025 14:54

This comment has been minimized.

Sign in to view

blyxyas requested changes Nov 24, 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 Nov 24, 2025

Lallapallooza requested a review from blyxyas December 14, 2025 05:21

rustbot 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 Dec 14, 2025

blyxyas requested changes Dec 16, 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 Dec 16, 2025

Lallapallooza requested a review from blyxyas December 17, 2025 13:59

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

rustbot removed the S-waiting-on-author Status: This is awaiting some action from the author. (Use `@rustbot ready` to update this status) label Dec 17, 2025

blyxyas reviewed Dec 30, 2025

View reviewed changes

This comment has been minimized.

Sign in to view

Lallapallooza force-pushed the disallowed-profiles branch from d7e5a4b to 647bc06 Compare April 21, 2026 00:37

This comment has been minimized.

Sign in to view

Lallapallooza requested a review from blyxyas April 21, 2026 01:35

This comment has been minimized.

Sign in to view

blyxyas approved these changes Jun 8, 2026

View reviewed changes

Lallapallooza added 5 commits June 9, 2026 12:30

Add profile-specific configuration for disallowed methods and types

f736c1e

fix review

286f01e

config: add [profiles.*] disallowed lists

74f3823

fix: address review feedback

37482e2

Lallapallooza force-pushed the disallowed-profiles branch from 647bc06 to 03128d7 Compare June 9, 2026 11:45

blyxyas approved these changes Jun 9, 2026

View reviewed changes

blyxyas added this pull request to the merge queue Jun 9, 2026

Merged via the queue into rust-lang:master with commit bf2b6ed Jun 9, 2026
11 checks passed

rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties label Jun 9, 2026

		profiles: FxHashMap<Symbol, TypeLookup>,
		known_profiles: FxHashSet<Symbol>,

Conversation

Lallapallooza commented Sep 29, 2025 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Sep 29, 2025

Uh oh!

Lallapallooza commented Oct 8, 2025

Uh oh!

blyxyas commented Oct 9, 2025

Uh oh!

blyxyas left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Lallapallooza commented Oct 11, 2025

Uh oh!

ojeda commented Oct 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Lallapallooza commented Oct 13, 2025

Uh oh!

blyxyas commented Oct 13, 2025

Uh oh!

ojeda commented Oct 13, 2025

Uh oh!

This comment has been minimized.

blyxyas commented Nov 12, 2025

Uh oh!

This comment has been minimized.

Lallapallooza commented Nov 17, 2025

Uh oh!

blyxyas commented Nov 20, 2025

Uh oh!

blyxyas left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

rustbot commented Nov 24, 2025

Uh oh!

Lallapallooza commented Dec 14, 2025

Uh oh!

blyxyas left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Lallapallooza commented Sep 29, 2025 •

edited by rustbot

Loading

blyxyas left a comment •

edited by rustbot

Loading

ojeda commented Oct 11, 2025 •

edited

Loading

blyxyas left a comment •

edited by rustbot

Loading

blyxyas left a comment •

edited by rustbot

Loading

blyxyas left a comment •

edited

Loading