Rust-clippy: same_item_push is incorrect in several cases

Created on 29 Aug 2020  路  3Comments  路  Source: rust-lang/rust-clippy

Code: the pdf crate on this commit https://github.com/Ploppz/pdf/tree/535429d8543434fbd5f46b4589c013bf96be9d10/pdf .
cargo clippy says:

warning: it looks like the same item is being pushed into this Vec
   --> pdf/src/object/stream.rs:247:17
    |
247 |                 offsets.push(offset);
    |                 ^^^^^^^
    |
    = note: `#[warn(clippy::same_item_push)]` on by default
    = help: try using vec![offset;SIZE] or offsets.resize(NEW_SIZE, offset)
    = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#same_item_push

warning: it looks like the same item is being pushed into this Vec
  --> pdf/src/parser/parse_xref.rs:30:9
   |
30 |         entries.push(entry);
   |         ^^^^^^^
   |
   = help: try using vec![entry;SIZE] or entries.resize(NEW_SIZE, entry)
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#same_item_push

Which seems incorrect.

Pasting the code in question here:

        let mut offsets = Vec::new();
        {
            debug!("parsing stream");
            let mut lexer = Lexer::new(stream.data()?);
            for _ in 0..(stream.info.num_objects as ObjNr) {
                let _obj_nr = lexer.next()?.to::<ObjNr>()?;
                let offset = lexer.next()?.to::<usize>()?;
                offsets.push(offset);
            }
        }
    let mut entries = Vec::new();
    for _ in 0..num_entries {
        let _type = read_u64_from_stream(width[0], data);
        let field1 = read_u64_from_stream(width[1], data);
        let field2 = read_u64_from_stream(width[2], data);

        let entry =
        match _type {
            0 => XRef::Free {next_obj_nr: field1 as ObjNr, gen_nr: field2 as GenNr},
            1 => XRef::Raw {pos: field1 as usize, gen_nr: field2 as GenNr},
            2 => XRef::Stream {stream_id: field1 as ObjNr, index: field2 as usize},
            _ => return Err(PdfError::XRefStreamType {found: _type}), // TODO: Should actually just be seen as a reference to the null object
        };
        entries.push(entry);
    }

Meta

  • cargo clippy -V: clippy 0.0.212 (de521cb 2020-08-21)
  • rustc -Vv:
    rustc 1.47.0-nightly (de521cbb3 2020-08-21) binary: rustc commit-hash: de521cbb303c08febd9fa3755caccd4f3e491ea3 commit-date: 2020-08-21 host: x86_64-unknown-linux-gnu release: 1.47.0-nightly LLVM version: 10.0
E-medium L-bug

Most helpful comment

Can confirm, self-contained version of the first example: Playground

All 3 comments

Can confirm, self-contained version of the first example: Playground

Hmm, it might be better not to emit a lint when the pushed item is the variable that introduced in loop, but what about? Of cource, while I think the above FP can be avoided FN will occur in the following cases.
https://github.com/rust-lang/rust-clippy/blob/f98ffa271d0112d04b482e1d61228d99bf006ccf/tests/ui/same_item_push.rs#L25-L29

Maybe an even simpler example using const fns from STD.

fn main() {
    let start = std::time::Instant::now();
    let mut vec = Vec::new();
    for _ in 0..1000 {
        let elapsed = std::time::Instant::now() - start;
        vec.push(elapsed.as_millis());
    }
}
Was this page helpful?
0 / 5 - 0 ratings

Related issues

matthiaskrgr picture matthiaskrgr  路  3Comments

f-fr picture f-fr  路  3Comments

phansch picture phansch  路  3Comments

matthiaskrgr picture matthiaskrgr  路  3Comments

taiki-e picture taiki-e  路  3Comments