[code-reflection] RFR: Improved error message on OpenCLBackend if Reflect annotation is missing on transitive methods from kernel method

[Gary Frost]

On Wed, 31 Dec 2025 00:18:12 GMT, Nadeesh TV <ntv at openjdk.org> wrote:

>> **Description** 
>> Currently, if we miss the **@Reflec**t annotation on methods called from kernel functions, no method is generated for them in the corresponding backend. This causes an error like:
>> 
>> `> error: implicit declaration of function 'squareitWithoutReflectAnnotation' is invalid...
>> `
>> **Solution** 
>> - Improved the error message by adding:  *"Did you miss @Reflect annotation on the above function?"* for such cases.
>> 
>>    - Tried throwing an early error on the Java side, but calls to certain methods (e.g., `hat.buffer.S32Array.length()`) lack @Reflect annotations yet map to native functions later. Therefore, I could not find an easy early Java-side validation.
>> 
>> **Test** 
>>   -  A new test is added at **hat.test.TestMissingReflectAnnotation#testTransitiveMethoFromKernelWithoutReflectAnnotation**
>>   - Output of the test case
>> 
>> UNSUPPORTED (log once): buildComputeProgram: cl2Metal failed
>> buildStatus = failed
>> logLen = 234 log  = program_source:68:37: error: implicit declaration of function 'squareitWithoutReflectAnnotation' is invalid in OpenCL
>>         array->array[(long)HAT_GIX]=squareitWithoutReflectAnnotation(value);
>>                                     ^
>> 
>> Did you miss @Reflect annotation on the above function?
>> 
>> Class: hat.test.TestMissingReflectAnnotation
>> Testing: #testComputeMethodWithoutReflectAnnotation..................... [passed]
>> Testing: #testKernelMethodWithoutReflectAnnotation..................... [passed]
>> Testing: #testTransitiveMethoFromKernelWithoutReflectAnnotation..................... [passed]
>> 
>> passed: 3, failed: 0, unsupported: 0, precision-errors: 0
>
> hat/backends/ffi/opencl/src/main/native/cpp/opencl_backend.cpp line 223:
> 
>> 221:                 std::cerr << "clGetBuildInfo (getting log) failed" << std::endl;
>> 222:                 delete[] log;
>> 223:                 log = nullptr;
> 
> @grfrost Not sure whether this delete was really needed. 
> If I understood correctly, the destructor of `OpenCLProgram`  should do this anyway, hence removed. But if you think otherwise let me know.

Will look at the delete Q. You may be correct. 

Howver, we should not defer testing this until we get to ffi/cpp native code. This is detectable in the Java side way before we get to first kernel dispatch.  

If we go down this rabit hole we are forced to also do this in the CUDA/PTX and all future ffi implementations.

-------------

PR Review Comment: https://git.openjdk.org/babylon/pull/798#discussion_r2655452496