Auto-sync is disabled for ready for review pull requests in this repository. Workflows must be run manually.

Contributors can view more details about this message here.

Can we add tests for these new constructors?

Can we add tests for these new constructors?

Right, good question, I was going to ask about this. It's not quite as straightforward to follow the pattern in #470 because this relies on Program being able to compile the original CUDA source to all of the flavors of input we want to test.

We might need to compile some files in the test environment to give us some fatbins, ltoIR objects, etc to test. My first idea was maybe to take inspiration from numba-cuda's binary generation makefile and vendor a portion/all of it here. We'd want to think carefully about what library should test what though to avoid duplicating things and share as many components as possible even across tests, What do you think @kkraus14 ?

Vendoring Numba's existing test (with modification) seems to be a good idea, but @brandon-b-miller could you confirm that if cuda.core adds this change and numba-cuda integrates with it, numba-cuda tests can pass? If so I feel comfortable to merge as is and revisit the tests in a next PR.

Vendoring Numba's existing test (with modification) seems to be a good idea, but @brandon-b-miller could you confirm that if cuda.core adds this change and numba-cuda integrates with it, numba-cuda tests can pass? If so I feel comfortable to merge as is and revisit the tests in a next PR.

This commit:

update for anticipated cuda-python changes

Implements the corresponding numba-cuda changes. Doing this reveals the need for #526, as it seems that is needed for numba's caching machinery. Other then that, the commit passes tests for me locally using CUDA 12, though I'd still like to test in an MVC scenario.

Sounds good, please feel free to take over #526. btw just for completeness, could you also add support for CU_JIT_INPUT_LIBRARY to below line 87?

Two other test ideas:

• For fatbins, we could consider adding the nvfatbin bindings and use it to generate fatbins in memory (Add nvfatbin bindings #156)
• For libraries/objects, we could consider the approach taken by @rwgk and embed a binary blob in the test suite (example) and check in the reproducing steps or scripts in case we need to regenerate the blob (example)

@leofang do you still want to move forward with merging this as-is? I confirmed numba-cuda tests pass with these changes FWIW, and I am happy to write up/take on a separate issue for developing a native set of explicit tests.

and I am happy to write up/take on a separate issue for developing a native set of explicit tests

I am supportive for addressing native tests in a separate PR.

Raised #663

/ok to test eb2bc8b

/ok to test