Allocate Vec capacity based on size hints during decoding

[jordy25519]

Discovered this issue while profiling another crate

[vkgnosis]

This fails CI. I guess there is a case where the code without with_capacity never end ups really allocating that much.

[jordy25519]

This fails CI. I guess there is a case where the code without with_capacity never end ups really allocating that much.

Ok I'm glad this happened since some malicious payloads could cause large memory allocation in my previous commit. Iterator should have the same effect to avoid reallocs and not allocate upfront

[vkgnosis]

Iterator should have the same effect to avoid reallocs and not allocate upfront

I don't think that's true. The current version of the PR works the same as it did before the PR but using collect instead of manually pushing. Either way the Vector reallocate as elements get added because the final size isn't known upfront.

[jordy25519]

you're right- after some benchmarking, the iterator size hints didn't work how I thought.
original error caused by test runner on 32bit machine can't allocate enough space in the 'corrupted dynamic array' test when using with_capacity. try_reserve fixes the issue so we can handle the error properly.

before this PR:

with iterator:
still has some reallocs and some over head

with try_reserve_exact:

benchmark code used

use ethabi::{self, decode, encode, ParamType, Token};

fn main() {
    let tokens: Vec<Token> = (0..100)
        .map(|i| Token::Address([i % 3 as u8; 20].into()))
        .collect();
    let param_types = vec![ParamType::Tuple(vec![ParamType::Address; tokens.len()])];
    let expected = vec![Token::Tuple(tokens)];
    let encoded = encode(&expected);

    for _ in 0..=50_000 {
        assert_eq!(decode(&param_types, &encoded,).unwrap(), expected);
    }
}

[vkgnosis]

Why this change? I think you are changing behavior because the previous version still implemented Default when T wasn't Default while the new one doesn't. Either way, it's unrelated to the rest of the PR.

[jordy25519]

there's no behaviour change, the compiler recommended this change in the CI failure.
this compiles fine:

	#[test]
	fn default_for_topic_T() {
		struct Foo;
		let f = Topic::<Foo>::default();
	}

[jordy25519]

I only changed it due to the CI failure, happy to keep or revert it either way

[vkgnosis]

Does CI fail because of that or is a warning? Apparently derive got smarter and it doesn't change behavior. I'm fine with keeping the change then.

[jordy25519]

CI failed, I actually think it was a clippy suggestion but it is configured to fail the job