.clang-format: Add default clang-format configuration

[maribu]

Contribution description

This adds a clang-format configuration based on the Linux Kernel configuration and modified to better match RIOT's coding convention.

Testing procedure

Automatic formatting using clang-format should now match RIOT's coding convention relatively closely. Aligning bitmasks is still a pain point, though. I think this is not yet possible to configure, but something that we don't have too often. E.g. the following would still not work

/* good */
   FOO_REG = FOO_REG_VAL1
           | FOO_REG_VAL2
           | FOO_REG_VAL3;

/* bad (but sadly currently generated by clang-format) */
   FOO_REG = FOO_REG_VAL1 |
       FOO_REG_VAL2 | FOO_REG_VAL3;

Issues/PRs references

None

[maribu]

Would be interesting to know whether this would result (except for bitmasks) in correctly formatted code when using VS code.

[riot-ci]

Murdock results

✔️ PASSED

e7c91fa .clang-format: Add default clang-format configuration

Success	Failures	Total	Runtime
10214	0	10215	15m:14s

Artifacts

• Documentation preview

[mguetschow]

Nice one, thank you! I can confirm that VSCode now formats code according to our coding convention 🎉

Just some minor proposals below.

[mguetschow]

Unfortunately, this also seems to include the header guard, adding an extra level of indentation in all header files :/

[mguetschow]

Correction: The include guards are recognized correctly if the corresponding #endif directive is the last line of the file (and not the documentation group closing /** @} */), is that the recommended order anyway?

[maribu]

Yes, it is generally expected that the include guard is the first and last thing in a header. I think this will also trigger the optimisation in the preprocessor to operate faster.

[mguetschow]

I see. I've just checked and there currently are a lot of places where the order is switched. I'll try to fix them, maybe we even get some build time improvements?

[maribu]

There could be an improvement, but probably in the order of noise :)

You could also go for #pragma once now that there seems to be an agreement that this is an acceptable instance of using GCC and clang features that go beyond thr standard.

[mguetschow]

You could also go for #pragma once now that there seems to be an agreement that this is an acceptable instance of using GCC and clang features that go beyond thr standard.

But that would be against the coding convention (and the static tests) that explicitly ask for the include guards. So I went with #20905 now.

[mguetschow]

After some manual testing with VSCode, I'd say this is ready to go. If problems showed up in the future, we could still adapt the configuration then.

[mguetschow]

@maribu squash needed :)