fix linking for several extension APIs and enums (#1360)

Author: bashbaug

api/cl_ext_buffer_device_address.asciidoc

@@ -18,7 +18,7 @@ include::{generated}/meta/{refprefix}cl_ext_buffer_device_address.txt[]
 
 === Description
 
-This extension provides access to raw device pointers for cl_mem buffers
+This extension provides access to raw device pointers for {cl_mem_TYPE} buffers
 without requiring a shared virtual address space between the host and
 the device.
 
@@ -67,14 +67,14 @@ can allocate.
   ** Initial version for detailed review.
   * Revision 1.0.1, 2025-01-28
   ** Made it explicit that passing illegal pointers is legal as long as they are
-     not referenced. Removed CL_INVALID_ARG_VALUE as a possible error in
-     clSetKernelArgDevicePointerEXT() as there are no illegal pointer
-     cases when calling this function. Return CL_INVALID_OPERATION for
-     clGetMemObjectInfo() if the pointer is not a buffer device pointer.
-     clSetKernelExecInfo() and clSetKernelArgDevicePointerEXT() now only
+     not referenced. Removed {CL_INVALID_ARG_VALUE} as a possible error in
+     {clSetKernelArgDevicePointerEXT} as there are no illegal pointer
+     cases when calling this function. Return {CL_INVALID_OPERATION} for
+     {clGetMemObjectInfo} if the pointer is not a buffer device pointer.
+     {clSetKernelExecInfo} and {clSetKernelArgDevicePointerEXT} now only
      error out if no devices in the context associated with kernel support
      device pointers.
   * Revision 1.0.2, 2025-02-04
-  ** Converted the clSetKernelArgDevicePointerEXT() address parameter to
+  ** Converted the {clSetKernelArgDevicePointerEXT} address parameter to
      a value instead of a pointer to the value.
 

api/cl_ext_image_from_buffer.asciidoc

@@ -45,13 +45,13 @@ object.
 
 //. TODO Test copy to/from another image?
 
-. Test clGetImageInfo
+. Test {clGetImageInfo}
   - For all image types (one format per element size)
   - For a few different row/pitch sizes (image dimensions being equal or not)
     - Create an image from a buffer
     - Check that the returned values for {CL_IMAGE_ROW_PITCH} and {CL_IMAGE_SLICE_PITCH} are correct.
 
-. Test clGetMemObjectInfo
+. Test {clGetMemObjectInfo}
   - For all image types (1 format only)
     - Create an image from a buffer
     - Check that {CL_MEM_ASSOCIATED_MEMOBJECT} correctly returns the buffer that was used.

api/cl_khr_gl_sharing.asciidoc

@@ -96,7 +96,7 @@ an arbitrary OpenGL or OpenGL ES context with respect to one of the
 window-system binding layers EGL, GLX, or WGL, or a share group handle to
 identify a CGL share group.
 If a context is specified, it need not be current to the thread calling
-clCreateContext*.
+{clCreateContext}.
 
 A previously suggested approach would use a single boolean attribute
 CL_USE_GL_CONTEXT_KHR to allow creating a context associated with the
@@ -168,8 +168,8 @@ Sharing between OpenCL and OpenGL requires integration at the driver
 internals level.
 --
 
-  . What command-queues can *clEnqueueAcquire/ReleaseGLObjects* be placed
-    on?
+  . What command-queues can {clEnqueueAcquireGLObjects} and
+    {clEnqueueReleaseGLObjects} be placed on?
 +
 --
 *RESOLVED*: All command-queues.
@@ -221,7 +221,7 @@ All extension language has now been integrated into the unified
 Specification and this distinction is not useful.
 --
 
-  . Where are the `clCreateFromGLTexture2D` and `clCreateFromGLTexture3D`
+  . Where are the {clCreateFromGLTexture2D} and {clCreateFromGLTexture3D}
     fuctions described?
 +
 --

api/cl_khr_icd.asciidoc

@@ -73,7 +73,7 @@ New in version 2.0.0, object that are ICD 2 compatible should also contain
 a `dispatch_data` field of type `void *` that the loader is free to modify
 for a platform through the {clIcdSetPlatformDispatchDataKHR} new API entry
 point. In order to distinguish ICD 1 and ICD 2 objects, the pointers to
-`clGetPlatformIDs` and `clUnloadCompiler` in the dispatch structure must be
+{clGetPlatformIDs} and {clUnloadCompiler} in the dispatch structure must be
 set to `CL_ICD2_TAG_KHR`. The vendor driver is responsible for propagating
 the `dispatch_data` value when returning objects to users.
 
@@ -242,7 +242,7 @@ continue on to the next.
 New in version 2.0.0, the ICD Loader will also query the following functions
 from the library: {clIcdGetFunctionAddressForPlatformKHR} and
 {clIcdSetPlatformDispatchDataKHR}. If these two functions are present and the
-pointers to `clGetPlatformIDs` and `clUnloadCompiler` in the dispatch
+pointers to {clGetPlatformIDs} and {clUnloadCompiler} in the dispatch
 structure of a platform is set to `CL_ICD2_TAG_KHR` the platform will be
 deemed ICD 2 compatible and dispatch will be managed by the ICD Loader. If the
 `CL_ICD2_TAG_KHR` tag is present but one of the two functions above is
@@ -274,8 +274,8 @@ Returned by {clGetPlatformIDs} when no platforms are found:
 
   * {CL_PLATFORM_NOT_FOUND_KHR}
 
-New in version 2.0.0, used as a value in the pointers to `clGetPlatformIDs`
-and `clUnloadCompiler` in the dispatch structure:
+New in version 2.0.0, used as a value in the pointers to {clGetPlatformIDs}
+and {clUnloadCompiler} in the dispatch structure:
 
   * `CL_ICD2_TAG_KHR`
 

api/cl_khr_spirv_linkonce_odr.asciidoc

@@ -12,7 +12,7 @@ include::{generated}/meta/{refprefix}cl_khr_spirv_linkonce_odr.txt[]
 
 === Description
 
-`cl_khr_spirv_linkonce_odr` allows use of the SPIR-V extension
+The {cl_khr_spirv_linkonce_odr_EXT} extension allows use of the SPIR-V extension
 `SPV_KHR_linkonce_odr`.
 
 See the