[FEA]: Tests for `ltoir`, `fatbin`, `object`, and `library` constructors

[brandon-b-miller]

Is this a duplicate?

• [x] I confirmed there appear to be no duplicate issues for this request and that I agree to the Code of Conduct

Area

cuda.bindings

Is your feature request related to a problem? Please describe.

https://github.com/NVIDIA/cuda-python/pull/652 adds these constructors for these various code types to the ObjectCode class, but can't leverage the convenient pattern for testing that the existing ones do and need their own set of tests.

Describe the solution you'd like

Some ideas that have been brought up:

• Take a similar approach to Numba's test binary makefile and vendor some/all of it here with appropriate changes
• Other ideas raised in the comments https://github.com/NVIDIA/cuda-python/pull/652#issuecomment-2902069400

Describe alternatives you've considered

No response

Additional context

No response

[benhg]

Adding a note here about the library constructor. When I pass in a string with a path to the location of the library rather than the bytes of the library, I get TypeError: Expected type bytes, but got str. The exception at https://github.com/NVIDIA/cuda-python/blob/8f1dd40ada363a8e4a65454818bcb2dbab1eb2f9/cuda_core/cuda/core/experimental/_linker.py#L398 likely needs to be adjusted.

[leofang]

@copilot let's do the following steps to resolve this issue:

1. Fix the bug that Ben mentioned above. It should be as simple as removing the type assertion and adding another path that calls either nvJitLinkAddFile or cuLinkAddFile (plus test coverage).
2. Add simple tests for all ObjectCode.from_<something>() constructors. Make sure we cover both in-memory (bytes) and on-disk (str for file path) inputs. This should be enough to ensure the fix for 1 is correct.

[leofang]

ltoir tests are added in #890, but not fatbin, object, or library

[leofang]

@isVoid added nvFatbin bindings in #1467. We can test the fatbin coverage now!