Feature Request: Add a compact style for `ccall`-wrapper functions

[Gnimuc]

By default, Clang.jl will simply generate 3-line-ccall-wrapper functions like:

@checked function zeDriverGetIpcProperties(hDriver, pIpcProperties)
    ccall((:zeDriverGetIpcProperties, libze_loader), ze_result_t, (ze_driver_handle_t, Ptr{ze_driver_ipc_properties_t}), hDriver, pIpcProperties)
end

@maleadt implemented an indenting pass which can format the code above in a style of:

@checked function zeDriverGetIpcProperties(hDriver, pIpcProperties)
    ccall((:zeDriverGetIpcProperties, libze_loader), ze_result_t,
          (ze_driver_handle_t, Ptr{ze_driver_ipc_properties_t}),
          hDriver, pIpcProperties)
end

I believe this functionality should live in this repo, so more Clang.jl users can take advantage of this.

[domluna]

The indentation looks to be in line with YASStyle, have you tried that?

https://domluna.github.io/JuliaFormatter.jl/dev/yas_style/

[Gnimuc]

That looks close but the above-proposed style always switches to a new line after the end of ccall's third argument. Also, the unnecessary return looks a little bit redundant.

@checked function zeDriverGetIpcProperties(hDriver, pIpcProperties)
    return ccall((:zeDriverGetIpcProperties, libze_loader), ze_result_t,
                 (ze_driver_handle_t, Ptr{ze_driver_ipc_properties_t}), hDriver,
                 pIpcProperties)
end

[domluna]

by default YASStyle sets always_use_return to true, you can override that arg to false

i.e. format(..., YASSyle(), always_use_return=false) or format_text

the third argument thing is based on the margin arg which is 92 spaces by default

[Gnimuc]

That's great! Just wanna confirm, what's the right way to set this wrap_at_comma behavior in JuliaFormatter?

[domluna]

I think that's doing the same thing as if you did margin=92 (which is the default value for margin)

[Gnimuc]

Here are more examples that demonstrate the wrap_at_comma behavior(more accurately, it's wrap_at_the_third_argument):

@checked function zeContextCreateEx(hDriver, desc, numDevices, phDevices, phContext)
    ccall((:zeContextCreateEx, libze_loader), ze_result_t,
          (ze_driver_handle_t, Ptr{ze_context_desc_t}, UInt32, Ptr{ze_device_handle_t},
           Ptr{ze_context_handle_t}),
          hDriver, desc, numDevices, phDevices, phContext)
end

@checked function zeContextDestroy(hContext)
    ccall((:zeContextDestroy, libze_loader), ze_result_t,
          (ze_context_handle_t,),
          hContext)
end

@checked function zeContextGetStatus(hContext)
    ccall((:zeContextGetStatus, libze_loader), ze_result_t,
          (ze_context_handle_t,),
          hContext)
end

But I think it's fine to just use YASSyle without return. Feel free to close this if you think it's not necessary to add this behavior. :)

[maleadt]

FWIW, the reason I added this is to make it easier to match up the arguments with the tuple of types, so pretty niche :-) It would probably be better to switch to the @ccall form, which pairs each argument with its C type.

[domluna]

yeah it just looks like the heuristic of when to break the lines is slightly different

[Gnimuc]

This is the result of using @ccall with format(..., YASSyle(), always_use_return=false):

@checked function zeCommandListAppendMemoryCopy(hCommandList, dstptr, srcptr, size,
                                                hSignalEvent, numWaitEvents, phWaitEvents)
    @ccall libze_loader.zeCommandListAppendMemoryCopy(hCommandList::ze_command_list_handle_t,
                                                      dstptr::PtrOrZePtr{Cvoid},
                                                      srcptr::PtrOrZePtr{Cvoid},
                                                      size::Csize_t,
                                                      hSignalEvent::ze_event_handle_t,
                                                      numWaitEvents::UInt32,
                                                      phWaitEvents::Ptr{ze_event_handle_t})::ze_result_t
end

@checked function zeCommandListAppendMemoryFill(hCommandList, ptr, pattern, pattern_size,
                                                size, hSignalEvent, numWaitEvents,
                                                phWaitEvents)
    @ccall libze_loader.zeCommandListAppendMemoryFill(hCommandList::ze_command_list_handle_t,
                                                      ptr::PtrOrZePtr{Cvoid},
                                                      pattern::PtrOrZePtr{Cvoid},
                                                      pattern_size::Csize_t, size::Csize_t,
                                                      hSignalEvent::ze_event_handle_t,
                                                      numWaitEvents::UInt32,
                                                      phWaitEvents::Ptr{ze_event_handle_t})::ze_result_t
end

@domluna any suggestions on which style/configuration should be used here?

As the auto-generated code may result in a very large file, I think the result should look something like this:

@checked function zeCommandListAppendMemoryFill(hCommandList, ptr, pattern, pattern_size, size, hSignalEvent, numWaitEvents, phWaitEvents)
    @ccall libze_loader.zeCommandListAppendMemoryFill(
        hCommandList::ze_command_list_handle_t, ptr::PtrOrZePtr{Cvoid}, pattern::PtrOrZePtr{Cvoid},
        pattern_size::Csize_t, size::Csize_t, hSignalEvent::ze_event_handle_t, numWaitEvents::UInt32,
        phWaitEvents::Ptr{ze_event_handle_t})::ze_result_t
end

1. The argument names in the function signature are the same as those in the @ccall-function signature below, so there is no need to do the wrap for the first line.
2. The first line of the function body consists of @ccall + a library loader expression + a C function name.
3. The remaining function argument-annotation pairs should be as compact as possible.

[domluna]

YAS is the closest but it aligns things to after the opening (. The other styles might put each arg on a single line depending on the margin.

Sounds like something that has Default or Blue style indentation with YAS style nesting could be close to what you're looking for

[penelopeysm]

I think it's too much to have special-cased rules for specific functions. Sorry, the codebase is already complex enough.