Repository navigation
[FEA]: Tests for ltoir, fatbin, object, and library constructors #663
Description
Is this a duplicate?
- 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.
#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 Add more
ObjectCodeconstructors #652 (comment)
Describe alternatives you've considered
No response
Additional context
No response
Metadata
Metadata
Assignees
Labels
Type
Projects
- Status
Activity
benhg commentedon Aug 16, 2025
Adding a note here about the
libraryconstructor. 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 atcuda-python/cuda_core/cuda/core/experimental/_linker.py
Line 398 in 8f1dd40
leofang commentedon Aug 22, 2025
@copilot let's do the following steps to resolve this issue:
nvJitLinkAddFileorcuLinkAddFile(plus test coverage).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.38 remaining items
rparolin commentedon May 29, 2026
@lijinf2 Please talk with @leofang and confirm what should be done to close off this issue. Thanks!
isVoid commentedon Jun 3, 2026
One small suggestion: the original feature suggestion suggested the binary util from numba-cuda to generate test binaries, there's a better way to do this in Numba-cuda-mlir now:
We use pytest fixtures to generate / cache the test binaries at test setup, then use them on-demand based on the test marker. Example:
@pytest.mark.numba_cuda_test_binaries("a", "cubin")demonstrates that the test depend on a mock static library and a cubin. This allows pytest to dynamically solve the required binary to generate and always generate the minimal set.
Def: https://github.com/NVIDIA/numba-cuda-mlir/blob/abd9129fdad64b3f8c93427b1362707eb2d29b75/tests/conftest.py#L324
Use: https://github.com/NVIDIA/numba-cuda-mlir/blob/abd9129fdad64b3f8c93427b1362707eb2d29b75/tests/numba_cuda_tests/cudadrv/test_nvjitlink.py#L22
acosmicflamingo commentedon Jun 5, 2026
@isVoid pretty neat! Assuming that @lijinf2 has not had a chance to talk to @leofang yet, do you think the best path forward is that I apply the aforementioned approach to this PR, even if it means that there is some code duplication going on? Or would it be better to actually house that functionality in this already-present
cuda_python_test_helpersmodule here and have numba-cuda-mlir import the pytest fixtures from there (and also use it to address this ticket)?isVoid commentedon Jun 5, 2026
@acosmicflamingo I'm gonna say we can have test infrastructure duplication. They could start off looking similar but could ended up evolving in different directions.
acosmicflamingo commentedon Jun 5, 2026
@isVoid thanks!
@lijinf2 Sorry! In a nutshell, I didn't want to step on your toes if you were working on this task. But if you haven't had a chance to work on it, I was just asking about reusing code versus blindly copying and pasting from numba-cuda-mlir in my PR.
lijinf2 commentedon Jun 6, 2026
@acosmicflamingo
Thanks for the clarification, and for checking in about reuse vs copy‑and‑paste.
I was a bit confused by two of the assumptions in your earlier comment:
This issue has been assigned to me for some time, and I’ve been actively working on it. Since it was already assigned before your comment, I believe that was visible on the issue. In situations like this, it would be much more helpful to ask the assignee directly about status or possible collaboration, rather than assuming they haven’t started.
For this ticket, I’ll keep driving the implementation as planned, and I’m happy to consider concrete suggestions on the test infrastructure where they fit. Let’s treat this case as an exception, and in the future, when you see an issue already assigned, please don’t make assumptions about the assignee’s progress — just reach out and ask.
acosmicflamingo commentedon Jun 6, 2026
@lijinf2 I do sincerely apologize for the misunderstanding; I didn't mean any ill-will. I was trying to be proactive, and I'm still new to contributing to open-source. I'll be following the guidelines that @rparolin is merging soon here, so this situation doesn't happen again. Thanks for explaining!