Force inlining of AttrsIter::next()

[philipc]

Before:
test bench_parsing_debug_info ... bench: 2,423,653 ns/iter (+/- 50,801)
test bench_parsing_debug_info_tree ... bench: 2,767,421 ns/iter (+/- 22,242)

After:
test bench_parsing_debug_info ... bench: 1,521,066 ns/iter (+/- 35,440)
test bench_parsing_debug_info_tree ... bench: 1,740,148 ns/iter (+/- 73,535)

It's a bit worrying that this makes such a large difference.

[coveralls]

Coverage remained the same at 93.836% when pulling 8e93980 on philipc:inline into f870889 on gimli-rs:master.

[fitzgen]

It might be worth adding #[inline] to every one of our iterators...

[philipc]

It might be worth adding #[inline] to every one of our iterators...

Only if the benchmark shows significant gain. I prefer not to blindly add #[inline], and even in this case I would like to remove the inline again once rustc improves. A large part of the problem is that rustc isn't optimizing large moves (eg see the code generated for https://is.gd/31IOrU, it does 4 moves when it should only need 1). I think this will improve once rustc has MIR passes for inlining and move propagation. There is currently an open PR for inlining, and work on move propagation has been done in the past.