cuda.core: add docstrings to Host properties and public StrEnum types

[aryanputta]

Summary

Contributes to the doc-finalization step of #2131.

Two doc-only changes to cuda.core, touching no logic:

cuda/core/_host.py — Host property docstrings

Host is a new 1.1.0 API (release notes: #2131 checklist item "Finalize the doc update"). The class-level docstring is already complete, but numa_id and is_numa_current had no docstrings, leaving them blank in generated API docs and help():

@property
def numa_id(self) -> int | None:
    """NUMA node ID, or ``None`` if not pinned to a specific NUMA node."""

@property
def is_numa_current(self) -> bool:
    """``True`` if this ``Host`` represents the calling thread's NUMA node (constructed via :meth:`numa_current`)."""

cuda/core/typing.py — StrEnum class docstrings

All 12 public StrEnum subclasses (SourceCodeType, ObjectCodeFormatType, CompilerBackendType, PCHStatusType, GraphConditionalType, GraphMemoryType, ManagedMemoryLocationType, VirtualMemoryHandleType, VirtualMemoryLocationType, VirtualMemoryGranularityType, VirtualMemoryAccessType, VirtualMemoryAllocationType) previously had zero class-level docstrings. Each now has a short description and a one-liner per member so help() and Sphinx show meaningful output.

Checklist

• cuda.core only — no cuda.bindings files touched
• No logic changes — docstrings only
• Consistent with existing single-line property docstring style (Host.numa_current, ManagedBuffer methods)

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

[aryanputta]

@leofang @rwgk — flagging this for your awareness in the context of #2131.

This is a doc-only contribution to cuda.core (no cuda.bindings files touched — I know external contributions there aren't permitted). Both changes are pure docstring additions, zero logic:

• _host.py: Host.numa_id and Host.is_numa_current were undocumented. Since Host is new in 1.1.0 and explicitly in the release notes, having blank property docs felt like the most directly useful thing I could help with for the doc-finalization step.
• typing.py: added class-level docstrings to all 11 public StrEnum types so help() and Sphinx show something meaningful.

Happy to split into two PRs if that's easier to review, or adjust wording on any of the docstrings.

[aryanputta]

@Andy-Jost — one style question before this is review-ready.

For the StrEnum classes, I went with per-member descriptions inside the class docstring body, e.g.:

class ObjectCodeFormatType(StrEnum):
    """Output format produced by :meth:`~cuda.core.Program.compile`.

    ``PTX`` — PTX assembly text.
    ``CUBIN`` — device-native CUDA binary.
    ``LTOIR`` — LTO (link-time optimization) IR for later linking.
    ``FATBIN`` — fat binary bundling multiple device images.
    ``OBJECT`` — relocatable device object.
    ``LIBRARY`` — device code library.
    """

The question is whether that level of detail is right for members that are fairly self-explanatory from their name and string value (PTX = "ptx" probably doesn't need "PTX assembly text"). Two options I see:

A) Keep per-member descriptions i tried to keep it consistent across all 11 types, useful in help() output, and makes Sphinx more readable without needing to cross-reference the CUDA driver docs.

B) Class-level summary only, drop the member list for this i led to a shorter approach which avoids redundancy for obvious members. Something like:

class ObjectCodeFormatType(StrEnum):
    """Output format produced by :meth:`~cuda.core.Program.compile`.

    Accepted values: ``PTX``, ``CUBIN``, ``LTOIR``, ``FATBIN``, ``OBJECT``, ``LIBRARY``.
    """

Happy to go either way — just want to match the preferred convention here before this gets reviewed.