Add new lint macros_hiding_unsafe_code by flip1995 · Pull Request #7469 · rust-lang/rust-clippy (original) (raw)

I think its design should be thought through a bit more carefully.

I'm also not really satisfied with how the lint currently behaves.

if some library has such a macro already, dependent crates will have no choice but to either get rid of dependency or add a bunch of allow(...), since they can't directly fix the issue.

I don't think this is a problem. I placed this lint in restriction, so that you'll have to enable it explicitly if you want it. If a dependent crate uses this lint and uses an external macro, that hides unsafe operations, the dependent crate probably wants to wrap this macro in an unsafe block, rather than adding allows.

We could just not lint on external macros, but as I just explained, this lint is supposed to restrict what you can and cannot do with macros that hide unsafe code, no matter the origin.

Logically, it's the macro fault that it hides unsafe code, so the lint should be placed on the macro.

With that, I think you would run into the problem with dependent crates. If you would lint a macro definition and tell the user to remove an unsafe block from the macro, all dependent crates using that macro would now have to add an unsafe block around the macro.

We could just not lint exported macros, but I'm not even sure if we're able to lint macro definitions at all, since Clippy is run after macro expansion.