Forward Hash::write_iN to Hash::write_uN

[nikic]

The Hasher::write_iN() methods should forward to Hasher::write_uN(), because some Hasher implementations implement only the write_uN() variants, with the expectation that write_iN() will use the same implementation. Most notably, this is the case for the FxHasher used by rustc itself.

This used to be the case previously, but was broken in #59982. As the PR description makes no mention of this particular change, I assume it was unintentional.

In a local test, this mitigates the regression from #73526 on at least one test-case (cc @cuviper), because we're no longer at the mercy of FxHasher::write() getting inlined to get reasonable performance.

[rust-highfive]

r? @kennytm

(rust_highfive has picked a reviewer for you, use r? to override)

[kennytm]

@bors r+

[bors]

📌 Commit 4c14f9d has been approved by kennytm

@bors retry rollup=never

May have perf implications

May I think may have observable change in behaviour, not sure if that means this PR is acceptable or not...

In that sense, this is just reverting the observable change in #59982.

In that sense, this is just reverting the observable change in #59982.

Not really. It was a change from

         self.write(&unsafe { mem::transmute::<_, [u8; 4]>(i) }) 

to

        self.write(&i.to_ne_bytes())

In both cases the function called, the data types, and the values supplied were identical. A Hasher::write(&[...]) may result in a different hash value compared to calling Hasher::write_u32 with the same bytes, as the Hasher has liberty to implement hashing of the two differently.

Oh sorry, I see what you mean, I was looking at the wrong functions ^^ Ignore me.

rollup=never ... May have perf implications

It was accidentally rolled up anyway in #73838.
FWIW, here's the perf comparison of that rollup as a whole.