Skip to content

Fix operator precedence in test_cudart.supportsCudaAPI - #2554

Open
LeSingh1 wants to merge 1 commit into
NVIDIA:mainfrom
LeSingh1:supports-cuda-api-precedence
Open

Fix operator precedence in test_cudart.supportsCudaAPI#2554
LeSingh1 wants to merge 1 commit into
NVIDIA:mainfrom
LeSingh1:supports-cuda-api-precedence

Conversation

@LeSingh1

@LeSingh1 LeSingh1 commented Aug 9, 2026

Copy link
Copy Markdown
Contributor
def supportsCudaAPI(name):
    return name in dir(cuda) or dir(cudart)

This parses as (name in dir(cuda)) or dir(cudart). dir(cudart) is a non-empty list for
any module, so it is unconditionally truthy — the function returns a truthy value for
every input, including names that exist nowhere:

>>> supportsCudaAPI("this_is_not_a_cuda_api")
['__all__', '__builtins__', ...]        # a list, not False

The left operand is dead as well. cuda is cuda.bindings.driver, and every name passed
in is a cudaXxx runtime symbol:

probed name driver.pyx runtime.pyx
cudaGraphGetId 0 1
cudaGreenCtxCreate 0 1
cudaDeviceGetExecutionCtx 0 1
cudaGraphConditionalHandleCreate 0 2

So name in dir(cuda) is always False and the result is always the dir(cudart) list.

Consequence

not supportsCudaAPI(...) is always False, so the API-presence half of all 17
skipif guards that use it never fires — lines 1443, 1501, 1528, 1575, 1617, 1646, 1693,
1712, 1727, 1745, 1765, 1793, 1862, 1885, 1902, 1933, 1954. Only the
driver_version_less_than(...) half of each guard does any work.

Those guards exist because the driver version and the binding version are independent:
cuda-bindings built against an older toolkit will not expose cudaGraphGetId even on a
13.1 driver. Today such a build runs the test and dies with AttributeError instead of
skipping.

Fix

name in dir(cuda) or name in dir(cudart) — complete the second comparison. I kept the
dir(cuda) half rather than narrowing to the runtime module: it is what the author wrote,
it is harmless, and narrowing it would be a second, unrelated decision.

Test

test_supportsCudaAPI pins all three cases — a runtime-only name (cudaMalloc), a
driver-only name (cuInit), and a name that exists in neither. The last two fail on
main
: supportsCudaAPI("cuInit") returns a list, not True, and
supportsCudaAPI("this_is_not_a_cuda_api") returns that same truthy list instead of
False. It needs no GPU and no driver — dir() does not load anything.

ruff format --check is clean. ruff check reports one pre-existing I001 on this file
that is byte-identical on upstream/main; I left it alone as out of scope.

    def supportsCudaAPI(name):
        return name in dir(cuda) or dir(cudart)

parses as `(name in dir(cuda)) or dir(cudart)`. `dir(cudart)` is a non-empty
list for any module, so it is unconditionally truthy and the function returns
a truthy value for every input, including names that exist nowhere.

The left operand is dead too: `cuda` is cuda.bindings.driver and every name
passed in is a cudaXxx runtime symbol. cudaGraphGetId, cudaGreenCtxCreate,
cudaDeviceGetExecutionCtx and cudaGraphConditionalHandleCreate are all defined
in runtime.pyx and appear nowhere in driver.pyx, so `name in dir(cuda)` is
always False and the result is always the `dir(cudart)` list.

Consequence: `not supportsCudaAPI(...)` is always False, so the API-presence
half of all 17 skipif guards that use it (lines 1443-1954) never fires. On a
build whose bindings genuinely lack the API, the test runs and dies with
AttributeError instead of skipping; only the driver_version_less_than() half
of each guard does any work.

Adds test_supportsCudaAPI, pinning all three cases: a runtime-only name, a
driver-only name, and a name that exists in neither. The last two fail before
this change.
@copy-pr-bot

copy-pr-bot Bot commented Aug 9, 2026

Copy link
Copy Markdown
Contributor

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.

@github-actions github-actions Bot added the cuda.bindings Everything related to the cuda.bindings module label Aug 9, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cuda.bindings Everything related to the cuda.bindings module

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant