Add the cuda.core.experiemental.Linker class

[ksimpson-work]

wrap nvjitlink into the object model.
Depends on #224

[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.

[leofang]

I think we need to revert the order:

Suggested change

	def __init__(self, options: LinkerOptions, object_codes = None):
	def __init__(self, *object_codes, options: LinkerOptions = None):

Taking *object_codes also allows us to loop over it later.

[rwgk]

for func in compile_ptx_functions:
    linker.add_code_object(func)

But I think I'd go beyond this:

• Add Linker.add_code_objects(self, iterable): in _linker.py and then use that here:

    linker.add_code_objects(compile_ptx_functions)

• I'd try hard to find something here to assert, or (probably best) just drop this particular test_linker_add_code_object() function, because it's the exact same code as in the next two functions.

[rwgk]

I'm unclear about what combinations of functions {ptx, ltoir} and target_types {ptx, cubin} are valid.

To reduce the code duplication, could this work as a general idea?

@pytest.mark.parametrize("functions", [compile_ptx_functions, compile_ltoir_functions])
@pytest.mark.parametrize("target_type", ["ptx", "cubin"])

I'm not sure if/how that works with fixtures though.

I'd also add these right here:

    log = linker.get_error_log()
    assert isinstance(log, str)
    log = linker.get_info_log()
    assert isinstance(log, str)

I think that could consolidate four test functions into one.

[ksimpson-work]

I like the idea of using parameterize, so I added it to the linker init test. In general I write tests to be as minimal as possible, and then to build on each other. ie I like to test add_code_object() in isolation before calling it in another test such as test_linker_link_ptx. This is just something I picked up when working on my last project, as there were a lot of fragile components, and it made it a faster process to determine where the issue was. That said, you have a lot more experience than me, so I am tempted to go with your suggestion of consolidating tests. I've left it as is for now

[ksimpson-work]

actually, considering the removal of add_codeObject as a public entrypoint that test can go.