Add small key type tests for static_set and static_map::find

[ksapru]

Extends the static_set unit-test type matrices to cover sub-4-byte key types (uint8_t and uint16_t), as requested in the good first issue.

Changes:

• Added uint8_t and uint16_t to the TEMPLATE_TEST_CASE_SIG type axes in all 8 templated static_set test files
• Added a compile-time num_keys guard (sizeof(Key) == 1 ? 100 : 400) to keep key sequences within each type's representable range, leaving room for the 0xFF / 0xFFFF empty sentinel
• Adjusted hardcoded gold_capacity values in unique_sequence_test and retrieve_all_test to be conditional on num_keys
• Parameterized expected sum values in for_each_test to match the reduced key count for uint8_t

The underlying implementation (packed_cas via cuda::atomic_ref) already supports 1B and 2B atomic operations — these tests verify that correctness holds end-to-end for small key types.

Part of #805

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[sleeepyjack]

/ok to test 7b0beb1

[sleeepyjack]

/ok to test 323adf8

[ksapru]

/ok to test 281721b

[sleeepyjack]

/ok to test 281721b

[sleeepyjack]

/ok to test 61993aa

[sleeepyjack]

/ok to test 22ad7ae

[sleeepyjack]

/ok to test 6dc9527

[sleeepyjack]

CI passes. Nice work! I'll give it a review on Monday or Tuesday depending on my workload. In the meantime, we can prepare follow up PRs: (1) replicate the same test extensions to all data structures, also sparsely testing combinations of differenty sized key/value types (e.g. 1B keys and 4B payloads), (2) go over the docs, readme, and asserts to make sure they reflect the new type constraints.

[ksapru]

Thanks @sleeepyjack. Is there an easier way to reproduce CI locally in the future?

[PointKernel]

Thanks @sleeepyjack. Is there an easier way to reproduce CI locally in the future?

@ksapru All the CI environment is shared via devcontainers. You could use them to repro the issue.

[sleeepyjack]

Thanks @sleeepyjack. Is there an easier way to reproduce CI locally in the future?

@ksapru , yes, @PointKernel 's suggestion is the right way to go. Note that if CI fails, the associated test/build log will tell you at the end how to spin up the corresponding devcontainer environment to reproduce the bug. If you don't have access to a GPU system, you can still use the base images of the devcontainers (e.g., this image) directly to at least compile the code locally by running the ci/build.sh script.

[sleeepyjack]

/ok to test 9e5899f

[sleeepyjack]

@ksapru do you want to extend the tests for the other open addressing based data structures in this PR or in a follow up PR?

[sleeepyjack]

/ok to test ce7e89f

[PointKernel]

/ok to test 81c502e

[PointKernel]

/ok to test f24907a

[PointKernel]

I’ve cleaned up the code to avoid unnecessary CI iterations. In the process, I realized my previous statement was incorrect: the packed<1> code path is actually the desired behavior, as set will use that specific path as well. Sorry for the confusion, and thanks again for the contribution @ksapru.

[sleeepyjack]

/ok to test 0d61796

[sleeepyjack]

Thanks for your contribution @ksapru