1
1
mirror of https://gitlab.gnome.org/GNOME/gimp.git synced 2025-10-05 21:02:42 +02:00

8 Commits

Author SHA1 Message Date
Jehan
4ec3268c78 clang-format: uncomment rule not usable yet.
BinPackParameters is looking for a boolean right now, which was changed
to the enum we were using, but only for LLVM 20 (not yet available in
our CI). Comment this line for now.

Fixes failure in "clang-format" job in CI:

> Debian clang-format version 14.0.6
> /builds/GNOME/gimp/.clang-format:22:20: error: invalid boolean
> BinPackParameters: AlwaysOnePerLine
>                    ^~~~~~~~~~~~~~~~
> Error reading /builds/GNOME/gimp/.clang-format: Invalid argument

See: https://github.com/llvm/llvm-project/issues/117830
2025-04-30 23:36:15 +02:00
Ondřej Míchal
e6bef93d73 .clang-format: Adjust bin-packing of parameters and arguments
As per GIMP's style documentation [0]:

- put function parameters on their own lines,
- pack function arguments to fit line and only then wrap.

[0] https://developer.gimp.org/core/coding_style/
2025-04-29 21:39:18 +03:00
Rupert
84a501f516 clang-format update
- Add Alignment for bitfields.
- BreakBefore*Operators: adhere to GIMP Coding Style.
- Align... AcrossComments: allows section comments in long lists w/o
  disturbing alignment (e.g. the struct at top of bmp-load.c). Alignment
  can still be reset with a newline.
2025-01-05 13:27:47 +01:00
Joachim Priesner
2680057b96 .clang-format: Remove duplicate option
This is an error starting with LLVM commit 388d679c (LLVM 17).
2024-02-21 15:44:48 +00:00
Joachim Priesner
6731761944 .clang-format: Enable PenaltyBreakOpenParenthesis option
The CI uses clang-format 14 at least since commit 01e56545,
since that is the version available in Debian bookworm.
2024-02-21 11:27:27 +00:00
Jehan
2d0ece6a03 clang-format: update.
I tested it against various merge requests and the more I go, the more I
wonder if it will ever be *really* useful. It detects so many false
positive of totally acceptable code. I tweak the style rules, improve
some things but then make other things worse.

Actually the logic of having one "best" case with the penalty system is
flawed IMO. We should really have rules of what is acceptable and should
not trigger changes vs. what is not acceptable styling.
For instance what such a system cannot detect is when we organize some
things on purpose, for instance for semantic reasons. If it's just "best
rule" based, it cannot work, but with an "acceptable style" logic, the
on-purpose organization of code will just pass as long as it doesn't
break the coding style.

Anyway let's see…
2022-03-14 18:16:14 +01:00
Jehan
3d97a408ea clang-format: improve according to our coding style.
- Align macro values.
- Align backslashes to escape newlines.
- Added explicit PointerAlignment though this one seems unneeded.
- Increase the column limit (even though 80 is really the official one)
  and add some penalty on breaking on very unexpected places, such as
  around assignments or on first parameters in calls/declaration. We
  want short lines but this is more of a soft rule which should not
  override sensible line breaking rules.
- Group some rules and reorder rule names alphabetically within groups.
2022-01-19 23:17:23 +01:00
Asa
9385a6405a .gitlab-ci.yml: add clang-format rules and pipeline
Fixes #950

`.gitlab/search-common-ancestor.sh`'s original authors are
Philip Withnall and Frederic Martinsons.
(Jehan/reviewer's note: script further improved by Asalle)
2022-01-19 20:44:45 +00:00