read_zero_byte_vec refactor for better heuristics
#11766
Conversation
|
r? @Manishearth (rustbot has picked a reviewer for you, use r? to override) |
rustbot
added
the
S-waiting-on-review
|
Let's hope that this is good enough to bring this lint back from |
| // should not lint | ||
| let mut empty = vec![]; | ||
| let mut data7 = vec![]; | ||
| f.read(&mut empty); | ||
|
|
||
| // should not lint | ||
| f.read(&mut data7); |
There was a problem hiding this comment.
This should lint, but the previous implementation can't catch this
|
r? @Alexendoo not going to have time this week I think |
|
Friendly ping :) @Alexendoo |
|
r? @blyxyas since it seems like you have the least amount of pending reviews in queue (if you don't mind, of course) |
|
@bors r+ |
`read_zero_byte_vec` refactor for better heuristics Fixes #9274 Previously, the implementation of `read_zero_byte_vec` only checks for the next statement after the vec init. This fails when there is a block with statements that are expanded and walked by the old visitor. This PR refactors so that: 1. It checks if there is a `resize` on the vec 2. It works on blocks properly e.g. This should properly lint now: ``` let mut v = Vec::new(); { f.read(&mut v)?; //~^ ERROR: reading zero byte data to `Vec` } ``` changelog: [`read_zero_byte_vec`] Refactored for better heuristics
|
💔 Test failed - checks-action_test |
|
? |
`read_zero_byte_vec` refactor for better heuristics Fixes #9274 Previously, the implementation of `read_zero_byte_vec` only checks for the next statement after the vec init. This fails when there is a block with statements that are expanded and walked by the old visitor. This PR refactors so that: 1. It checks if there is a `resize` on the vec 2. It works on blocks properly e.g. This should properly lint now: ``` let mut v = Vec::new(); { f.read(&mut v)?; //~^ ERROR: reading zero byte data to `Vec` } ``` changelog: [`read_zero_byte_vec`] Refactored for better heuristics
|
💔 Test failed - checks-action_test |
|
I'll retry this one more time (if it doesn't work, we'll have to investigate further or wait a few hours), it seems like macos is having some sporadic failures. |
|
@bors retry |
|
☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test |
Fixes #9274
Previously, the implementation of
read_zero_byte_veconly checks for the next statement after the vec init. This fails when there is a block with statements that are expanded and walked by the old visitor.This PR refactors so that:
resizeon the vece.g. This should properly lint now:
changelog: [
read_zero_byte_vec] Refactored for better heuristics