Code Formatting and Style Check for RTEMS score

[Christian Mauderer]

Introduction

For the core parts of RTEMS the coding style is defined in the documentation (​https://docs.rtems.org/branches/master/eng/coding-conventions.html). But there is no automatic checking. Therefore for people new to RTEMS it can get tricky to get it right when sending patches.

The RTEMS score format is specific to this project and a formatter needs to be taught how to handle the format.

Project

This project should improve the situation and work towards automatic stle and formatting checking for RTEMS score.

Tasks

• Find a code checker or formater that can produce results that match the RTEMS coding conventions. Some tools have been discussed on the list or described in the wiki in the past. But a new tool is possible too.
• If necessary create a configuration for the code checker (most likely it is necessary).
• Make sure the tool works on all mayor development platforms for RTEMS (Linux, FreeBSD, Windows, MacOS).
• If necessary: Integrate the tool into rtems-source-builder.
• Add a build target for automatic code checking.

Prerequisites

• Knowledge of C and (most likely) Python programming languages.
• Knowledge of host software and building packages.
• Access to test systems for the development platforms (at least two to three of them).

Possible Hurdles

• The existing code isn't entirely consistent. Discussions are necessary whether these inconsistencies should be patched.
• Maybe some style discussions will be started.
• During this project we need to define a test threshold a change made by a formatter has to pass before it is posted for review. For example builds with out the introduction of warnings, no regression in the tests, etc

Both points could lead to long discussions. But don't hesitate: The mentor of the project will help with them.

[Gedare Bloom]

This was mostly done, need to follow-up and integrate.

[Gedare Bloom]

I'm going to tag style reformats with this ticket. More plans forthcoming soon.

[Gedare Bloom]

There is a bug to fix for the current clang-format to be usable as-is: ​https://github.com/llvm/llvm-project/issues/54808

[Gedare Bloom]

Another remaining open problem is: Do we have an easy mechanical way to identify third party code?

One suggestion for handling this is:
I would like to see this as a waf target and so handled by the build system. We
could look at something in the spec files or a simple rtems-formatting in a
directory. If the file exists the contents could be some form of regx to include
or exclude and if not present it is include *. The parent applies to child
directories until overridden?

I'm going to look into it further.