Skip to content

Conversation

@Lallapallooza
Copy link

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 rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties label Sep 29, 2025
@rustbot
Copy link
Collaborator

rustbot commented Sep 29, 2025

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
Copy link
Author

@blyxyas ping

@blyxyas
Copy link
Member

blyxyas commented Oct 9, 2025

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!

Copy link
Member

@blyxyas blyxyas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Author

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
Copy link
Contributor

ojeda commented Oct 11, 2025

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
Copy link
Author

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
Copy link
Member

blyxyas commented Oct 13, 2025

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
Copy link
Contributor

ojeda commented Oct 13, 2025

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).

@rustbot

This comment has been minimized.

@blyxyas
Copy link
Member

blyxyas commented Nov 12, 2025

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.

@rustbot
Copy link
Collaborator

rustbot commented Nov 17, 2025

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
Copy link
Author

@blyxyas Thanks, I have rebased pr.

@blyxyas
Copy link
Member

blyxyas commented Nov 20, 2025

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

Copy link
Member

@blyxyas blyxyas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

View changes since this review

@rustbot 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
@rustbot
Copy link
Collaborator

rustbot commented Nov 24, 2025

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

@rustbot 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
@Lallapallooza
Copy link
Author

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

Copy link
Member

@blyxyas blyxyas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

View changes since this review

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());
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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;
}

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

added a NOTE why it's needed

@rustbot rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties label Dec 16, 2025
@rustbot rustbot added the S-waiting-on-author Status: This is awaiting some action from the author. (Use `@rustbot ready` to update this status) label Dec 16, 2025
@rustbot 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 17, 2025
std::mem::drop(value); //~ ERROR: use of a disallowed method `std::mem::drop`
}

#[expect(clippy::disallowed_methods)]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Comment on lines +96 to +97
profiles: FxHashMap<Symbol, TypeLookup>,
known_profiles: FxHashSet<Symbol>,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment on lines +151 to +165
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);
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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);
}
}
}

}

fn check_res_emit(&mut self, cx: &LateContext<'_>, hir_id: rustc_hir::HirId, res: &Res, span: Span) {
let mut active_profiles = SmallVec::<[Symbol; 2]>::new();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✨ Great use of SmallVec!

use rustc_span::{Span, Symbol};

#[derive(Copy, Clone)]
pub struct ProfileEntry {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

}

#[derive(Clone)]
pub struct ProfileSelection {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We'll also need some more documentation here

Comment on lines +153 to +161
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);
}
}
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
})
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-review Status: Awaiting review from the assignee but also interested parties

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants