Fix bitwise_unary_op

[connortsui20]

Summary

Closes: #6895 (which might seem completely unrelated but is relevant because of an incorrect mask)

Fixes a bug in bitwise_unary_op where the it used Arrow's UnalignedBitChunk iterator, which for buffers larger than 16 bytes (128 bits) uses align_to::<u64>() and introduces lead padding zeros when the byte pointer isn't u64-aligned. After applying the operation (e.g. NOT), those padding bits were written into a fresh, aligned output buffer at real data positions, corrupting the first padding bits of the result

This change just delegates to the correct mut implementation which is likely also faster.

Testing

Adds a simple regression test.

[robert3005]

Ah, that's why you can't just change this. I made this change in #6880 which means that binary op needs adjustment as well. I don't see how the mut op would be faster though

[codspeed-hq]

Merging this PR will degrade performance by 12.27%

⚡ 1 improved benchmark
❌ 1 regressed benchmark
✅ 1007 untouched benchmarks
⏩ 1515 skipped benchmarks¹

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
⚡	Simulation	binary_search_std	582.8 ns	524.4 ns	+11.12%
❌	Simulation	true_count_vortex_buffer[128]	1 µs	1.2 µs	-12.27%

---

_{Comparing ct/fix-bit-unary (e0daf70) with develop (18bef2b)}

Footnotes

1. 1515 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[robert3005]

align_to is not the problem here though? It's that the padding is wrong so offset and length are wrong

[connortsui20]

I thought that align to caused the padding to be wrong in this case.

Anyways I don't see much reason to not just delegate to the _mut version, the regression on codspeed is likely because it was just incorrect before.

[robert3005]

align_to just splits the buffer (it's a const function). But the padding is clearly not preserved for any buffer in 17-32 range potentially. Anyway I agree with your fix. We should make sure to fix the binary op as well since we're here

[connortsui20]

what do you mean by fix the binary op?

[robert3005]

I can follow up with the fix to binary op

[robert3005]

Ok, binary op is not a problem since it's only ever used for aligned arrays (i.e. 8 byte aligned) but we really only need 1 byte alignment