On Wed, May 12, 2021 at 2:18 PM Ida Delphine <idad...@gmail.com> wrote:
>
> Hello everyone,
> Still waiting for some feedback :)
>
> Cheers,
> Ida.
>
> On Mon, 10 May 2021, 5:59 am Ida Delphine, <idad...@gmail.com> wrote:
>>
>> Hello everyone,
>> 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
>>
>> AlignConsecutiveDeclarations: false
>> PointerAlignment: Right
>>
>> Doesn't seem to work.
>> For example in the cpukit/score/src/threadq.c file, something like
>>
>> RTEMS_STATIC_ASSERT(
>> offsetof( Thread_queue_Syslock_queue, Queue.name )
>> == offsetof( struct _Thread_queue_Queue, _name ),
>> THREAD_QUEUE_SYSLOCK_QUEUE_NAME
>> );
>>
>> RTEMS_STATIC_ASSERT(
>> sizeof( Thread_queue_Syslock_queue )
>> == sizeof( struct _Thread_queue_Queue ),
>> THREAD_QUEUE_SYSLOCK_QUEUE_SIZE
>> );
>>
>> #if defined(RTEMS_SMP)
>> void _Thread_queue_Do_acquire_critical(
>> Thread_queue_Control *the_thread_queue,
>> ISR_lock_Context *lock_context
>> )
>> {
>> _Thread_queue_Queue_acquire_critical(
>> &the_thread_queue->Queue,
>> &the_thread_queue->Lock_stats,
>> lock_context
>> );
>>
>> becomes this after using the given configuration
>>
>> RTEMS_STATIC_ASSERT(sizeof(Thread_queue_Syslock_queue) ==
>> sizeof(struct _Thread_queue_Queue),
>> THREAD_QUEUE_SYSLOCK_QUEUE_SIZE);
>>
>> #if defined(RTEMS_SMP)
>> void _Thread_queue_Do_acquire_critical(Thread_queue_Control
>> *the_thread_queue,
>> ISR_lock_Context *lock_context) {
>> _Thread_queue_Queue_acquire_critical(
>> &the_thread_queue->Queue, &the_thread_queue->Lock_stats, lock_context);
>>
>> Everything seems manageable except for this alignment issue...
>> This also throws more light on the changes using clang-format
>> (https://lists.rtems.org/pipermail/devel/2018-December/024145.html)
>>
I think we're willing to concede the pointer alignment. However, it
would be worth spending some time to see if
https://reviews.llvm.org/D27651 can be made to work. The current state
of the code would need to be compared to the patch on that review
board.
Beyond that, documenting the clang-format options to use is next, and
then identifying a plan how to invoke clang-format during a git
workflow is needed.
>> On Thu, May 6, 2021 at 8:05 PM Joel Sherrill <j...@rtems.org> wrote:
>>>
>>>
>>>
>>> On Thu, May 6, 2021 at 12:47 PM Christian Mauderer <o...@c-mauderer.de>
>>> wrote:
>>>>
>>>> Hello Ida and Gedare,
>>>>
>>>> On 06/05/2021 06:26, Gedare Bloom wrote:
>>>> > hi Ida,
>>>> >
>>>> > On Wed, May 5, 2021 at 3:21 PM Ida Delphine <idad...@gmail.com> wrote:
>>>> >>
>>>> >> Hello everyone,
>>>> >>
>>>> >> Regarding this project (https://devel.rtems.org/ticket/3860) 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.
>>>> >> Please will love to know the best option.
>>>> >>
>>>> > We will likely need to consider our choices carefully. If we can find
>>>> > a suitably close style that is already well-supported by clang, and
>>>> > get consensus from the maintainers on a change, then that might be the
>>>> > best route forward.
>>>>
>>>> +1
>>>>
>>>> > I think the first thing to do is take the examples
>>>> > that have been shown by Sebastian that are "close" but not quite
>>>> > perfect, and identify the cases where they differ with RTEMS style in
>>>> > order to present for discussion here. If consensus can't be reached to
>>>> > change the style, then we would need to have a plan for how to improve
>>>> > the existing tools for what we have.
>>>>
>>>> I also found the following tool quite useful to play with the clang
>>>> style config:
>>>>
>>>> https://zed0.co.uk/clang-format-configurator/
>>>>
>>>> Maybe it can help a bit to find out what certain options mean.
>>>>
>>>> >
>>>> > However, I think there is interest in doing less work on the tool
>>>> > side, and more work on how to integrate it into our workflows better.
>>>>
>>>> +1
>>>
>>>
>>> I agree with all of this from the student perspective. But we will have
>>> to come to some agreement on a machine producible format to
>>> be able to use the integration. A report on what doesn't match would
>>> give us something to chew on while Ida works the integration.
>>>
>>> --joel
>>>>
>>>>
>>>> >
>>>> >> Cheers,
>>>> >> Ida.
>>>> >> _______________________________________________
>>>> >> devel mailing list
>>>> >> devel@rtems.org
>>>> >> http://lists.rtems.org/mailman/listinfo/devel
>>>> > _______________________________________________
>>>> > devel mailing list
>>>> > devel@rtems.org
>>>> > http://lists.rtems.org/mailman/listinfo/devel
>>>> >
>>>> _______________________________________________
>>>> devel mailing list
>>>> devel@rtems.org
>>>> http://lists.rtems.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
