Allow cudf::type_to_id<T const>()

[esoha-nvidia]

Description

Currently, cudf::type_to_id<X> where X is a valid type for converting to a cudf::id only works if X is neither const nor volatile. However, if it has either of those "cv" qualifiers, the function returns type_id::EMPTY.

With this change, return the correct type id no matter the cv-qualifiers.

Checklist

• I am familiar with the Contributing Guidelines.
• New or existing tests cover these changes.
• The documentation is up to date with these changes.

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

[davidwendt]

/ok to test

[esoha-nvidia]

Please wait for CI to pass before merging this! I didn't check it much!

[davidwendt]

/ok to test

[davidwendt]

/ok to test

[davidwendt]

Looks like many compile failures here. Example: https://github.com/rapidsai/cudf/actions/runs/12996716950/job/36246264687?pr=17831#step:8:3511
Looks to be centered on __int128_t but there may be others.
Since branch-25.02 is in burndown I would suggest moving this to 25.04 to give us more time to investigate a viable solution.

[davidwendt]

Are there tests for this function? I would like to add some more!

Tests are in this file:

cudf/cpp/tests/types/type_dispatcher_test.cu

Line 108 in 6dc4a53

TYPED_TEST(TypedDoubleDispatcherTest, TypeToId)

[esoha-nvidia]

@davidwendt Thanks for the pointer. I've added tests.

[karthikeyann]

LGTM 👍

[bdice]

I'm approving this change, as the code looks fine. However, I think it's worth getting more context on the use cases that this solves and/or how it might affect user expectations of cv-qualified types.

This PR drops cv-qualifiers that the user might expect to carry some kind of meaning (though I feel it is unrealistic to assert any meaning for those qualifiers in the context of a libcudf column). Would users of type_to_id<T> expect that a column created with type_to_id<const int> is read-only, for instance? Or some kind of behavior change corresponding to volatile qualifiers? Today, we fail, and I think that's an acceptable position (we don't have type ids that correspond to cv-qualified types).

Does it make sense for cudf to be responsible for dropping cv-qualifiers in type_to_id<T>, or should that requirement fall upon the caller of type_to_id to instead use type_to_id<std::remove_cv_t<T>> if their type may be cv-qualified?

I could envision this PR being just a docs change to state that type_to_id requires non-cv-qualified types.

[davidwendt]

I think this probably falls under
"few things in life are a result of conscious decision instead of a product of circumstance" -JH
I'm ok with this change until we have a reason to distinguish behavior based on cv-qualifiers.

Repeating my suggestion to rebase this on branch-25.04

[esoha-nvidia]

@bdice A type id is just a enum value. it's an int. Would would it even mean for an integer literal to be const? All literals are already constants...

If I write a templated function with type T and I want to make it into a cudf column, I'm going to need to use type_to_id<T>. That new column will not be const, even if the type is.

Bikeshed moment here.

[vyasr]

/ok to test

[vyasr]

Needs a style fix (and unfortunately not one of the fixes that our PR linter can push an autofix for). Please run pre-commit locally and then push up the changes.

[ttnghia]

Also need to rebase upstream.