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