`read_zero_byte_vec` emitted when `read` is in the next block

[unrealhoang]

Summary

As the heuristic is checking if the next statement of an empty vec includes read(&mut v), if the next statement/expression is a block with resize before read, the lint is still fired.

Lint Name

read_zero_byte_vec

Reproducer

I tried this code:

    let mut v = Vec::new();
    {
        v.resize(10, 0);
        r.read(&mut v).unwrap();
    }

I saw this happen:

error: reading zero byte data to `Vec`
   --> src/main.rs:10:5
    |
130 | /     {
131 | |         v.resize(10, 0);
132 | |         r.read(&mut v).unwrap();
133 | |     }
    | |_____^
    |
    = note: `#[deny(clippy::read_zero_byte_vec)]` on by default
    = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#read_zero_byte_vec

I expected to not seeing this lint fired off.

Version

rustc 1.64.0-nightly (0f4bcadb4 2022-07-30)
binary: rustc
commit-hash: 0f4bcadb46006bc484dad85616b484f93879ca4e
commit-date: 2022-07-30
host: x86_64-unknown-linux-gnu
release: 1.64.0-nightly
LLVM version: 14.0.6

Additional Labels

No response

[tamaroning]

I added this lint. (#8964)
For now, this lint checks reads immidiately after creating Vecs and dosen't catch other many cases.
For example, the code below doesn't trigger the lint.

let mut data = Vec::with_capacity(100);
();
f.read(&mut data).unwrap();

Linting all cases by just using AST is tough so I made a compromise.

[crepererum]

I've also encountered this and found it quite confusing under which conditions the lint is triggered:

// triggers read_zero_byte_vec
pub fn f1<T: std::io::Read>(x: &mut T) {
    let mut to_read = 100;
    let mut buf = vec![];

    while to_read > 0 {
        let step = to_read.min(10);
        buf.resize(step, 0);
        x.read_exact(&mut buf).unwrap();
        to_read -= step;
    }
}

// does NOT trigger read_zero_byte_vec
pub fn f2<T: std::io::Read>(x: &mut T) {
    let mut buf = vec![];
    let mut to_read = 100;

    while to_read > 0 {
        let step = to_read.min(10);
        buf.resize(step, 0);
        x.read_exact(&mut buf).unwrap();
        to_read -= step;
    }
}

// does NOT trigger read_zero_byte_vec
pub fn f3<T: std::io::Read>(x: &mut T) {
    let mut to_read = 100;

    while to_read > 0 {
        let mut buf = vec![];
        let step = to_read.min(10);
        buf.resize(step, 0);
        x.read_exact(&mut buf).unwrap();
        to_read -= step;
    }
}

[wildbook]

I just discovered this lint through false positives when running clippy against older code.

All of my so far hits can be simplified down to variants of this:

let mut data = vec![];
match () {
    () => {
        data.resize(10, 0);
        input.read_exact(&mut data)?;
    },
}

It'd be nice if there was a mention of the false positives or restrictions in the lint index, similar to most other lints with known failure cases. I'm also not sure that a lint with so easy-to-trigger false positives should be deny by default, but perhaps I'm just unlucky with it.

[joshtriplett]

It's fine if this has false negatives, but it needs to not have false positives. This shouldn't be checking "the next statement" in a way that includes the whole next block.

[joshtriplett]

I ran into this with code that reduces to the following:

pub fn func(mut stream: impl std::io::Read) {
    let mut size_buf = [0u8; 4];
    let mut buf = Vec::new();
    loop {
        stream.read_exact(&mut size_buf).unwrap();
        let size = u32::from_le_bytes(size_buf) as usize;
        buf.resize(size, 0);
        stream.read_exact(&mut buf).unwrap();
    }
}

This is literally reading the size and resizing the buffer to the appropriate size before reading.