libcudacxx: guard invocability traits against extended lambdas

[Aminsed]

Summary

• reuse the existing extended-lambda detection logic from invoke_result to block is_invocable{,_r} and is_nothrow_invocable{,_r} when host builds introspect extended lambdas
• rely on a shared helper so the diagnostic is consistent for both __device__ and __host__ __device__ closures
• add NVCC-only .fail.cpp tests that instantiate each trait with extended lambdas to prove the static assertions fire

Testing

• ./ci/util/build_and_test_targets.sh --preset libcudacxx-cpp20 --cmake-options "-DCMAKE_CUDA_HOST_COMPILER=/usr/bin/g++ -DCMAKE_CXX_COMPILER=/usr/bin/g++" --lit-tests "std/utilities/meta/meta.rel/is_invocable.extended_device_lambda.fail.cpp std/utilities/meta/meta.rel/is_invocable.extended_host_device_lambda.fail.cpp std/utilities/meta/meta.rel/is_nothrow_invocable.extended_device_lambda.fail.cpp"
• pre-commit run --files libcudacxx/include/cuda/std/__functional/invoke.h libcudacxx/test/libcudacxx/std/utilities/meta/meta.rel/is_invocable.extended_device_lambda.fail.cpp libcudacxx/test/libcudacxx/std/utilities/meta/meta.rel/is_invocable.extended_host_device_lambda.fail.cpp libcudacxx/test/libcudacxx/std/utilities/meta/meta.rel/is_nothrow_invocable.extended_device_lambda.fail.cpp

Fixes #1984.

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

[miscco]

I believe it is not correct to add those checks in the generic is_invocable machinery

As the error message points out we need this check in places where we need to query the return type of the invokable.

This is already done in the invoke_result struct above is_invocable

If we only want to invoke the lambda, there is no reason to error out. This is especially true, given that this is a nontrivial source breaking change.

[pciolkosz]

I think we shouldn't mention cuda::proclaim_return_type, because it won't help here

[pciolkosz]

If we only want to invoke the lambda, there is no reason to error out. This is especially true, given that this is a nontrivial source breaking change.

I don't agree. I had a use case like this:

if constexpr (is_invocable<Fn, Args...>) {
   // call Fn
}
else {
   // do something else
}

There is no way to express that with invoke_result and currently if Fn is an extended lambda the if statement always evaluates to true regardless of what the argument types are, leading to errors. It might lead to missed errors if someone is not aware of this bizarre behavior.

The source breaking is a valid point, but in the case we would error out we return a false result, which I would say is even worse

[miscco]

The source breaking is a valid point, but in the case we would error out we return a false result, which I would say is even worse

If you care about the return type you need to query it through is_invocable_r and not break other users that dont

[Aminsed]

@miscco Thanks for the feedback. I've removed the static_asserts from the invocability traits and kept the diagnostic only in invoke_result where the return type is actually queried. Please let me know if there's anything else that needs adjustment.

[miscco]

These changes are actually pessimizations of the current code.

We do not want to instantiate types just to access a value that we could have gotten directly.

I believe we should close this

[miscco]

This is actually really bad because it now forces us to instantiate types when we do not want to do that