Place inline and cold attributes on helper functions

Move the starter's misplaced attribute to the helper functions used by the supplied loop. Keep the constant, signatures and function bodies unchanged.

pub fn mix(x: u64) -> u64
pub fn fold(acc: u64, v: u64) -> u64
pub fn report_overflow(i: usize) -> u64

Apply #[inline] to mix and fold, which run on every iteration. Apply #[cold] to report_overflow, which is called only when the accumulator's low sixteen bits are zero. Remove #[inline] from GOLDEN: it is a constant, not a function. The supplied starter is rejected for that placement on the exercise toolchain.

What the supplied loop does

The harness accepts n and seed as u64 values. Starting with acc = seed and hits = 0, it repeats these steps for each i from zero up to, but excluding, n:

1. Compute v = mix(i ^ acc).
2. Replace acc with fold(acc, v).
3. If acc & 0xFFFF == 0, add report_overflow(i as usize) with wrapping arithmetic and increment hits.

It returns the final acc and hits. With n equal to zero, the result is the original seed and zero hits. The helper name report_overflow does not mean that an arithmetic overflow was detected: the branch tests the low bits. All supplied wrapping operations are intentional and must be preserved.

The branch frequency depends on the generated values. One hit per 65,536 iterations is a rough expectation for uniformly distributed low bits, not a fixed interval or a guarantee for every seed.

What the attributes mean

Inlining replaces a call with the called function's code, which can expose more optimization opportunities. #[inline] encourages it; #[inline(always)] is a stronger request and #[inline(never)] discourages it. These are hints, not promises. The compiler can also inline an unannotated function.

#[cold] says that calls are expected to be uncommon. It can influence code generation, but does not guarantee a particular placement, branch instruction or absence of inlining. More inlining can increase code size and can help or hurt performance. Attribute placement alone does not establish a speedup.

See the code generation attribute reference.

Why build settings matter

Codegen units split a crate's compilation work into parts. Their number and link-time optimization (LTO) affect compilation cost and optimization opportunities. They are not determined by the number of source files. Changing either setting can change the effect of an inline hint; one codegen unit or LTO does not guarantee that two versions run equally fast.

The local Rust runner compiles optimized code with rustc -O. It does not explicitly select a codegen-unit count or LTO mode. When comparing performance, record the compiler version, target and build flags, and measure the relevant workload under the same conditions. Do not treat a timing from another machine as an expected result for this exercise.

See rustc's codegen options. Passing requires compilation, correct outputs and Clippy with warnings denied. Output tests check the arithmetic; they do not prove that a hint caused a particular optimization. Use the requested attributes to complete the lesson.