Ignore disallowed_types in foreign macros

[stepantubanov]

changelog: [disallowed_types]: do not trigger in foreign macros

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @xFrednet (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[J-ZhengLi]

in_external_macro is kinda... buggy? I assume, it doesn't detects macros with spanned quote for some reason.

So, if you have a macro defined like this:

#[proc_macro_attribute]
pub fn use_std_hash_map(_args: TokenStream, input: TokenStream) -> TokenStream {
    let mut item = syn::parse_macro_input!(input as syn::ItemFn);
    let span = item.block.brace_token.span;
    let block = item.block;
    item.block = syn::parse_quote_spanned! {
        span =>
        {
            let _ = std::collections::HashMap::<i32, i32>::default();
        }
    };
    quote! {#item}.into()
}

It still triggers this lint, I think you'll need a clippy_utils::is_from_proc_macro check additionally.

[y21]

Is this change motivated by some kind of "real" example? I think it would be reasonable that users might still want to be warned when macro-generated code uses a disallowed type? For example a program intended to be compiled to webassembly might want to disallow std::thread::Builder because webassembly has no threads, and they would also want to know about it even if a macro tries to do that.

[stepantubanov]

Is this change motivated by some kind of "real" example? I think it would be reasonable that users might still want to be warned when macro-generated code uses a disallowed type? For example a program intended to be compiled to webassembly might want to disallow std::thread::Builder because webassembly has no threads, and they would also want to know about it even if a macro tries to do that.

In my case I had this issue with OpenApi macro https://docs.rs/poem-openapi/latest/poem_openapi/attr.OpenApi.html:

struct InternalApi {
  ...
}

#[OpenApi(tag = "super::ApiTags::Tables")]
impl InternalApi {
  ...
}

The problem is usage of disallowed types generated by the macro. And the only way to ignore it is to set #![allow(clippy::disallowed_types)] at the module level, which is not great.

May be we could add an attribute allow_in_external_macros (alongside path and reason attributes) for each type and apply based on that?

[xFrednet]

May be we could add an attribute allow_in_external_macros (alongside path and reason attributes) for each type and apply based on that?

I'd suggest adding a configuration value instead. Something like lint-disallowed-in-external-macros. Here are our docs on how to add a new configuration value: adding configuration to a lint