2019-11-28 12:44:24 +01:00
|
|
|
|
#!/bin/bash
|
|
|
|
|
|
2020-02-25 12:11:42 +01:00
|
|
|
|
set -e
|
|
|
|
|
|
|
|
|
|
# Wrap everything in a subshell so we can propagate the exit status.
|
2023-11-29 00:43:33 +01:00
|
|
|
|
exit_status=0
|
2020-02-25 12:11:42 +01:00
|
|
|
|
(
|
2019-11-28 12:44:24 +01:00
|
|
|
|
|
2021-01-11 17:03:34 +01:00
|
|
|
|
source .gitlab-ci/search-common-ancestor.sh
|
2020-07-25 01:36:33 +02:00
|
|
|
|
|
2023-10-17 11:13:50 +02:00
|
|
|
|
git diff -U0 --no-color "${newest_common_ancestor_sha}" | .gitlab-ci/clang-format-diff.py -binary "clang-format-14" -p1
|
2020-01-16 14:48:33 +01:00
|
|
|
|
|
2023-11-29 00:43:33 +01:00
|
|
|
|
) || exit_status=$?
|
2020-02-25 12:11:42 +01:00
|
|
|
|
|
2020-01-16 14:48:33 +01:00
|
|
|
|
# The style check is not infallible. The clang-format configuration cannot
|
|
|
|
|
# perfectly describe GLib’s coding style: in particular, it cannot align
|
|
|
|
|
# function arguments. The documented coding style for GLib takes priority over
|
|
|
|
|
# clang-format suggestions. Hopefully we can eventually improve clang-format to
|
|
|
|
|
# be configurable enough for our coding style. That’s why this CI check is OK
|
|
|
|
|
# to fail: the idea is that people can look through the output and ignore it if
|
|
|
|
|
# it’s wrong. (That situation can also happen if someone touches pre-existing
|
|
|
|
|
# badly formatted code and it doesn’t make sense to tidy up the wider coding
|
|
|
|
|
# style with the changes they’re making.)
|
|
|
|
|
echo ""
|
|
|
|
|
echo "Note that clang-format output is advisory and cannot always match the GLib coding style, documented at"
|
2021-06-07 14:16:50 +02:00
|
|
|
|
echo " https://gitlab.gnome.org/GNOME/gtk/blob/HEAD/docs/CODING-STYLE.md"
|
2020-01-16 14:48:33 +01:00
|
|
|
|
echo "Warnings from this tool can be ignored in favour of the documented coding style,"
|
|
|
|
|
echo "or in favour of matching the style of existing surrounding code."
|
2020-02-25 12:11:42 +01:00
|
|
|
|
|
|
|
|
|
exit ${exit_status}
|