feat: Add profile-specific configuration for disallowed methods and types

[Lallapallooza]

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]

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]

@blyxyas ping

[blyxyas]

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]

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]

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]

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]

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]

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