Skip to content

Macros wrapping expressions in unsafe blocks when using unsafe_op_in_unsafe_fn #7323

@ojeda

Description

@ojeda

What it does

For projects using unsafe_op_in_unsafe_fn (and specially those requiring // SAFETY comments), it would be nice to detect cases where a macro is wrapping an expression passed as a parameter in a "hidden" unsafe block, and thus bypassing the intention of unsafe_op_in_unsafe_fn.

The logic could be something like:

  • If inside an unsafe fn...
  • And there is a macro call outside an unsafe block...
  • And unsafe_op_in_unsafe_fn is enabled in this context...
  • And if the node/AST/tree of a parameter appears as-is...
  • Then check that node/AST/tree is not inside an introduced unsafe block.

Callers of the macro would need to wrap the entire macro call in an unsafe block to avoid hitting the lint (plus perhaps playing with #[allow(unused_unsafe)] inside the macro to avoid the unneeded nested unsafe warning from rustc).

Categories (optional)

  • Kind: clippy::pedantic?

Drawbacks

None.

Example

Assume #![deny(unsafe_op_in_unsafe_fn)], and that container_of! wraps the first parameter in an unsafe block. Then:

let reg = container_of!((*file).private_data, Self, mdev);

Could be written as:

let reg = unsafe { container_of!((*file).private_data, Self, mdev) };

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-lintArea: New lints

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions