<div dir="ltr"><div>Hi Gedare,</div><div><br></div><div>With regards to your comment on discord on me looking for a tool that works on both patches and source files, it turns out clang-format has that functionality already. Here's what I found - <a href="https://clang.llvm.org/docs/ClangFormat.html#script-for-patch-reformatting">https://clang.llvm.org/docs/ClangFormat.html#script-for-patch-reformatting</a></div><div><br></div><div>Does it match what you have in mind?<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 13, 2021 at 3:49 PM Gedare Bloom <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, May 12, 2021 at 2:18 PM Ida Delphine <<a href="mailto:idadelm@gmail.com" target="_blank">idadelm@gmail.com</a>> wrote:<br>
><br>
> Hello everyone,<br>
> Still waiting for some feedback :)<br>
><br>
> Cheers,<br>
> Ida.<br>
><br>
> On Mon, 10 May 2021, 5:59 am Ida Delphine, <<a href="mailto:idadelm@gmail.com" target="_blank">idadelm@gmail.com</a>> wrote:<br>
>><br>
>> Hello everyone,<br>
>> Went through some previous emails and it turns out Sebastian already came up with a configuration for clang format which works well for RTEMS except for the fact that some configurations haven't been implemented into clang-format yet. Using<br>
>><br>
>> AlignConsecutiveDeclarations: false<br>
>> PointerAlignment: Right<br>
>><br>
>> Doesn't seem to work.<br>
>> For example in the cpukit/score/src/threadq.c file, something like<br>
>><br>
>> RTEMS_STATIC_ASSERT(<br>
>> offsetof( Thread_queue_Syslock_queue, Queue.name )<br>
>> == offsetof( struct _Thread_queue_Queue, _name ),<br>
>> THREAD_QUEUE_SYSLOCK_QUEUE_NAME<br>
>> );<br>
>><br>
>> RTEMS_STATIC_ASSERT(<br>
>> sizeof( Thread_queue_Syslock_queue )<br>
>> == sizeof( struct _Thread_queue_Queue ),<br>
>> THREAD_QUEUE_SYSLOCK_QUEUE_SIZE<br>
>> );<br>
>><br>
>> #if defined(RTEMS_SMP)<br>
>> void _Thread_queue_Do_acquire_critical(<br>
>> Thread_queue_Control *the_thread_queue,<br>
>> ISR_lock_Context *lock_context<br>
>> )<br>
>> {<br>
>> _Thread_queue_Queue_acquire_critical(<br>
>> &the_thread_queue->Queue,<br>
>> &the_thread_queue->Lock_stats,<br>
>> lock_context<br>
>> );<br>
>><br>
>> becomes this after using the given configuration<br>
>><br>
>> RTEMS_STATIC_ASSERT(sizeof(Thread_queue_Syslock_queue) ==<br>
>> sizeof(struct _Thread_queue_Queue),<br>
>> THREAD_QUEUE_SYSLOCK_QUEUE_SIZE);<br>
>><br>
>> #if defined(RTEMS_SMP)<br>
>> void _Thread_queue_Do_acquire_critical(Thread_queue_Control *the_thread_queue,<br>
>> ISR_lock_Context *lock_context) {<br>
>> _Thread_queue_Queue_acquire_critical(<br>
>> &the_thread_queue->Queue, &the_thread_queue->Lock_stats, lock_context);<br>
>><br>
>> Everything seems manageable except for this alignment issue...<br>
>> This also throws more light on the changes using clang-format (<a href="https://lists.rtems.org/pipermail/devel/2018-December/024145.html" rel="noreferrer" target="_blank">https://lists.rtems.org/pipermail/devel/2018-December/024145.html</a>)<br>
>><br>
I think we're willing to concede the pointer alignment. However, it<br>
would be worth spending some time to see if<br>
<a href="https://reviews.llvm.org/D27651" rel="noreferrer" target="_blank">https://reviews.llvm.org/D27651</a> can be made to work. The current state<br>
of the code would need to be compared to the patch on that review<br>
board.<br>
<br>
Beyond that, documenting the clang-format options to use is next, and<br>
then identifying a plan how to invoke clang-format during a git<br>
workflow is needed.<br>
<br>
>> On Thu, May 6, 2021 at 8:05 PM Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>> wrote:<br>
>>><br>
>>><br>
>>><br>
>>> On Thu, May 6, 2021 at 12:47 PM Christian Mauderer <<a href="mailto:oss@c-mauderer.de" target="_blank">oss@c-mauderer.de</a>> wrote:<br>
>>>><br>
>>>> Hello Ida and Gedare,<br>
>>>><br>
>>>> On 06/05/2021 06:26, Gedare Bloom wrote:<br>
>>>> > hi Ida,<br>
>>>> ><br>
>>>> > On Wed, May 5, 2021 at 3:21 PM Ida Delphine <<a href="mailto:idadelm@gmail.com" target="_blank">idadelm@gmail.com</a>> wrote:<br>
>>>> >><br>
>>>> >> Hello everyone,<br>
>>>> >><br>
>>>> >> Regarding this project (<a href="https://devel.rtems.org/ticket/3860" rel="noreferrer" target="_blank">https://devel.rtems.org/ticket/3860</a>) I went with clang-format as we all agreed. I have tested it on some "score" files and it made some changes which I don't think are very much in line with the RTEMS coding style. However, it wasn't really clear if we will chage the RTEMS coding style or try to make changes to clang-format to fit the style.<br>
>>>> >> Please will love to know the best option.<br>
>>>> >><br>
>>>> > We will likely need to consider our choices carefully. If we can find<br>
>>>> > a suitably close style that is already well-supported by clang, and<br>
>>>> > get consensus from the maintainers on a change, then that might be the<br>
>>>> > best route forward.<br>
>>>><br>
>>>> +1<br>
>>>><br>
>>>> > I think the first thing to do is take the examples<br>
>>>> > that have been shown by Sebastian that are "close" but not quite<br>
>>>> > perfect, and identify the cases where they differ with RTEMS style in<br>
>>>> > order to present for discussion here. If consensus can't be reached to<br>
>>>> > change the style, then we would need to have a plan for how to improve<br>
>>>> > the existing tools for what we have.<br>
>>>><br>
>>>> I also found the following tool quite useful to play with the clang<br>
>>>> style config:<br>
>>>><br>
>>>> <a href="https://zed0.co.uk/clang-format-configurator/" rel="noreferrer" target="_blank">https://zed0.co.uk/clang-format-configurator/</a><br>
>>>><br>
>>>> Maybe it can help a bit to find out what certain options mean.<br>
>>>><br>
>>>> ><br>
>>>> > However, I think there is interest in doing less work on the tool<br>
>>>> > side, and more work on how to integrate it into our workflows better.<br>
>>>><br>
>>>> +1<br>
>>><br>
>>><br>
>>> I agree with all of this from the student perspective. But we will have<br>
>>> to come to some agreement on a machine producible format to<br>
>>> be able to use the integration. A report on what doesn't match would<br>
>>> give us something to chew on while Ida works the integration.<br>
>>><br>
>>> --joel<br>
>>>><br>
>>>><br>
>>>> ><br>
>>>> >> Cheers,<br>
>>>> >> Ida.<br>
>>>> >> _______________________________________________<br>
>>>> >> devel mailing list<br>
>>>> >> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
>>>> >> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
>>>> > _______________________________________________<br>
>>>> > devel mailing list<br>
>>>> > <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
>>>> > <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
>>>> ><br>
>>>> _______________________________________________<br>
>>>> devel mailing list<br>
>>>> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
>>>> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
</blockquote></div>