chore(deps): upgrade itertools to v0.15

[claude]

Requested by Arthur Pastel · Slack thread

Before: the workspace depends on itertools 0.14.0, used by cargo-codspeed and codspeed-divan-compat-macros.

After: the workspace depends on itertools 0.15.0. Cargo.lock is updated with cargo update -p itertools@0.14.0 only, so no other dependency moves.

How: the 0.15 breaking changes (Position becomes a struct, all_equal_value error type) touch APIs neither crate uses; we only rely on collect_vec, join, unique and unique_by, so no code change is needed. itertools 0.15 keeps an MSRV of 1.63, below the crates' 1.85. The vendored criterion fork (codspeed-criterion-compat-walltime) still pins itertools = "0.10" like upstream criterion and is left as is.

Closes #192

---

Generated by Claude Code

[codspeed]

Merging this PR will regress 14 benchmarks

⚠️ 59 benchmarks measured no execution time

Nothing ran under measurement, usually because the compiler removed the code under test. These results are not comparable, so they count as unchanged.

Preventing compiler optimizations

⚠️ Different runtime environments detected

Some benchmarks with significant performance changes were compared across different runtime environments,
which may affect the accuracy of the results.

Open the report in CodSpeed to investigate

⚡ 15 improved benchmarks
❌ 14 regressed benchmarks
✅ 565 untouched benchmarks

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	WallTime	string_copy_with_bytes_counter	56 ns	71 ns	-21.13%
❌	Simulation	add_two_integers[(42, 13)]	233.8 ns	288 ns	-18.81%
❌	Simulation	add_two_integers[(255, 255)]	233.8 ns	288 ns	-18.81%
❌	WallTime	iter_batched_ref_large_input	5 ns	6 ns	-16.67%
❌	Simulation	add_two_integers[(1024, -1024)]	295.2 ns	349.4 ns	-15.5%
❌	WallTime	from_elem_decimal[1024]	179 ns	211 ns	-15.17%
❌	Simulation	add_two_integers[(65535, -65535)]	307 ns	361.1 ns	-15%
❌	WallTime	iter_with_setup	48 ns	56 ns	-14.29%
❌	WallTime	graph_coloring[6]	1.2 µs	1.4 µs	-11.65%
❌	WallTime	iter_batched_large_input	8 ns	9 ns	-11.11%
❌	WallTime	iter_batched_per_iteration	46 ns	49 ns	-6.12%
❌	Simulation	iter_manual_simple	894.9 ns	949.1 ns	-5.71%
❌	WallTime	iterative[10]	17 ns	18 ns	-5.56%
❌	WallTime	init_array[42]	35 ns	37 ns	-5.41%
⚡	WallTime	hamiltonian_cycle[5]	1,535 ns	869 ns	+76.64%
⚡	Simulation	find_highest_set_bit[0]	282 ns	172.3 ns	+63.7%
⚡	Simulation	count_set_bits[0]	225.9 ns	170.3 ns	+32.62%
⚡	Simulation	rem	232.3 ns	178.1 ns	+30.42%
⚡	Simulation	div	232.3 ns	178.1 ns	+30.42%
⚡	Simulation	find_highest_set_bit[42]	283.5 ns	229.3 ns	+23.62%
...	...	...	...	...	...

ℹ️ Only the first 20 benchmarks are displayed. Go to the app to view all benchmarks.

Tip

Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing chore/itertools-0.15 (8f007e2) with main (d07bbd0)}

[claude]

The failing CodSpeed Performance Analysis check is not caused by this PR:

• itertools is only used by cargo-codspeed (build tooling, never inside a measurement) and by the divan proc-macro (compile time only). The macro-expanded math and the_algorithms benches of codspeed-divan-compat-examples (-Zunpretty=expanded) are byte-identical between base 832f252 and this head.
• The same ~55 ns jump shows up in reverse on the base commit's own run (832f252 vs 96e1aca, a manifest-only release bump). For example, iterative[5] went 289.6 → 234.1 ns there and 234.1 → 289.6 ns here.
• criterion_compat benches also regressed (e.g. Simulation iter_manual_simple 839.4 → 893.5 ns), even though nothing in their dependency graph changes in this PR.

There is no code fix to port. A maintainer can acknowledge the regressions on CodSpeed.

---

Generated by Claude Code