Skip to content

Conversation

@samueltardieu
Copy link
Member

@samueltardieu samueltardieu commented Nov 19, 2025

changelog: [multiple_unsafe_ops_per_block]: count unsafe operations only towards the innermost unsafe block

Fixes #16116

r? Jarcho

@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties label Nov 19, 2025
@github-actions
Copy link

github-actions bot commented Nov 19, 2025

Lintcheck changes for 181cb9c

Lint Added Removed Changed
clippy::multiple_unsafe_ops_per_block 0 287 55

This comment will be updated if you push new changes

@Jarcho
Copy link
Contributor

Jarcho commented Nov 19, 2025

The actual issue is nested unsafe blocks, not macros. I feel like we should be skipping them.

unsafe f1() {}
unsafe f2() {}

fn f3() {
  unsafe {
    f1();
    unsafe { f2(); }
  }
}

This only has one unsafe operation in each block, just one of them happens to be nested in another.


We should still be considering a macro call to be a single thing. A macro expanding to multiple unsafe calls without an unsafe block shouldn't trigger the lint.

Also, macro calls are counted as at most one unsafe operation.
@samueltardieu samueltardieu changed the title Do not lint unsafe code coming from external macros Count unsafe operations and macro calls once towards the innermost unsafe block Nov 25, 2025
@samueltardieu
Copy link
Member Author

Done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-review Status: Awaiting review from the assignee but also interested parties

Projects

None yet

Development

Successfully merging this pull request may close these issues.

multiple_unsafe_ops_per_block triggering for format! on nightly

3 participants