{"thread":{"id":"61750","subject":"[PATCH 0/8] clang-format: add more rules and enable on CI","startedAt":"2024-07-08T09:23:30Z","lastAt":"2025-06-20T00:02:19Z","messageCount":127,"participants":["Karthik Nayak","Chris Torek","Georg Pfuetzenreuter","Junio C Hamano","Justin Tobler","Eric Sunshine","brian m. carlson","Phillip Wood","phillip.wood123@gmail.com","Ramsay Jones","Patrick Steinhardt"],"isPatch":true,"patchVersion":1,"patchTotal":8},"messages":[{"id":"498220","messageId":"20240708092317.267915-1-karthik.188@gmail.com","threadId":"61750","inReplyTo":null,"subject":"[PATCH 0/8] clang-format: add more rules and enable on CI","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-08T09:23:08Z","receivedAt":"2024-07-08T09:23:30Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"The series was mostly inspired by a patch sent recently to 'include\nkh_foreach* macros in ForEachMacros' [1]. I was wondering why we don't\nrun the formatting on CI and reduce some of the workload of reviewers.\n\nWe have a '.clang-format' file to provide rules for code formatting.\nThe commits 1-6 aims to add more rules to the file while deprecating old\nones.\n\nCommit 7 enables CI action on GitHub and GitLab to also check for the\ncode formatting. Currently, it is allowed to fail. This way we can build\nconfidence and fine tune the values as needed and finally enforce the\ncheck in a future patch. I'm not well versed with GitHub workflows, and\nI mostly tried to copy existing work there. Expecting some feedback in\nthat section!\n\nCommit 8 fixes an existing issue with the 'check-whitespace' job, which\nis failing as success in the GitLab CI.\n\n1: https://lore.kernel.org/git/4e7893f5-2dd9-46cf-8a64-cf780f4e1730@web.de/\n\nKarthik Nayak (8):\n clang-format: indent preprocessor directives after hash\n clang-format: avoid spacing around bitfield colon\n clang-format: ensure files end with newlines\n clang-format: replace deprecated option with 'SpacesInParens'\n clang-format: avoid braces on simple single-statement bodies\n clang-format: formalize some of the spacing rules\n ci: run style check on GitHub and GitLab\n check-whitespace: detect if no base_commit is provided\n\n .clang-format | 41 +++++++++++++++++++++++++++----\n .github/workflows/check-style.yml | 29 ++++++++++++++++++++++\n .gitlab-ci.yml | 14 ++++++++++-\n ci/check-whitespace.sh | 13 +++++++---\n ci/install-dependencies.sh | 2 +-\n ci/run-style-check.sh | 8 ++++++\n 6 files changed, 97 insertions(+), 10 deletions(-)\n create mode 100644 .github/workflows/check-style.yml\n create mode 100755 ci/run-style-check.sh\n\n-- \n2.45.1\n\n"},{"id":"498221","messageId":"20240708092317.267915-2-karthik.188@gmail.com","threadId":"61750","inReplyTo":"20240708092317.267915-1-karthik.188@gmail.com","subject":"[PATCH 1/8] clang-format: indent preprocessor directives after hash","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-08T09:23:09Z","receivedAt":"2024-07-08T09:23:30Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"We do not have a rule around the indentation of preprocessor directives.\nThis was also discussed on the list [1], noting how there is often\ninconsistency in the styling. While there was discussion, there was no\nconclusion around what is the preferred style here. One style being\nindenting after the hash:\n\n #if FOO\n # if BAR\n # include \n # endif\n #endif\n\nThe other being before the hash:\n\n #if FOO\n #if BAR\n #include \n #endif\n #endif\n\nLet's pick the former and add 'IndentPPDirectives: AfterHash' value to\nour '.clang-format'. There is no clear reason to pick one over the\nother, but it would definitely be nicer to be consistent.\n\n[1]: https://lore.kernel.org/r/xmqqwmmm1bw6.fsf@gitster.g\n\nSigned-off-by: Karthik Nayak \n---\n .clang-format | 6 ++++++\n 1 file changed, 6 insertions(+)\n\ndiff --git a/.clang-format b/.clang-format\nindex 3ed4fac753..5e128519bf 100644\n--- a/.clang-format\n+++ b/.clang-format\n@@ -96,6 +96,12 @@ BreakStringLiterals: false\n # Switch statement body is always indented one level more than case labels.\n IndentCaseLabels: false\n \n+# Indents directives before the hash.\n+# #if FOO\n+# # include \n+# #endif\n+IndentPPDirectives: AfterHash\n+\n # Don't indent a function definition or declaration if it is wrapped after the\n # type\n IndentWrappedFunctionNames: false\n-- \n2.45.1\n\n"},{"id":"498222","messageId":"20240708092317.267915-3-karthik.188@gmail.com","threadId":"61750","inReplyTo":"20240708092317.267915-1-karthik.188@gmail.com","subject":"[PATCH 2/8] clang-format: avoid spacing around bitfield colon","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-08T09:23:10Z","receivedAt":"2024-07-08T09:23:32Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"The spacing around colons is currently not standardized and as such we\nhave the following practices in our code base:\n- Spacing around the colon `int bf : 1`: 146 instances\n- No spacing around the colon `int bf:1`: 148 instances\n- Spacing before the colon `int bf :1`: 6 instances\n- Spacing after the colon `int bf: 1`: 12 instances\n\nLet's formalize this by picking the most followed pattern and add the\ncorresponding style to '.clang-format'.\n\nSigned-off-by: Karthik Nayak \n---\n .clang-format | 4 ++++\n 1 file changed, 4 insertions(+)\n\ndiff --git a/.clang-format b/.clang-format\nindex 5e128519bf..803b274dd5 100644\n--- a/.clang-format\n+++ b/.clang-format\n@@ -72,6 +72,10 @@ AlwaysBreakAfterReturnType: None\n BinPackArguments: true\n BinPackParameters: true\n \n+# Add no space around the bit field\n+# unsigned bf:2;\n+BitFieldColonSpacing: None\n+\n # Attach braces to surrounding context except break before braces on function\n # definitions.\n # void foo()\n-- \n2.45.1\n\n"},{"id":"498223","messageId":"20240708092317.267915-4-karthik.188@gmail.com","threadId":"61750","inReplyTo":"20240708092317.267915-1-karthik.188@gmail.com","subject":"[PATCH 3/8] clang-format: ensure files end with newlines","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-08T09:23:11Z","receivedAt":"2024-07-08T09:23:32Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"All our source files end with a newline, let's formalize in\n'.clang-format'.\n\nSigned-off-by: Karthik Nayak \n---\n .clang-format | 3 +++\n 1 file changed, 3 insertions(+)\n\ndiff --git a/.clang-format b/.clang-format\nindex 803b274dd5..4c9751a9db 100644\n--- a/.clang-format\n+++ b/.clang-format\n@@ -106,6 +106,9 @@ IndentCaseLabels: false\n # #endif\n IndentPPDirectives: AfterHash\n \n+# Insert a newline at end of file if missing\n+InsertNewlineAtEOF: true\n+\n # Don't indent a function definition or declaration if it is wrapped after the\n # type\n IndentWrappedFunctionNames: false\n-- \n2.45.1\n\n"},{"id":"498224","messageId":"20240708092317.267915-5-karthik.188@gmail.com","threadId":"61750","inReplyTo":"20240708092317.267915-1-karthik.188@gmail.com","subject":"[PATCH 4/8] clang-format: replace deprecated option with 'SpacesInParens'","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-08T09:23:12Z","receivedAt":"2024-07-08T09:23:33Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"Replace the deprecated options 'SpacesInParentheses' and\n'SpaceInEmptyParentheses' with the newer 'SpacesInParens' option. The\nusage is the same.\n\nSigned-off-by: Karthik Nayak \n---\n .clang-format | 9 ++++-----\n 1 file changed, 4 insertions(+), 5 deletions(-)\n\ndiff --git a/.clang-format b/.clang-format\nindex 4c9751a9db..914254a29b 100644\n--- a/.clang-format\n+++ b/.clang-format\n@@ -134,8 +134,6 @@ SpaceBeforeAssignmentOperators: true\n # }\n SpaceBeforeParens: ControlStatements\n \n-# Don't insert spaces inside empty '()'\n-SpaceInEmptyParentheses: false\n \n # The number of spaces before trailing line comments (// - comments).\n # This does not affect trailing block comments (/* - comments).\n@@ -149,9 +147,10 @@ SpacesInCStyleCastParentheses: false\n # var arr = [1, 2, 3]; not var arr = [ 1, 2, 3 ];\n SpacesInContainerLiterals: false\n \n-# Don't insert spaces after '(' or before ')'\n-# f(arg); not f( arg );\n-SpacesInParentheses: false\n+SpacesInParens: Custom\n+SpacesInParensOptions:\n+ # Don't insert spaces inside empty '()'\n+ InEmptyParentheses: false\n \n # Don't insert spaces after '[' or before ']'\n # int a[5]; not int a[ 5 ];\n-- \n2.45.1\n\n"},{"id":"498225","messageId":"20240708092317.267915-6-karthik.188@gmail.com","threadId":"61750","inReplyTo":"20240708092317.267915-1-karthik.188@gmail.com","subject":"[PATCH 5/8] clang-format: avoid braces on simple single-statement bodies","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-08T09:23:13Z","receivedAt":"2024-07-08T09:23:34Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"Set the 'RemoveBracesLLVM' to 'true' which ensures that we avoid curly\nbraces for single-statement bodies in conditional blocks.\n\nSigned-off-by: Karthik Nayak \n---\n .clang-format | 5 +++++\n 1 file changed, 5 insertions(+)\n\ndiff --git a/.clang-format b/.clang-format\nindex 914254a29b..1a5f0c9046 100644\n--- a/.clang-format\n+++ b/.clang-format\n@@ -117,6 +117,11 @@ IndentWrappedFunctionNames: false\n # int *a;\n PointerAlignment: Right\n \n+# Remove optional braces of control statements (if, else, for, and while)\n+# according to the LLVM coding style\n+# This avoids braces on simple single-statement bodies of statements.\n+RemoveBracesLLVM: true\n+\n # Don't insert a space after a cast\n # x = (int32)y; not x = (int32) y;\n SpaceAfterCStyleCast: false\n-- \n2.45.1\n\n"},{"id":"498226","messageId":"20240708092317.267915-7-karthik.188@gmail.com","threadId":"61750","inReplyTo":"20240708092317.267915-1-karthik.188@gmail.com","subject":"[PATCH 6/8] clang-format: formalize some of the spacing rules","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-08T09:23:14Z","receivedAt":"2024-07-08T09:23:36Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"There are some spacing rules that we follow in the project and it makes\nsen to formalize them:\n* Ensure there is no space inserted after the logical not '!' operator.\n* Ensure there is no space before the case statement's color.\n* Ensure there is no space before the first bracket '[' of an array.\n* Ensure there is no space in empty blocks.\n\nSigned-off-by: Karthik Nayak \n---\n .clang-format | 14 ++++++++++++++\n 1 file changed, 14 insertions(+)\n\ndiff --git a/.clang-format b/.clang-format\nindex 1a5f0c9046..05036f610b 100644\n--- a/.clang-format\n+++ b/.clang-format\n@@ -126,11 +126,18 @@ RemoveBracesLLVM: true\n # x = (int32)y; not x = (int32) y;\n SpaceAfterCStyleCast: false\n \n+# No space is inserted after the logical not operator\n+SpaceAfterLogicalNot: false\n+\n # Insert spaces before and after assignment operators\n # int a = 5; not int a=5;\n # a += 42; a+=42;\n SpaceBeforeAssignmentOperators: true\n \n+# Spaces will be removed before case colon.\n+# case 1: break; not case 1 : break;\n+SpaceBeforeCaseColon: false\n+\n # Put a space before opening parentheses only after control statement keywords.\n # void f() {\n # if (true) {\n@@ -139,6 +146,13 @@ SpaceBeforeAssignmentOperators: true\n # }\n SpaceBeforeParens: ControlStatements\n \n+# No space before first '[' in arrays\n+# int a[5][5]; not int a [5][5];\n+SpaceBeforeSquareBrackets: false\n+\n+# No space will be inserted into {}\n+# while (true) {} not while (true) { }\n+SpaceInEmptyBlock: false\n \n # The number of spaces before trailing line comments (// - comments).\n # This does not affect trailing block comments (/* - comments).\n-- \n2.45.1\n\n"},{"id":"498227","messageId":"20240708092317.267915-8-karthik.188@gmail.com","threadId":"61750","inReplyTo":"20240708092317.267915-1-karthik.188@gmail.com","subject":"[PATCH 7/8] ci: run style check on GitHub and GitLab","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-08T09:23:15Z","receivedAt":"2024-07-08T09:23:36Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"We don't run style checks on our CI, even though we have a\n'.clang-format' setup in the repository. Let's add one, the job will\nvalidate only against the new commits added and will only run on merge\nrequests. Since we're introducing it for the first time, let's allow\nthis job to fail, so we can validate if this is useful and eventually\nenforce it.\n\nSigned-off-by: Karthik Nayak \n---\n .github/workflows/check-style.yml | 29 +++++++++++++++++++++++++++++\n .gitlab-ci.yml | 12 ++++++++++++\n ci/install-dependencies.sh | 2 +-\n ci/run-style-check.sh | 8 ++++++++\n 4 files changed, 50 insertions(+), 1 deletion(-)\n create mode 100644 .github/workflows/check-style.yml\n create mode 100755 ci/run-style-check.sh\n\ndiff --git a/.github/workflows/check-style.yml b/.github/workflows/check-style.yml\nnew file mode 100644\nindex 0000000000..27276dfe5e\n--- /dev/null\n+++ b/.github/workflows/check-style.yml\n@@ -0,0 +1,29 @@\n+name: check-style\n+\n+# Get the repository with all commits to ensure that we can analyze\n+# all of the commits contributed via the Pull Request.\n+\n+on:\n+ pull_request:\n+ types: [opened, synchronize]\n+\n+# Avoid unnecessary builds. Unlike the main CI jobs, these are not\n+# ci-configurable (but could be).\n+concurrency:\n+ group: ${{ github.workflow }}-${{ github.ref }}\n+ cancel-in-progress: true\n+\n+jobs:\n+ check-style:\n+ runs-on: ubuntu-latest\n+ steps:\n+ - uses: actions/checkout@v4\n+ with:\n+ fetch-depth: 0\n+\n+ - name: git clang-format\n+ continue-on-error: true\n+ id: check_out\n+ run: |\n+ ./ci/run-style-check.sh \\\n+ \"${{github.event.pull_request.base.sha}}\"\ndiff --git a/.gitlab-ci.yml b/.gitlab-ci.yml\nindex 37b991e080..65fd261e5e 100644\n--- a/.gitlab-ci.yml\n+++ b/.gitlab-ci.yml\n@@ -123,6 +123,18 @@ check-whitespace:\n rules:\n - if: $CI_PIPELINE_SOURCE == 'merge_request_event'\n \n+check-style:\n+ image: ubuntu:latest\n+ allow_failure: true\n+ variables:\n+ CC: clang\n+ before_script:\n+ - ./ci/install-dependencies.sh\n+ script:\n+ - ./ci/run-style-check.sh \"$CI_MERGE_REQUEST_DIFF_BASE_SHA\"\n+ rules:\n+ - if: $CI_PIPELINE_SOURCE == 'merge_request_event'\n+\n documentation:\n image: ubuntu:latest\n variables:\ndiff --git a/ci/install-dependencies.sh b/ci/install-dependencies.sh\nindex 6ec0f85972..46fe12a690 100755\n--- a/ci/install-dependencies.sh\n+++ b/ci/install-dependencies.sh\n@@ -43,7 +43,7 @@ ubuntu-*)\n \t\tmake libssl-dev libcurl4-openssl-dev libexpat-dev wget sudo default-jre \\\n \t\ttcl tk gettext zlib1g-dev perl-modules liberror-perl libauthen-sasl-perl \\\n \t\tlibemail-valid-perl libio-pty-perl libio-socket-ssl-perl libnet-smtp-ssl-perl libdbd-sqlite3-perl libcgi-pm-perl \\\n-\t\t${CC_PACKAGE:-${CC:-gcc}} $PYTHON_PACKAGE\n+\t\t${CC_PACKAGE:-${CC:-gcc}} $PYTHON_PACKAGE clang-format\n \n \tmkdir --parents \"$CUSTOM_PATH\"\n \twget --quiet --directory-prefix=\"$CUSTOM_PATH\" \\\ndiff --git a/ci/run-style-check.sh b/ci/run-style-check.sh\nnew file mode 100755\nindex 0000000000..9d4c4089c1\n--- /dev/null\n+++ b/ci/run-style-check.sh\n@@ -0,0 +1,8 @@\n+#!/usr/bin/env sh\n+#\n+# Perform style check\n+#\n+\n+baseCommit=$1\n+\n+git clang-format --style file --diff --extensions c,h \"$baseCommit\"\n-- \n2.45.1\n\n"},{"id":"498228","messageId":"20240708092317.267915-9-karthik.188@gmail.com","threadId":"61750","inReplyTo":"20240708092317.267915-1-karthik.188@gmail.com","subject":"[PATCH 8/8] check-whitespace: detect if no base_commit is provided","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-08T09:23:16Z","receivedAt":"2024-07-08T09:23:38Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"The 'check-whitespace' CI script exists gracefully if no base commit is\nprovided or if an invalid revision is provided. This is not good because\nif a particular CI provides an incorrect base_commit, it would fail\nsuccessfully.\n\nThis is exactly the case with the GitLab CI. The CI is using the\n\"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\" variable to get the base commit\nSHA, but variable is only defined for _merged_ pipelines. So it is empty\nfor regular pipelines [1]. This should've failed the check-whitespace\njob.\n\nLet's fix the variable used in the GitLab CI. Let's also add a check for\nincorrect base_commit in the 'check-whitespace.sh' script. While here,\nfix a small typo too.\n\n[1]: https://docs.gitlab.com/ee/ci/variables/predefined_variables.html#predefined-variables-for-merge-request-pipelines\n\nSigned-off-by: Karthik Nayak \n---\n .gitlab-ci.yml | 2 +-\n ci/check-whitespace.sh | 13 ++++++++++---\n 2 files changed, 11 insertions(+), 4 deletions(-)\n\ndiff --git a/.gitlab-ci.yml b/.gitlab-ci.yml\nindex 65fd261e5e..36199893d8 100644\n--- a/.gitlab-ci.yml\n+++ b/.gitlab-ci.yml\n@@ -119,7 +119,7 @@ check-whitespace:\n before_script:\n - ./ci/install-dependencies.sh\n script:\n- - ./ci/check-whitespace.sh \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\"\n+ - ./ci/check-whitespace.sh \"$CI_MERGE_REQUEST_DIFF_BASE_SHA\"\n rules:\n - if: $CI_PIPELINE_SOURCE == 'merge_request_event'\n \ndiff --git a/ci/check-whitespace.sh b/ci/check-whitespace.sh\nindex db399097a5..ab023f9519 100755\n--- a/ci/check-whitespace.sh\n+++ b/ci/check-whitespace.sh\n@@ -9,12 +9,19 @@ baseCommit=$1\n outputFile=$2\n url=$3\n \n-if test \"$#\" -ne 1 && test \"$#\" -ne 3\n+if { test \"$#\" -ne 1 && test \"$#\" -ne 3; } || test -z \"$1\"\n then\n \techo \"USAGE: $0 [ ]\"\n \texit 1\n fi\n \n+gitLogOutput=$(git log --check --pretty=format:\"---% h% s\" \"${baseCommit}\"..)\n+if test $? -ne 0\n+then\n+\techo -n $gitLogOutput\n+\texit 1\n+fi\n+\n problems=()\n commit=\n commitText=\n@@ -58,7 +65,7 @@ do\n \t\techo \"${dash} ${sha} ${etc}\"\n \t\t;;\n \tesac\n-done <<< \"$(git log --check --pretty=format:\"---% h% s\" \"${baseCommit}\"..)\"\n+done <<< \"$gitLogOutput\"\n \n if test ${#problems[*]} -gt 0\n then\n@@ -67,7 +74,7 @@ then\n \t\tgoodParent=${baseCommit: 0:7}\n \tfi\n \n-\techo \"A whitespace issue was found in onen of more of the commits.\"\n+\techo \"A whitespace issue was found in one of more of the commits.\"\n \techo \"Run the following command to resolve whitespace issues:\"\n \techo \"git rebase --whitespace=fix ${goodParent}\"\n \n-- \n2.45.1\n\n"},{"id":"498230","messageId":"CAPx1GveNmpM=v2Kymi7euuerciZKHqPmmexqPdMxKUEA7oAEkQ@mail.gmail.com","threadId":"61750","inReplyTo":"20240708092317.267915-1-karthik.188@gmail.com","subject":"Re: [PATCH 0/8] clang-format: add more rules and enable on CI","fromName":"Chris Torek","fromEmail":"chris.torek@gmail.com","sentAt":"2024-07-08T10:06:36Z","receivedAt":"2024-07-08T10:06:50Z","isPatch":true,"sender":{"key":"chris.torek@gmail.com","avatar":"https://avatars.githubusercontent.com/u/16826774?v=4"},"body":"On Mon, Jul 8, 2024 at 2:23 AM Karthik Nayak wrote:\n> The series was mostly inspired by a patch sent recently to 'include\n> kh_foreach* macros in ForEachMacros' [1]. I was wondering why we don't\n> run the formatting on CI and reduce some of the workload of reviewers.\n\nAs a big fan of automated formatting, I scanned through all of these.\nI did not spot anything problematic and had just a few minor comments.\nI'm not an expert on clang-format directives, nor on GitHub/GitLab CI,\nthough. Anyway if you want it you can have a reviewed-by from me. :-)\n\n(Comments stuck on individual patches)\n\nChris\n"},{"id":"498232","messageId":"CAPx1GvfExeYEwStqDDeyuTW02Yi_n9Php-t-T6waadTgyk-XSg@mail.gmail.com","threadId":"61750","inReplyTo":"20240708092317.267915-2-karthik.188@gmail.com","subject":"Re: [PATCH 1/8] clang-format: indent preprocessor directives after hash","fromName":"Chris Torek","fromEmail":"chris.torek@gmail.com","sentAt":"2024-07-08T10:08:58Z","receivedAt":"2024-07-08T10:09:11Z","isPatch":true,"sender":{"key":"chris.torek@gmail.com","avatar":"https://avatars.githubusercontent.com/u/16826774?v=4"},"body":"On Mon, Jul 8, 2024 at 2:23 AM Karthik Nayak wrote:\n> Let's pick the former and add 'IndentPPDirectives: AfterHash' value to\n> our '.clang-format'. There is no clear reason to pick one over the\n> other, but it would definitely be nicer to be consistent.\n\nThere is one extremely weak technical reason to pick \"# in left column\",\nwhich is: some ancient C compilers required it. I don't think any modern\nones do.\n\nChris\n"},{"id":"498233","messageId":"CAPx1GvfkC0rv_8_q5_HfduhuKX4csO+sBZiZqV+Sh+Q0dV8+4w@mail.gmail.com","threadId":"61750","inReplyTo":"20240708092317.267915-9-karthik.188@gmail.com","subject":"Re: [PATCH 8/8] check-whitespace: detect if no base_commit is provided","fromName":"Chris Torek","fromEmail":"chris.torek@gmail.com","sentAt":"2024-07-08T10:18:35Z","receivedAt":"2024-07-08T10:18:50Z","isPatch":true,"sender":{"key":"chris.torek@gmail.com","avatar":"https://avatars.githubusercontent.com/u/16826774?v=4"},"body":"On Mon, Jul 8, 2024 at 2:24 AM Karthik Nayak wrote:\n> diff --git a/ci/check-whitespace.sh b/ci/check-whitespace.sh\n> index db399097a5..ab023f9519 100755\n> --- a/ci/check-whitespace.sh\n> +++ b/ci/check-whitespace.sh\n> @@ -9,12 +9,19 @@ baseCommit=$1\n> outputFile=$2\n> url=$3\n>\n> -if test \"$#\" -ne 1 && test \"$#\" -ne 3\n> +if { test \"$#\" -ne 1 && test \"$#\" -ne 3; } || test -z \"$1\"\n> then\n\nThe braces `{ ... }` here are unnecessary as `&&`will bind first\n(sh and bash give both operators the same precedence but\nthen use left associativity). Dropping them drops the need for\nthe semicolon. Of course some might prefer this to be explicit.\n\nThe `test` command has AND and OR operators of its own,\nwhich give `-a` (AND) higher precedence than `-o` (OR). In\naddition, `$#` can only expand to an integer value, so quotes\nare not required, and the whole thing can be written as:\n\n if test $# -ne 1 -a $# -ne 3 -o -z \"$1\"\n\n(which is what I would do myself, unless I wanted a separate\nerror message for an empty \"$1\"). It's fine as is though.\n\nChris\n"},{"id":"498234","messageId":"CAPx1GvcunqYvZtkSJ0wDd4802VPEyRzDJnZmfoGh6L1rFof2vQ@mail.gmail.com","threadId":"61750","inReplyTo":"d3921679-eeb8-4cca-bc0d-967e9e567fd4@syscid.com","subject":"Re: [PATCH 8/8] check-whitespace: detect if no base_commit is provided","fromName":"Chris Torek","fromEmail":"chris.torek@gmail.com","sentAt":"2024-07-08T10:42:10Z","receivedAt":"2024-07-08T10:42:23Z","isPatch":true,"sender":{"key":"chris.torek@gmail.com","avatar":"https://avatars.githubusercontent.com/u/16826774?v=4"},"body":"On Mon, Jul 8, 2024 at 3:35 AM Georg Pfuetzenreuter wrote:\n> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html states\n>\n> \"The XSI extensions specifying the -a and -o binary primaries and the\n> '(' and ')' operators have been marked obsolescent.\"\n>\n> suggesting \"&&\" being preferred over \"-a\".\n\nThat's annoying, I wonder why they did that. It does make\nthe \"test\" parser a bit tricky, especially with empty expansions,\nbut empty expansions are already a problem requiring careful\nquoting in the first place...\n\nChris\n"},{"id":"498235","messageId":"d3921679-eeb8-4cca-bc0d-967e9e567fd4@syscid.com","threadId":"61750","inReplyTo":"CAPx1GvfkC0rv_8_q5_HfduhuKX4csO+sBZiZqV+Sh+Q0dV8+4w@mail.gmail.com","subject":"Re: [PATCH 8/8] check-whitespace: detect if no base_commit is provided","fromName":"Georg Pfuetzenreuter","fromEmail":"georg@syscid.com","sentAt":"2024-07-08T10:35:49Z","receivedAt":"2024-07-08T10:44:43Z","isPatch":true,"sender":{"key":"georg@syscid.com","avatar":null},"body":"\n\nOn 7/8/24 12:18 PM, Chris Torek wrote:\n> The `test` command has AND and OR operators of its own,\n> which give `-a` (AND) higher precedence than `-o` (OR). In\n> addition, `$#` can only expand to an integer value, so quotes\n> are not required, and the whole thing can be written as:\n> \n> if test $# -ne 1 -a $# -ne 3 -o -z \"$1\"\n> \n> (which is what I would do myself, unless I wanted a separate\n> error message for an empty \"$1\"). It's fine as is though.\n\nHi,\n\nhttps://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html states\n\n\"The XSI extensions specifying the -a and -o binary primaries and the \n'(' and ')' operators have been marked obsolescent.\"\n\nsuggesting \"&&\" being preferred over \"-a\".\n\n> Chris\n> \n"},{"id":"498278","messageId":"xmqqle2bkg5i.fsf@gitster.g","threadId":"61750","inReplyTo":"20240708092317.267915-2-karthik.188@gmail.com","subject":"Re: [PATCH 1/8] clang-format: indent preprocessor directives after hash","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-07-08T16:22:17Z","receivedAt":"2024-07-08T16:22:22Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Karthik Nayak writes:\n\n> We do not have a rule around the indentation of preprocessor directives.\n> This was also discussed on the list [1], noting how there is often\n> inconsistency in the styling. While there was discussion, there was no\n> conclusion around what is the preferred style here. One style being\n> indenting after the hash:\n>\n> #if FOO\n> # if BAR\n> # include \n> # endif\n> #endif\n>\n> The other being before the hash:\n>\n> #if FOO\n> #if BAR\n> #include \n> #endif\n> #endif\n>\n> Let's pick the former and add 'IndentPPDirectives: AfterHash' value to\n> our '.clang-format'. There is no clear reason to pick one over the\n> other, but it would definitely be nicer to be consistent.\n\nWhen I experimented with reindenting the CPP directives in\n [*], I think I saw an existing violation in an\nearly part of the file. Outside the borrowed code in compat/, we\nhave these:\n\n $ git grep -e '^[ \t]\\{1,\\}#' master -- ':!compat/' \\*.[ch]\n blame.c:\t#define FINGERPRINT_FILE_THRESHOLD\t10\n block-sha1/sha1.c: #define setW(x, val) (*(volatile unsigned int *)&W(x) = (val))\n block-sha1/sha1.c: #define setW(x, val) do { W(x) = (val); __asm__(\"\":::\"memory\"); } while (0)\n block-sha1/sha1.c: #define setW(x, val) (W(x) = (val))\n diff.h:\t#define COLOR_MOVED_DEFAULT COLOR_MOVED_ZEBRA\n diff.h:\t#define COLOR_MOVED_MIN_ALNUM_COUNT 20\n diff.h:\t#define COLOR_MOVED_WS_ALLOW_INDENTATION_CHANGE (1<<5)\n diff.h:\t#define COLOR_MOVED_WS_ERROR (1<<0)\n git-compat-util.h: #define GIT_GNUC_PREREQ(maj, min) 0\n pkt-line.c:\t#define hex(a) (hexchar[(a) & 15])\n pkt-line.c:\t#undef hex\n sha1dc/sha1.c:\t#define sha1_load(m, t, temp) { temp = m[t]; }\n sha1dc/sha1.c:\t#define sha1_load(m, t, temp) { temp = m[t]; sha1_bswap32(temp); }\n\nShould we clean them up before we start adding these rules to the\nfile, especially if we plan to run the rules for stylistic check?\nOtherwise wouldn't we see noises coming from the existing lines that\nmay dwarf the new ones, whose addition we want prevent?\n\nIf we were to run the check in CI to help contributors, I would\nassume that you are arranging it to only complain about the lines\ntouched by the commits they are contributing, not about the existing\nstyle violations. This comment is not limited to the CPP directive\nindentation but any other style rules .clang-format defines.\n\nIf we are not checking only for lines affected by commits being\ncontributed, then perhaps we should exclude compat/ from these\nrules?\n\nThanks for working on this.\n\n[Reference]\n\n * https://lore.kernel.org/git/xmqqjzim197j.fsf@gitster.g/\n"},{"id":"498282","messageId":"xmqqa5irkfw3.fsf_-_@gitster.g","threadId":"61750","inReplyTo":"20240708092317.267915-2-karthik.188@gmail.com","subject":"Re* [PATCH 1/8] clang-format: indent preprocessor directives after hash","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-07-08T16:27:56Z","receivedAt":"2024-07-08T16:28:01Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Subject: cpp: consistently write '#' for CPP directive at column 1\n\nBesides it would get complaints from older compilers and look\nstrange to older eyes that were trained with such compilers, we will\nbe introducing a rule to be enforced to new code. Update a few\nexisting violators before it happens.\n\nThe changes in git-compat-util.h and sha1dc/sha1.c are both about\nindenting the body of conditional CPP directives, e.g.,\n\n (correct) (incorrect)\n #if foo #if foo\n # define bar #define bar\n #endif #endif\n\nThe #define/#undef in pkt-line.c were indented not because they were\ninside a conditional compilation block inside #if/#endif but because\nthey were added inside a function. As the function body is short,\nwe can move them out of the function and lose their indentation\nwithout sacrificing the readability.\n\nSigned-off-by: Junio C Hamano \n---\n\n * So, if we decide to apply a preliminary clean-up to the codebase,\n it should look somethine like this. I couldn't decide what we\n want to do with diff.h where the indentation is done for the same\n reason as how pkt-line.c temporarily defines hex(), but it is\n messier.\n\n\tdiff --git i/diff.h w/diff.h\n\tindex 9901c8ca8c..ecaa8ec49e 100644\n\t--- i/diff.h\n\t+++ w/diff.h\n\t@@ -386,12 +386,12 @@ struct diff_options {\n\t \t\tCOLOR_MOVED_ZEBRA = 3,\n\t \t\tCOLOR_MOVED_ZEBRA_DIM = 4,\n\t \t} color_moved;\n\t-\t#define COLOR_MOVED_DEFAULT COLOR_MOVED_ZEBRA\n\t-\t#define COLOR_MOVED_MIN_ALNUM_COUNT 20\n\t+#define COLOR_MOVED_DEFAULT COLOR_MOVED_ZEBRA\n\t+#define COLOR_MOVED_MIN_ALNUM_COUNT 20\n\t \n\t \t/* XDF_WHITESPACE_FLAGS regarding block detection are set at 2, 3, 4 */\n\t-\t#define COLOR_MOVED_WS_ALLOW_INDENTATION_CHANGE (1<<5)\n\t-\t#define COLOR_MOVED_WS_ERROR (1<<0)\n\t+#define COLOR_MOVED_WS_ALLOW_INDENTATION_CHANGE (1<<5)\n\t+#define COLOR_MOVED_WS_ERROR (1<<0)\n\t \tunsigned color_moved_ws_handling;\n\t \n\t \tstruct repository *repo;\n\n I _think_ the right solution for the first half of this is\n actually to define the enum outside the structure and define\n _DEFAULT and _COUNT next to the enum, all at the top-level of the\n header file outside \"struct diff_options\" definition.\n\n But I am unsure how to clean up the latter and that is where I\n stopped.\n\n git-compat-util.h | 2 +-\n pkt-line.c | 4 ++--\n sha1dc/sha1.c | 4 ++--\n 4 files changed, 9 insertions(+), 9 deletions(-)\n\ndiff --git c/git-compat-util.h w/git-compat-util.h\nindex ca7678a379..2cbd7c92b8 100644\n--- c/git-compat-util.h\n+++ w/git-compat-util.h\n@@ -41,7 +41,7 @@ struct strbuf;\n # define GIT_GNUC_PREREQ(maj, min) \\\n \t((__GNUC__ << 16) + __GNUC_MINOR__ >= ((maj) << 16) + (min))\n #else\n- #define GIT_GNUC_PREREQ(maj, min) 0\n+# define GIT_GNUC_PREREQ(maj, min) 0\n #endif\n \n \ndiff --git c/pkt-line.c w/pkt-line.c\nindex 24479eae4d..30044b2e76 100644\n--- c/pkt-line.c\n+++ w/pkt-line.c\n@@ -132,17 +132,17 @@ void packet_buf_delim(struct strbuf *buf)\n \tstrbuf_add(buf, \"0001\", 4);\n }\n \n+#define hex(a) (hexchar[(a) & 15])\n void set_packet_header(char *buf, int size)\n {\n \tstatic char hexchar[] = \"0123456789abcdef\";\n \n-\t#define hex(a) (hexchar[(a) & 15])\n \tbuf[0] = hex(size >> 12);\n \tbuf[1] = hex(size >> 8);\n \tbuf[2] = hex(size >> 4);\n \tbuf[3] = hex(size);\n-\t#undef hex\n }\n+#undef hex\n \n static void format_packet(struct strbuf *out, const char *prefix,\n \t\t\t const char *fmt, va_list args)\ndiff --git c/sha1dc/sha1.c w/sha1dc/sha1.c\nindex f993ef9c69..e82e05425e 100644\n--- c/sha1dc/sha1.c\n+++ w/sha1dc/sha1.c\n@@ -139,9 +139,9 @@\n #define sha1_mix(W, t) (rotate_left(W[t - 3] ^ W[t - 8] ^ W[t - 14] ^ W[t - 16], 1))\n \n #ifdef SHA1DC_BIGENDIAN\n-\t#define sha1_load(m, t, temp) { temp = m[t]; }\n+#\tdefine sha1_load(m, t, temp) { temp = m[t]; }\n #else\n-\t#define sha1_load(m, t, temp) { temp = m[t]; sha1_bswap32(temp); }\n+#\tdefine sha1_load(m, t, temp) { temp = m[t]; sha1_bswap32(temp); }\n #endif\n \n #define sha1_store(W, t, x)\t*(volatile uint32_t *)&W[t] = x\n"},{"id":"498283","messageId":"xmqq5xtfkfo6.fsf@gitster.g","threadId":"61750","inReplyTo":"20240708092317.267915-5-karthik.188@gmail.com","subject":"Re: [PATCH 4/8] clang-format: replace deprecated option with 'SpacesInParens'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-07-08T16:32:41Z","receivedAt":"2024-07-08T16:32:46Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Karthik Nayak writes:\n\n> Replace the deprecated options 'SpacesInParentheses' and\n> 'SpaceInEmptyParentheses' with the newer 'SpacesInParens' option. The\n> usage is the same.\n\nI do not follow clang and clang-format development; updating to\navoid deprecated features is a welcome change, as long as the\nreplacing feature isn't too new (like, \"introduced only 3 years\nago\").\n\nThanks.\n\n> Signed-off-by: Karthik Nayak \n> ---\n> .clang-format | 9 ++++-----\n> 1 file changed, 4 insertions(+), 5 deletions(-)\n>\n> diff --git a/.clang-format b/.clang-format\n> index 4c9751a9db..914254a29b 100644\n> --- a/.clang-format\n> +++ b/.clang-format\n> @@ -134,8 +134,6 @@ SpaceBeforeAssignmentOperators: true\n> # }\n> SpaceBeforeParens: ControlStatements\n> \n> -# Don't insert spaces inside empty '()'\n> -SpaceInEmptyParentheses: false\n> \n> # The number of spaces before trailing line comments (// - comments).\n> # This does not affect trailing block comments (/* - comments).\n> @@ -149,9 +147,10 @@ SpacesInCStyleCastParentheses: false\n> # var arr = [1, 2, 3]; not var arr = [ 1, 2, 3 ];\n> SpacesInContainerLiterals: false\n> \n> -# Don't insert spaces after '(' or before ')'\n> -# f(arg); not f( arg );\n> -SpacesInParentheses: false\n> +SpacesInParens: Custom\n> +SpacesInParensOptions:\n> + # Don't insert spaces inside empty '()'\n> + InEmptyParentheses: false\n> \n> # Don't insert spaces after '[' or before ']'\n> # int a[5]; not int a[ 5 ];\n"},{"id":"498284","messageId":"xmqq1q43kfnu.fsf@gitster.g","threadId":"61750","inReplyTo":"20240708092317.267915-4-karthik.188@gmail.com","subject":"Re: [PATCH 3/8] clang-format: ensure files end with newlines","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-07-08T16:32:53Z","receivedAt":"2024-07-08T16:32:58Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Karthik Nayak writes:\n\n> All our source files end with a newline, let's formalize in\n> '.clang-format'.\n\nMakes sense.\n\n>\n> Signed-off-by: Karthik Nayak \n> ---\n> .clang-format | 3 +++\n> 1 file changed, 3 insertions(+)\n>\n> diff --git a/.clang-format b/.clang-format\n> index 803b274dd5..4c9751a9db 100644\n> --- a/.clang-format\n> +++ b/.clang-format\n> @@ -106,6 +106,9 @@ IndentCaseLabels: false\n> # #endif\n> IndentPPDirectives: AfterHash\n> \n> +# Insert a newline at end of file if missing\n> +InsertNewlineAtEOF: true\n> +\n> # Don't indent a function definition or declaration if it is wrapped after the\n> # type\n> IndentWrappedFunctionNames: false\n"},{"id":"498286","messageId":"xmqqle2bj0dl.fsf@gitster.g","threadId":"61750","inReplyTo":"20240708092317.267915-6-karthik.188@gmail.com","subject":"Re: [PATCH 5/8] clang-format: avoid braces on simple single-statement bodies","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-07-08T16:48:22Z","receivedAt":"2024-07-08T16:48:27Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Karthik Nayak writes:\n\n> Set the 'RemoveBracesLLVM' to 'true' which ensures that we avoid curly\n> braces for single-statement bodies in conditional blocks.\n\nHmph, two warnings in its documentation [*] sound ominous, especially\nthe second one that says:\n\n Warning\n\n Setting this option to true could lead to incorrect code\n formatting due to clang-format’s lack of complete semantic\n information. As such, extra care should be taken to review code\n changes made by this option.\n\nwhich implies it may not necessarily a good idea to add to\nautomation without telling contributors that they may get hit with a\nfalse positive (or incorrect rewrite).\n\nReading from the examples in that documentation page, it was unclear\nhow it would handle if/else if/.../else cascade where not all branches\nare multi-statement blocks, e.g.,\n\n\tif (A) {\n\t\tdo_A_thing();\n\t} else if (B) {\n\t\tdo_B_thing();\n\t} else {\n\t\tdo_C_things();\n\t\tdo_other_things();\n\t}\n\nbut looking around I am getting a feeling that the tool would do the\nright thing, i.e., to match our preference that is to use {braces}\naround all branches, if I am not mistaken.\n\n\n[Reference]\n\n * https://releases.llvm.org/16.0.0/tools/clang/docs/ClangFormatStyleOptions.html#:~:text=RemoveBracesLLVM\n\n> +# Remove optional braces of control statements (if, else, for, and while)\n> +# according to the LLVM coding style\n> +# This avoids braces on simple single-statement bodies of statements.\n\n\"... but keeps braces if one side of if/else if/.../else cascade has\nmulti-statement body.\"\n\n> +RemoveBracesLLVM: true\n"},{"id":"498289","messageId":"xmqq8qybj039.fsf@gitster.g","threadId":"61750","inReplyTo":"20240708092317.267915-7-karthik.188@gmail.com","subject":"Re: [PATCH 6/8] clang-format: formalize some of the spacing rules","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-07-08T16:54:34Z","receivedAt":"2024-07-08T16:54:39Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Karthik Nayak writes:\n\n> There are some spacing rules that we follow in the project and it makes\n> sen to formalize them:\n> * Ensure there is no space inserted after the logical not '!' operator.\n\nShouldn't the rule be more like \"no space between any single operand\nprefix or postfix operator and its operand\"? \"foo++\", \"--foo\", \"~0\"\nare the examples that come to my mind.\n\n> * Ensure there is no space before the case statement's color.\n\n\"color\" -> \"colon\".\n\n> * Ensure there is no space before the first bracket '[' of an array.\n> * Ensure there is no space in empty blocks.\n\nHmph, I actually thought we preferred to be more explicit, using\n\n\tif (foo)\n\t\t; /* nothing */\n\ninstead of any of\n\n\tif (foo) {}\n\tif (foo) { }\n\tif (foo) { ; }\n\tif (foo) { ; /* nothing */ }\n\nto write an empty statement.\n\n> Signed-off-by: Karthik Nayak \n> ---\n> .clang-format | 14 ++++++++++++++\n> 1 file changed, 14 insertions(+)\n>\n> diff --git a/.clang-format b/.clang-format\n> index 1a5f0c9046..05036f610b 100644\n> --- a/.clang-format\n> +++ b/.clang-format\n> @@ -126,11 +126,18 @@ RemoveBracesLLVM: true\n> # x = (int32)y; not x = (int32) y;\n> SpaceAfterCStyleCast: false\n> \n> +# No space is inserted after the logical not operator\n> +SpaceAfterLogicalNot: false\n> +\n> # Insert spaces before and after assignment operators\n> # int a = 5; not int a=5;\n> # a += 42; a+=42;\n> SpaceBeforeAssignmentOperators: true\n> \n> +# Spaces will be removed before case colon.\n> +# case 1: break; not case 1 : break;\n> +SpaceBeforeCaseColon: false\n> +\n> # Put a space before opening parentheses only after control statement keywords.\n> # void f() {\n> # if (true) {\n> @@ -139,6 +146,13 @@ SpaceBeforeAssignmentOperators: true\n> # }\n> SpaceBeforeParens: ControlStatements\n> \n> +# No space before first '[' in arrays\n> +# int a[5][5]; not int a [5][5];\n> +SpaceBeforeSquareBrackets: false\n> +\n> +# No space will be inserted into {}\n> +# while (true) {} not while (true) { }\n> +SpaceInEmptyBlock: false\n> \n> # The number of spaces before trailing line comments (// - comments).\n> # This does not affect trailing block comments (/* - comments).\n"},{"id":"498290","messageId":"saa7uz2ovecdwg4ruhnusgebmexocq3qinlp5x5oz5sb2a3vqp@v4iupsp2ovwh","threadId":"61750","inReplyTo":"20240708092317.267915-7-karthik.188@gmail.com","subject":"Re: [PATCH 6/8] clang-format: formalize some of the spacing rules","fromName":"Justin Tobler","fromEmail":"jltobler@gmail.com","sentAt":"2024-07-08T16:56:03Z","receivedAt":"2024-07-08T16:56:32Z","isPatch":true,"sender":{"key":"jltobler@gmail.com","avatar":"https://avatars.githubusercontent.com/u/53454972?v=4"},"body":"On 24/07/08 11:23AM, Karthik Nayak wrote:\n> There are some spacing rules that we follow in the project and it makes\n> sen to formalize them:\n> * Ensure there is no space inserted after the logical not '!' operator.\n> * Ensure there is no space before the case statement's color.\n\ns/color/colon\n\n> * Ensure there is no space before the first bracket '[' of an array.\n> * Ensure there is no space in empty blocks.\n\n"},{"id":"498293","messageId":"CAOLa=ZQSDoKHtVRav2DpJhMgy3yhyLZ_itF2Q9fsbPy0WuTvbw@mail.gmail.com","threadId":"61750","inReplyTo":"CAPx1GvcunqYvZtkSJ0wDd4802VPEyRzDJnZmfoGh6L1rFof2vQ@mail.gmail.com","subject":"Re: [PATCH 8/8] check-whitespace: detect if no base_commit is provided","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-08T17:13:06Z","receivedAt":"2024-07-08T17:13:10Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"Chris Torek writes:\n\n> On Mon, Jul 8, 2024 at 3:35 AM Georg Pfuetzenreuter wrote:\n>> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html states\n>>\n>> \"The XSI extensions specifying the -a and -o binary primaries and the\n>> '(' and ')' operators have been marked obsolescent.\"\n>>\n>> suggesting \"&&\" being preferred over \"-a\".\n>\n> That's annoying, I wonder why they did that. It does make\n> the \"test\" parser a bit tricky, especially with empty expansions,\n> but empty expansions are already a problem requiring careful\n> quoting in the first place...\n>\n> Chris\n\nThanks both, I think with this, it makes sense to keep it as is.\n"},{"id":"498294","messageId":"xmqqr0c3hkjs.fsf@gitster.g","threadId":"61750","inReplyTo":"20240708092317.267915-8-karthik.188@gmail.com","subject":"Re: [PATCH 7/8] ci: run style check on GitHub and GitLab","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-07-08T17:15:35Z","receivedAt":"2024-07-08T17:15:38Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Karthik Nayak writes:\n\n> We don't run style checks on our CI, even though we have a\n> '.clang-format' setup in the repository. Let's add one, the job will\n> validate only against the new commits added and will only run on merge\n> requests.\n\nI hope \"against new commits\" means what I think it does ;-) I am\nworried about the case where a new commit touches a file that has\nexisting style violations but the commit does not make the situation\nany worse at all.\n\nOK, \"git clang-format\" is used to for this thing and it is designed\nto address only lines that differ, so hopefully that would be good.\n\n> Since we're introducing it for the first time, let's allow\n> this job to fail, so we can validate if this is useful and eventually\n> enforce it.\n\nVery good idea.\n\n> Signed-off-by: Karthik Nayak \n> ---\n> .github/workflows/check-style.yml | 29 +++++++++++++++++++++++++++++\n> .gitlab-ci.yml | 12 ++++++++++++\n> ci/install-dependencies.sh | 2 +-\n> ci/run-style-check.sh | 8 ++++++++\n> 4 files changed, 50 insertions(+), 1 deletion(-)\n> create mode 100644 .github/workflows/check-style.yml\n> create mode 100755 ci/run-style-check.sh\n>\n> diff --git a/.github/workflows/check-style.yml b/.github/workflows/check-style.yml\n> new file mode 100644\n> index 0000000000..27276dfe5e\n> --- /dev/null\n> +++ b/.github/workflows/check-style.yml\n> @@ -0,0 +1,29 @@\n> +name: check-style\n> +\n> +# Get the repository with all commits to ensure that we can analyze\n> +# all of the commits contributed via the Pull Request.\n> +\n> +on:\n> + pull_request:\n> + types: [opened, synchronize]\n> +\n> +# Avoid unnecessary builds. Unlike the main CI jobs, these are not\n> +# ci-configurable (but could be).\n> +concurrency:\n> + group: ${{ github.workflow }}-${{ github.ref }}\n> + cancel-in-progress: true\n> +\n> +jobs:\n> + check-style:\n> + runs-on: ubuntu-latest\n> + steps:\n> + - uses: actions/checkout@v4\n> + with:\n> + fetch-depth: 0\n> +\n> + - name: git clang-format\n> + continue-on-error: true\n> + id: check_out\n> + run: |\n> + ./ci/run-style-check.sh \\\n> + \"${{github.event.pull_request.base.sha}}\"\n> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml\n> index 37b991e080..65fd261e5e 100644\n> --- a/.gitlab-ci.yml\n> +++ b/.gitlab-ci.yml\n> @@ -123,6 +123,18 @@ check-whitespace:\n> rules:\n> - if: $CI_PIPELINE_SOURCE == 'merge_request_event'\n> \n> +check-style:\n> + image: ubuntu:latest\n> + allow_failure: true\n> + variables:\n> + CC: clang\n> + before_script:\n> + - ./ci/install-dependencies.sh\n> + script:\n> + - ./ci/run-style-check.sh \"$CI_MERGE_REQUEST_DIFF_BASE_SHA\"\n> + rules:\n> + - if: $CI_PIPELINE_SOURCE == 'merge_request_event'\n> +\n> documentation:\n> image: ubuntu:latest\n> variables:\n> diff --git a/ci/install-dependencies.sh b/ci/install-dependencies.sh\n> index 6ec0f85972..46fe12a690 100755\n> --- a/ci/install-dependencies.sh\n> +++ b/ci/install-dependencies.sh\n> @@ -43,7 +43,7 @@ ubuntu-*)\n> \t\tmake libssl-dev libcurl4-openssl-dev libexpat-dev wget sudo default-jre \\\n> \t\ttcl tk gettext zlib1g-dev perl-modules liberror-perl libauthen-sasl-perl \\\n> \t\tlibemail-valid-perl libio-pty-perl libio-socket-ssl-perl libnet-smtp-ssl-perl libdbd-sqlite3-perl libcgi-pm-perl \\\n> -\t\t${CC_PACKAGE:-${CC:-gcc}} $PYTHON_PACKAGE\n> +\t\t${CC_PACKAGE:-${CC:-gcc}} $PYTHON_PACKAGE clang-format\n> \n> \tmkdir --parents \"$CUSTOM_PATH\"\n> \twget --quiet --directory-prefix=\"$CUSTOM_PATH\" \\\n> diff --git a/ci/run-style-check.sh b/ci/run-style-check.sh\n> new file mode 100755\n> index 0000000000..9d4c4089c1\n> --- /dev/null\n> +++ b/ci/run-style-check.sh\n> @@ -0,0 +1,8 @@\n> +#!/usr/bin/env sh\n\nUnder ci/ hierarchy we are very inconsistent. Most use the bog\nstandard \"#!/bin/sh\" (which is my preference by the way), but\nsee what we have here right now:\n\n $ git grep -e '^#![a-z/]*/bin/[a-z]*sh' -e '^#![a-z/]*bin/env ' ci |\n sort -t: -k2\n ci/check-directional-formatting.bash:#!/bin/bash\n ci/install-dependencies.sh:#!/bin/sh\n ci/make-test-artifacts.sh:#!/bin/sh\n ci/mount-fileshare.sh:#!/bin/sh\n ci/print-test-failures.sh:#!/bin/sh\n ci/run-build-and-minimal-fuzzers.sh:#!/bin/sh\n ci/run-build-and-tests.sh:#!/bin/sh\n ci/run-docker-build.sh:#!/bin/sh\n ci/run-docker.sh:#!/bin/sh\n ci/run-static-analysis.sh:#!/bin/sh\n ci/run-test-slice.sh:#!/bin/sh\n ci/util/extract-trash-dirs.sh:#!/bin/sh\n ci/check-whitespace.sh:#!/usr/bin/env bash\n ci/test-documentation.sh:#!/usr/bin/env bash\n\nUnless you have a strong reason to suspect that in your CI\nenvironment /bin/sh is an unusuably broken shell, please do not\nspread the inconsistencies.\n\nI think the consensus from the last discussion we had was to allow\nscripts that rely on bash-isms to say \"#!/usr/bin/env bash\" because\nwe know /bin/sh can legitimately be not bash and we assume bash may\nnot be installed as /bin/bash. As all of them would run in the CI\nenvironment that we have some control over what required packages\nare installed at what path, it is OK to assume that \"bash\" would be\nfound on the $PATH by using /usr/bin/env (but it does assume\neverybody installs \"env\" there, not /bin/env or /usr/local/bin/env,\nwith a bit of chicken-and-egg issue).\n\n> +#\n> +# Perform style check\n> +#\n> +\n> +baseCommit=$1\n> +\n> +git clang-format --style file --diff --extensions c,h \"$baseCommit\"\n\nOK, \"git clang-format\" compares the working tree with the named\ncommit, so if we have the tip of the topic branch proposed to be\nmerged checked out and compare it with the base commit of the topic,\nthat would give us exactly what we want. Nice.\n\nThanks.\n"},{"id":"498295","messageId":"xmqqikxfhkdc.fsf@gitster.g","threadId":"61750","inReplyTo":"CAPx1GvcunqYvZtkSJ0wDd4802VPEyRzDJnZmfoGh6L1rFof2vQ@mail.gmail.com","subject":"Re: [PATCH 8/8] check-whitespace: detect if no base_commit is provided","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-07-08T17:19:27Z","receivedAt":"2024-07-08T17:19:29Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Chris Torek writes:\n\n> On Mon, Jul 8, 2024 at 3:35 AM Georg Pfuetzenreuter wrote:\n>> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html states\n>>\n>> \"The XSI extensions specifying the -a and -o binary primaries and the\n>> '(' and ')' operators have been marked obsolescent.\"\n>>\n>> suggesting \"&&\" being preferred over \"-a\".\n>\n> That's annoying, I wonder why they did that.\n\nConsult Documentation/CodingGuidelines?\n\n - We do not write our \"test\" command with \"-a\" and \"-o\" and use \"&&\"\n or \"||\" to concatenate multiple \"test\" commands instead, because\n the use of \"-a/-o\" is often error-prone. E.g.\n\n test -n \"$x\" -a \"$a\" = \"$b\"\n\n is buggy and breaks when $x is \"=\", but\n\n test -n \"$x\" && test \"$a\" = \"$b\"\n\n does not have such a problem.\n\n"},{"id":"498296","messageId":"CAOLa=ZQUv7=CKFY7YwfVeOW0qobJbMU8nadN4daB7Lb2=eJc8Q@mail.gmail.com","threadId":"61750","inReplyTo":"xmqq8qybj039.fsf@gitster.g","subject":"Re: [PATCH 6/8] clang-format: formalize some of the spacing rules","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-08T17:26:50Z","receivedAt":"2024-07-08T17:26:54Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"Junio C Hamano writes:\n\n> Karthik Nayak writes:\n>\n>> There are some spacing rules that we follow in the project and it makes\n>> sen to formalize them:\n>> * Ensure there is no space inserted after the logical not '!' operator.\n>\n> Shouldn't the rule be more like \"no space between any single operand\n> prefix or postfix operator and its operand\"? \"foo++\", \"--foo\", \"~0\"\n> are the examples that come to my mind.\n>\n\nThe rule here is SpaceAfterLogicalNot [1], is specific to logical not\noperator. Unfortunately I couldn't find a general rule for unary\noperators. That would be very useful indeed.\n\n>> * Ensure there is no space before the case statement's color.\n>\n> \"color\" -> \"colon\".\n>\n\nWill fix, thanks!\n\n>> * Ensure there is no space before the first bracket '[' of an array.\n>> * Ensure there is no space in empty blocks.\n>\n> Hmph, I actually thought we preferred to be more explicit, using\n>\n> \tif (foo)\n> \t\t; /* nothing */\n>\n> instead of any of\n>\n> \tif (foo) {}\n> \tif (foo) { }\n> \tif (foo) { ; }\n> \tif (foo) { ; /* nothing */ }\n>\n> to write an empty statement.\n>\n\nYup, that is correct. This rule doesn't state that we need to use 'if (foo) {}'\nover the more explicit format. It only states that if we do create an\nempty block without statements, the rule is to have no spaces.\n\nWe only have a few instances of this in our code.\n\n[1]: https://clang.llvm.org/docs/ClangFormatStyleOptions.html#spaceafterlogicalnot\n\n[snip]\n"},{"id":"498297","messageId":"CAOLa=ZQa7NgTZrMMM8eEEy3Q7E0TohLbHPA=bDwUN0-3u9qLkA@mail.gmail.com","threadId":"61750","inReplyTo":"saa7uz2ovecdwg4ruhnusgebmexocq3qinlp5x5oz5sb2a3vqp@v4iupsp2ovwh","subject":"Re: [PATCH 6/8] clang-format: formalize some of the spacing rules","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-08T17:27:12Z","receivedAt":"2024-07-08T17:27:15Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"Justin Tobler writes:\n\n> On 24/07/08 11:23AM, Karthik Nayak wrote:\n>> There are some spacing rules that we follow in the project and it makes\n>> sen to formalize them:\n>> * Ensure there is no space inserted after the logical not '!' operator.\n>> * Ensure there is no space before the case statement's color.\n>\n> s/color/colon\n>\n\nThanks, will fix in the next version!\n\n>> * Ensure there is no space before the first bracket '[' of an array.\n>> * Ensure there is no space in empty blocks.\n"},{"id":"498298","messageId":"xmqqbk37hjma.fsf@gitster.g","threadId":"61750","inReplyTo":"20240708092317.267915-9-karthik.188@gmail.com","subject":"Re: [PATCH 8/8] check-whitespace: detect if no base_commit is provided","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-07-08T17:35:41Z","receivedAt":"2024-07-08T17:35:46Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Karthik Nayak writes:\n\n> The 'check-whitespace' CI script exists gracefully if no base commit is\n\n\"exists\" -> \"exits\"\n\n> provided or if an invalid revision is provided...\n> ...\n> Let's fix the variable used in the GitLab CI. Let's also add a check for\n> incorrect base_commit in the 'check-whitespace.sh' script. While here,\n> fix a small typo too.\n>\n> [1]: https://docs.gitlab.com/ee/ci/variables/predefined_variables.html#predefined-variables-for-merge-request-pipelines\n>\n> Signed-off-by: Karthik Nayak \n> ---\n> .gitlab-ci.yml | 2 +-\n> ci/check-whitespace.sh | 13 ++++++++++---\n> 2 files changed, 11 insertions(+), 4 deletions(-)\n>\n> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml\n> index 65fd261e5e..36199893d8 100644\n> --- a/.gitlab-ci.yml\n> +++ b/.gitlab-ci.yml\n> @@ -119,7 +119,7 @@ check-whitespace:\n> before_script:\n> - ./ci/install-dependencies.sh\n> script:\n> - - ./ci/check-whitespace.sh \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\"\n> + - ./ci/check-whitespace.sh \"$CI_MERGE_REQUEST_DIFF_BASE_SHA\"\n> rules:\n> - if: $CI_PIPELINE_SOURCE == 'merge_request_event'\n> \n> diff --git a/ci/check-whitespace.sh b/ci/check-whitespace.sh\n> index db399097a5..ab023f9519 100755\n> --- a/ci/check-whitespace.sh\n> +++ b/ci/check-whitespace.sh\n> @@ -9,12 +9,19 @@ baseCommit=$1\n> outputFile=$2\n> url=$3\n> \n> -if test \"$#\" -ne 1 && test \"$#\" -ne 3\n> +if { test \"$#\" -ne 1 && test \"$#\" -ne 3; } || test -z \"$1\"\n\nYou can just add || test -z \"$1\" after the existing one, making the\nthing A && B || C which evaulates left to right with the same\nprecedence for && and ||.\n\n> then\n> \techo \"USAGE: $0 [ ]\"\n> \texit 1\n> fi\n> \n> +gitLogOutput=$(git log --check --pretty=format:\"---% h% s\" \"${baseCommit}\"..)\n\nThat is a large string to hold in a variable for a potentially large\nseries with lots of breakages. I didn't quite read the reasoning\nbehind this change in the proposed log message. Under what\ncondition do you expect the command to exit with non-zero status?\n$basecommit being a non-empty string but does not name a valid\ncommit object or something, in which case shouldn't \"git log\n--oneline $baseCommit..\" or something simpler should suffice?\n\n> +if test $? -ne 0\n> +then\n> +\techo -n $gitLogOutput\n\nWhat is \"-n\" doing here? Why are you squashing run of spaces in the\n$gitLogOutput variable into a space by not \"quoting\" inside a dq-pair?\n\n> +\texit 1\n> +fi\n\nLooking for \"--check\" in\n\n\t$ git log --help\n\ntells me that the command exits with non-zero status if problems are\nfound, so wouldn't that mean the cases with problems always exit\nearly, bypassing the while loop with full of bash-ism that comes\nafter this block?\n\n> problems=()\n> commit=\n> commitText=\n> @@ -58,7 +65,7 @@ do\n> \t\techo \"${dash} ${sha} ${etc}\"\n> \t\t;;\n> \tesac\n> -done <<< \"$(git log --check --pretty=format:\"---% h% s\" \"${baseCommit}\"..)\"\n> +done <<< \"$gitLogOutput\"\n> \n> if test ${#problems[*]} -gt 0\n> then\n> @@ -67,7 +74,7 @@ then\n> \t\tgoodParent=${baseCommit: 0:7}\n> \tfi\n> \n> -\techo \"A whitespace issue was found in onen of more of the commits.\"\n> +\techo \"A whitespace issue was found in one of more of the commits.\"\n> \techo \"Run the following command to resolve whitespace issues:\"\n> \techo \"git rebase --whitespace=fix ${goodParent}\"\n"},{"id":"498300","messageId":"tl66b35ytbri4dep3cnppdexebblep6avyuhj4moc4mnsolnp2@xpqqwyl4oo2y","threadId":"61750","inReplyTo":"20240708092317.267915-9-karthik.188@gmail.com","subject":"Re: [PATCH 8/8] check-whitespace: detect if no base_commit is provided","fromName":"Justin Tobler","fromEmail":"jltobler@gmail.com","sentAt":"2024-07-08T17:58:42Z","receivedAt":"2024-07-08T17:59:12Z","isPatch":true,"sender":{"key":"jltobler@gmail.com","avatar":"https://avatars.githubusercontent.com/u/53454972?v=4"},"body":"On 24/07/08 11:23AM, Karthik Nayak wrote:\n> The 'check-whitespace' CI script exists gracefully if no base commit is\n> provided or if an invalid revision is provided. This is not good because\n> if a particular CI provides an incorrect base_commit, it would fail\n> successfully.\n\ns/exists/exits\n\nIf no base commit is provided, we already fail. Here is an example\nGitLab CI job demonstrating this:\nhttps://gitlab.com/gitlab-org/git/-/jobs/7289543498#L2370\n\nIf the base commit does not exist though, it currently prints that error occured\nbut still exits with 0. Makes sense to update and fail the job accordingly.\n\n> \n> This is exactly the case with the GitLab CI. The CI is using the\n> \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\" variable to get the base commit\n> SHA, but variable is only defined for _merged_ pipelines. So it is empty\n> for regular pipelines [1]. This should've failed the check-whitespace\n> job.\n\nThe CI for this project is configured to use merged pipelines. So \n$CI_MERGE_REQUEST_TARGET_BRANCH_SHA is defined. The downside with using \n$CI_MERGE_REQUEST_DIFF_BASE_SHA is that it will include other commits in\nthe check that are not part of the MR, but are included in the merge for\nmerge pipelines. With this change, the job can now fail due to unrelated\nchanges.\n\nIf we feel inclined to also support regular pipelines, one option would\nbe to simply fallback to $CI_MERGE_REQUEST_DIFF_BASE_SHA if a merge\npipeline is not in use.\n\nGitLab CI pipeline showing $CI_MERGE_REQUEST_TARGET_BRANCH_SHA defined:\nhttps://gitlab.com/gitlab-org/git/-/jobs/7289331488#L2371\n\n> \n> Let's fix the variable used in the GitLab CI. Let's also add a check for\n> incorrect base_commit in the 'check-whitespace.sh' script. While here,\n> fix a small typo too.\n> \n> [1]: https://docs.gitlab.com/ee/ci/variables/predefined_variables.html#predefined-variables-for-merge-request-pipelines\n> \n> Signed-off-by: Karthik Nayak \n> ---\n> .gitlab-ci.yml | 2 +-\n> ci/check-whitespace.sh | 13 ++++++++++---\n> 2 files changed, 11 insertions(+), 4 deletions(-)\n> \n> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml\n> index 65fd261e5e..36199893d8 100644\n> --- a/.gitlab-ci.yml\n> +++ b/.gitlab-ci.yml\n> @@ -119,7 +119,7 @@ check-whitespace:\n> before_script:\n> - ./ci/install-dependencies.sh\n> script:\n> - - ./ci/check-whitespace.sh \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\"\n> + - ./ci/check-whitespace.sh \"$CI_MERGE_REQUEST_DIFF_BASE_SHA\"\n> rules:\n> - if: $CI_PIPELINE_SOURCE == 'merge_request_event'\n> \n> diff --git a/ci/check-whitespace.sh b/ci/check-whitespace.sh\n> index db399097a5..ab023f9519 100755\n> --- a/ci/check-whitespace.sh\n> +++ b/ci/check-whitespace.sh\n> @@ -9,12 +9,19 @@ baseCommit=$1\n> outputFile=$2\n> url=$3\n> \n> -if test \"$#\" -ne 1 && test \"$#\" -ne 3\n> +if { test \"$#\" -ne 1 && test \"$#\" -ne 3; } || test -z \"$1\"\n\nI might be misunderstanding, but this additional check seems redundant to me.\n\n> then\n> \techo \"USAGE: $0 [ ]\"\n> \texit 1\n> fi\n> \n> +gitLogOutput=$(git log --check --pretty=format:\"---% h% s\" \"${baseCommit}\"..)\n> +if test $? -ne 0\n> +then\n> +\techo -n $gitLogOutput\n> +\texit 1\n> +fi\n> +\n> problems=()\n> commit=\n> commitText=\n> @@ -58,7 +65,7 @@ do\n> \t\techo \"${dash} ${sha} ${etc}\"\n> \t\t;;\n> \tesac\n> -done <<< \"$(git log --check --pretty=format:\"---% h% s\" \"${baseCommit}\"..)\"\n> +done <<< \"$gitLogOutput\"\n> \n> if test ${#problems[*]} -gt 0\n> then\n> @@ -67,7 +74,7 @@ then\n> \t\tgoodParent=${baseCommit: 0:7}\n> \tfi\n> \n> -\techo \"A whitespace issue was found in onen of more of the commits.\"\n> +\techo \"A whitespace issue was found in one of more of the commits.\"\nThere is another preexisting typo:\n\ns/one of/one or/\n\n> \techo \"Run the following command to resolve whitespace issues:\"\n> \techo \"git rebase --whitespace=fix ${goodParent}\"\n> \n> -- \n> 2.45.1\n> \n"},{"id":"498301","messageId":"7wc2ucdbirqgtrxgij3i4eqwfib334kdogbfxtiyifje6clsat@3p3xnqkoj3ic","threadId":"61750","inReplyTo":"20240708092317.267915-8-karthik.188@gmail.com","subject":"Re: [PATCH 7/8] ci: run style check on GitHub and GitLab","fromName":"Justin Tobler","fromEmail":"jltobler@gmail.com","sentAt":"2024-07-08T18:10:34Z","receivedAt":"2024-07-08T18:11:03Z","isPatch":true,"sender":{"key":"jltobler@gmail.com","avatar":"https://avatars.githubusercontent.com/u/53454972?v=4"},"body":"On 24/07/08 11:23AM, Karthik Nayak wrote:\n> We don't run style checks on our CI, even though we have a\n> '.clang-format' setup in the repository. Let's add one, the job will\n> validate only against the new commits added and will only run on merge\n> requests. Since we're introducing it for the first time, let's allow\n> this job to fail, so we can validate if this is useful and eventually\n> enforce it.\n\n[snip]\n\n> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml\n> index 37b991e080..65fd261e5e 100644\n> --- a/.gitlab-ci.yml\n> +++ b/.gitlab-ci.yml\n> @@ -123,6 +123,18 @@ check-whitespace:\n> rules:\n> - if: $CI_PIPELINE_SOURCE == 'merge_request_event'\n> \n> +check-style:\n> + image: ubuntu:latest\n> + allow_failure: true\n> + variables:\n> + CC: clang\n> + before_script:\n> + - ./ci/install-dependencies.sh\n> + script:\n> + - ./ci/run-style-check.sh \"$CI_MERGE_REQUEST_DIFF_BASE_SHA\"\n\nOne downside to using $CI_MERGE_REQUEST_DIFF_BASE_SHA is that for GitLab\nmerge pipeines, commits from the merge that are not part of the MR\nchanges are also included. This could lead to somewhat confusing\nfailures.\n\nExample failure occuring on this patch series:\nhttps://gitlab.com/gitlab-org/git/-/jobs/7284442220\n\nIt might be best to use $CI_MERGE_REQUEST_TARGET_BRANCH_SHA instead.\n\n> + rules:\n> + - if: $CI_PIPELINE_SOURCE == 'merge_request_event'\n> +\n"},{"id":"498316","messageId":"CAOLa=ZSb_S7X7pdFPp0r5bfNc3o95mGe5pU+rC1T_yM89NRqCw@mail.gmail.com","threadId":"61750","inReplyTo":"xmqqle2bj0dl.fsf@gitster.g","subject":"Re: [PATCH 5/8] clang-format: avoid braces on simple single-statement bodies","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-08T20:25:32Z","receivedAt":"2024-07-08T20:25:34Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"Junio C Hamano writes:\n\n> Karthik Nayak writes:\n>\n>> Set the 'RemoveBracesLLVM' to 'true' which ensures that we avoid curly\n>> braces for single-statement bodies in conditional blocks.\n>\n> Hmph, two warnings in its documentation [*] sound ominous, especially\n> the second one that says:\n>\n> Warning\n>\n> Setting this option to true could lead to incorrect code\n> formatting due to clang-format’s lack of complete semantic\n> information. As such, extra care should be taken to review code\n> changes made by this option.\n>\n> which implies it may not necessarily a good idea to add to\n> automation without telling contributors that they may get hit with a\n> false positive (or incorrect rewrite).\n>\n\nAgreed on this one. I'm a bit skeptical to be honest too. I think I\nshould have added information about the warning in the commit too. I\nwill for next round. Overall, this also contributes to the reason why I\ndecided these CI jobs need to be allowed to fail.\n\n>\n> Reading from the examples in that documentation page, it was unclear\n> how it would handle if/else if/.../else cascade where not all branches\n> are multi-statement blocks, e.g.,\n>\n> \tif (A) {\n> \t\tdo_A_thing();\n> \t} else if (B) {\n> \t\tdo_B_thing();\n> \t} else {\n> \t\tdo_C_things();\n> \t\tdo_other_things();\n> \t}\n>\n> but looking around I am getting a feeling that the tool would do the\n> right thing, i.e., to match our preference that is to use {braces}\n> around all branches, if I am not mistaken.\n>\n\nYup, that was my understanding and what I could see from some quick\ntrials that I did too.\n\nIt would be a great win to have this though, because it is one of the\nthings that always get me.\n\n>\n> [Reference]\n>\n> * https://releases.llvm.org/16.0.0/tools/clang/docs/ClangFormatStyleOptions.html#:~:text=RemoveBracesLLVM\n>\n>> +# Remove optional braces of control statements (if, else, for, and while)\n>> +# according to the LLVM coding style\n>> +# This avoids braces on simple single-statement bodies of statements.\n>\n> \"... but keeps braces if one side of if/else if/.../else cascade has\n> multi-statement body.\"\n>\n\nMakes sense, will add.\n\n>> +RemoveBracesLLVM: true\n\nOverall I must say, I'd be okay if this patch is also dropped from this\nseries.\n"},{"id":"498317","messageId":"CAOLa=ZTrVGekoh0z2H0WpKCqhHLuWSeZShCkkSA_NGSrj_Tb7g@mail.gmail.com","threadId":"61750","inReplyTo":"xmqqle2bkg5i.fsf@gitster.g","subject":"Re: [PATCH 1/8] clang-format: indent preprocessor directives after hash","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-08T20:33:02Z","receivedAt":"2024-07-08T20:33:03Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"Junio C Hamano writes:\n\n> Karthik Nayak writes:\n>\n>> We do not have a rule around the indentation of preprocessor directives.\n>> This was also discussed on the list [1], noting how there is often\n>> inconsistency in the styling. While there was discussion, there was no\n>> conclusion around what is the preferred style here. One style being\n>> indenting after the hash:\n>>\n>> #if FOO\n>> # if BAR\n>> # include \n>> # endif\n>> #endif\n>>\n>> The other being before the hash:\n>>\n>> #if FOO\n>> #if BAR\n>> #include \n>> #endif\n>> #endif\n>>\n>> Let's pick the former and add 'IndentPPDirectives: AfterHash' value to\n>> our '.clang-format'. There is no clear reason to pick one over the\n>> other, but it would definitely be nicer to be consistent.\n>\n> When I experimented with reindenting the CPP directives in\n> [*], I think I saw an existing violation in an\n> early part of the file. Outside the borrowed code in compat/, we\n> have these:\n>\n> $ git grep -e '^[ \t]\\{1,\\}#' master -- ':!compat/' \\*.[ch]\n> blame.c:\t#define FINGERPRINT_FILE_THRESHOLD\t10\n> block-sha1/sha1.c: #define setW(x, val) (*(volatile unsigned int *)&W(x) = (val))\n> block-sha1/sha1.c: #define setW(x, val) do { W(x) = (val); __asm__(\"\":::\"memory\"); } while (0)\n> block-sha1/sha1.c: #define setW(x, val) (W(x) = (val))\n> diff.h:\t#define COLOR_MOVED_DEFAULT COLOR_MOVED_ZEBRA\n> diff.h:\t#define COLOR_MOVED_MIN_ALNUM_COUNT 20\n> diff.h:\t#define COLOR_MOVED_WS_ALLOW_INDENTATION_CHANGE (1<<5)\n> diff.h:\t#define COLOR_MOVED_WS_ERROR (1<<0)\n> git-compat-util.h: #define GIT_GNUC_PREREQ(maj, min) 0\n> pkt-line.c:\t#define hex(a) (hexchar[(a) & 15])\n> pkt-line.c:\t#undef hex\n> sha1dc/sha1.c:\t#define sha1_load(m, t, temp) { temp = m[t]; }\n> sha1dc/sha1.c:\t#define sha1_load(m, t, temp) { temp = m[t]; sha1_bswap32(temp); }\n>\n> Should we clean them up before we start adding these rules to the\n> file, especially if we plan to run the rules for stylistic check?\n> Otherwise wouldn't we see noises coming from the existing lines that\n> may dwarf the new ones, whose addition we want prevent?\n>\n\nMaking syntax changes just so the rule works was something I did\nconsider, but I avoided it mostly because the CI only applies to the\nchanges made and not pre-existing files.\n\nThis also allows us to apply the boy scout rule and cleanup as we go.\n\n> If we were to run the check in CI to help contributors, I would\n> assume that you are arranging it to only complain about the lines\n> touched by the commits they are contributing, not about the existing\n> style violations. This comment is not limited to the CPP directive\n> indentation but any other style rules .clang-format defines.\n>\n\nYes exactly, the usage of 'git-clang-format' allows us to only check for\nlines changed.\n\n> If we are not checking only for lines affected by commits being\n> contributed, then perhaps we should exclude compat/ from these\n> rules?\n>\n> Thanks for working on this.\n>\n> [Reference]\n>\n> * https://lore.kernel.org/git/xmqqjzim197j.fsf@gitster.g/\n"},{"id":"498319","messageId":"CAPig+cRvz7ctW8K7QbZyDSTTG_qxdU9uRmJYrXPW64OuydH4VA@mail.gmail.com","threadId":"61750","inReplyTo":"20240708092317.267915-7-karthik.188@gmail.com","subject":"Re: [PATCH 6/8] clang-format: formalize some of the spacing rules","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2024-07-08T20:53:22Z","receivedAt":"2024-07-08T20:53:34Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Mon, Jul 8, 2024 at 5:24 AM Karthik Nayak wrote:\n> There are some spacing rules that we follow in the project and it makes\n> sen to formalize them:\n\nSince nobody else pointed it out: s/sen/sense/\n"},{"id":"498320","messageId":"CAOLa=ZTH8Zh-H7R+1=f3zvnBKFzs8Wtzh+Xxy7+aBvD4Yjg59A@mail.gmail.com","threadId":"61750","inReplyTo":"xmqqr0c3hkjs.fsf@gitster.g","subject":"Re: [PATCH 7/8] ci: run style check on GitHub and GitLab","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-08T21:05:40Z","receivedAt":"2024-07-08T21:05:42Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"Junio C Hamano writes:\n[snip]\n>> diff --git a/ci/run-style-check.sh b/ci/run-style-check.sh\n>> new file mode 100755\n>> index 0000000000..9d4c4089c1\n>> --- /dev/null\n>> +++ b/ci/run-style-check.sh\n>> @@ -0,0 +1,8 @@\n>> +#!/usr/bin/env sh\n>\n> Under ci/ hierarchy we are very inconsistent. Most use the bog\n> standard \"#!/bin/sh\" (which is my preference by the way), but\n> see what we have here right now:\n>\n> $ git grep -e '^#![a-z/]*/bin/[a-z]*sh' -e '^#![a-z/]*bin/env ' ci |\n> sort -t: -k2\n> ci/check-directional-formatting.bash:#!/bin/bash\n> ci/install-dependencies.sh:#!/bin/sh\n> ci/make-test-artifacts.sh:#!/bin/sh\n> ci/mount-fileshare.sh:#!/bin/sh\n> ci/print-test-failures.sh:#!/bin/sh\n> ci/run-build-and-minimal-fuzzers.sh:#!/bin/sh\n> ci/run-build-and-tests.sh:#!/bin/sh\n> ci/run-docker-build.sh:#!/bin/sh\n> ci/run-docker.sh:#!/bin/sh\n> ci/run-static-analysis.sh:#!/bin/sh\n> ci/run-test-slice.sh:#!/bin/sh\n> ci/util/extract-trash-dirs.sh:#!/bin/sh\n> ci/check-whitespace.sh:#!/usr/bin/env bash\n> ci/test-documentation.sh:#!/usr/bin/env bash\n>\n> Unless you have a strong reason to suspect that in your CI\n> environment /bin/sh is an unusuably broken shell, please do not\n> spread the inconsistencies.\n>\n> I think the consensus from the last discussion we had was to allow\n> scripts that rely on bash-isms to say \"#!/usr/bin/env bash\" because\n> we know /bin/sh can legitimately be not bash and we assume bash may\n> not be installed as /bin/bash. As all of them would run in the CI\n> environment that we have some control over what required packages\n> are installed at what path, it is OK to assume that \"bash\" would be\n> found on the $PATH by using /usr/bin/env (but it does assume\n> everybody installs \"env\" there, not /bin/env or /usr/local/bin/env,\n> with a bit of chicken-and-egg issue).\n>\n\nI must admit, I didn't put any thought into this while writing. The\nusage of '/usr/bin/env' is mostly muscle memory and since I didn't need\nany bash-isms, I defaulted to /bin/sh.\n\nI'll change it, thanks!\n\n>> +#\n>> +# Perform style check\n>> +#\n>> +\n>> +baseCommit=$1\n>> +\n>> +git clang-format --style file --diff --extensions c,h \"$baseCommit\"\n>\n> OK, \"git clang-format\" compares the working tree with the named\n> commit, so if we have the tip of the topic branch proposed to be\n> merged checked out and compare it with the base commit of the topic,\n> that would give us exactly what we want. Nice.\n>\n> Thanks.\n"},{"id":"498321","messageId":"CAOLa=ZTuBziBPY1B0P3gTWMhqThuyFsFW1aWtwUconYN4gH+aA@mail.gmail.com","threadId":"61750","inReplyTo":"7wc2ucdbirqgtrxgij3i4eqwfib334kdogbfxtiyifje6clsat@3p3xnqkoj3ic","subject":"Re: [PATCH 7/8] ci: run style check on GitHub and GitLab","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-08T21:16:56Z","receivedAt":"2024-07-08T21:16:58Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"Justin Tobler writes:\n\n> On 24/07/08 11:23AM, Karthik Nayak wrote:\n>> We don't run style checks on our CI, even though we have a\n>> '.clang-format' setup in the repository. Let's add one, the job will\n>> validate only against the new commits added and will only run on merge\n>> requests. Since we're introducing it for the first time, let's allow\n>> this job to fail, so we can validate if this is useful and eventually\n>> enforce it.\n>\n> [snip]\n>\n>> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml\n>> index 37b991e080..65fd261e5e 100644\n>> --- a/.gitlab-ci.yml\n>> +++ b/.gitlab-ci.yml\n>> @@ -123,6 +123,18 @@ check-whitespace:\n>> rules:\n>> - if: $CI_PIPELINE_SOURCE == 'merge_request_event'\n>>\n>> +check-style:\n>> + image: ubuntu:latest\n>> + allow_failure: true\n>> + variables:\n>> + CC: clang\n>> + before_script:\n>> + - ./ci/install-dependencies.sh\n>> + script:\n>> + - ./ci/run-style-check.sh \"$CI_MERGE_REQUEST_DIFF_BASE_SHA\"\n>\n> One downside to using $CI_MERGE_REQUEST_DIFF_BASE_SHA is that for GitLab\n> merge pipeines, commits from the merge that are not part of the MR\n> changes are also included. This could lead to somewhat confusing\n> failures.\n>\n\nI'm not sure I follow.\n\n> Example failure occuring on this patch series:\n> https://gitlab.com/gitlab-org/git/-/jobs/7284442220\n>\n\nIf you notice this job, it points to the commit: 1c6551488, and the\nparent commit of that commit is: 614dff2011.\n\nThe parent commit [1] is a test commit I added to check the failures. So\nisn't this working as expected?\n\n> It might be best to use $CI_MERGE_REQUEST_TARGET_BRANCH_SHA instead.\n>\n\nI actually started with $CI_MERGE_REQUEST_TARGET_BRANCH_SHA, it didn't\nwork, because the value was undefined.\n\nSee: https://gitlab.com/gitlab-org/git/-/jobs/7283724903\n\nThis is why I also decided to fix and change the whitespace check.\n\n>> + rules:\n>> + - if: $CI_PIPELINE_SOURCE == 'merge_request_event'\n>> +\n\n[1]: https://gitlab.com/gitlab-org/git/-/commit/614dff20119aa325661424a9fcef552e242a95d9\n"},{"id":"498325","messageId":"xmqqwmlvcx9g.fsf_-_@gitster.g","threadId":"61750","inReplyTo":"xmqqr0c3hkjs.fsf@gitster.g","subject":"Re* [PATCH 7/8] ci: run style check on GitHub and GitLab","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-07-08T22:52:11Z","receivedAt":"2024-07-08T22:52:21Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> I think the consensus from the last discussion we had was to allow\n> scripts that rely on bash-isms to say \"#!/usr/bin/env bash\" because\n> we know /bin/sh can legitimately be not bash and we assume bash may\n> not be installed as /bin/bash.\n\nLet's do this before we forget.\n\n------- >8 ------------- >8 ------------- >8 -------\nSubject: [PATCH] ci: unify bash calling convention\n\nUnder ci/ hierarchy, we run scripts under either \"sh\" (any Bourne\ncompatible POSIX shell would work) or specifically \"bash\" (as they\nrequire features from bash, e.g., $(parameter/pattern/string}\nexpansion). As we have the CI envionment under our control, we can\nexpect that /bin/sh will always be fine to run the scripts that only\nrequire Bourne, but we may not know where \"bash\" gets installed\ndepending on distros.\n\nSo let's make sure we start these scripts with either one of these:\n\n\t#!/bin/sh\n\t#!/usr/bin/env bash\n\nYes, the latter has to assume that everybody installs \"env\" at that\npath and not as /bin/env or /usr/local/bin/env, but this currently\nis the best we could do.\n\nSigned-off-by: Junio C Hamano \n---\n ci/check-directional-formatting.bash | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/ci/check-directional-formatting.bash b/ci/check-directional-formatting.bash\nindex e6211b141a..3cbbb7030e 100755\n--- a/ci/check-directional-formatting.bash\n+++ b/ci/check-directional-formatting.bash\n@@ -1,4 +1,4 @@\n-#!/bin/bash\n+#!/usr/bin/env bash\n \n # This script verifies that the non-binary files tracked in the Git index do\n # not contain any Unicode directional formatting: such formatting could be used\n-- \n2.45.2-924-g22c02b0a17\n\n"},{"id":"498326","messageId":"pcyr4eb52de67j7idzfklbeg5d5jbfmgkt6loqhkbxppvjvnco@3b2lmbd7nt3b","threadId":"61750","inReplyTo":"xmqqwmlvcx9g.fsf_-_@gitster.g","subject":"Re: Re* [PATCH 7/8] ci: run style check on GitHub and GitLab","fromName":"Justin Tobler","fromEmail":"jltobler@gmail.com","sentAt":"2024-07-08T23:17:43Z","receivedAt":"2024-07-08T23:18:13Z","isPatch":true,"sender":{"key":"jltobler@gmail.com","avatar":"https://avatars.githubusercontent.com/u/53454972?v=4"},"body":"On 24/07/08 03:52PM, Junio C Hamano wrote:\n> Junio C Hamano writes:\n> \n> > I think the consensus from the last discussion we had was to allow\n> > scripts that rely on bash-isms to say \"#!/usr/bin/env bash\" because\n> > we know /bin/sh can legitimately be not bash and we assume bash may\n> > not be installed as /bin/bash.\n> \n> Let's do this before we forget.\n> \n> ------- >8 ------------- >8 ------------- >8 -------\n> Subject: [PATCH] ci: unify bash calling convention\n> \n> Under ci/ hierarchy, we run scripts under either \"sh\" (any Bourne\n> compatible POSIX shell would work) or specifically \"bash\" (as they\n> require features from bash, e.g., $(parameter/pattern/string}\n> expansion). As we have the CI envionment under our control, we can\n\ns/envionment/environment\n\n> expect that /bin/sh will always be fine to run the scripts that only\n> require Bourne, but we may not know where \"bash\" gets installed\n> depending on distros.\n> \n> So let's make sure we start these scripts with either one of these:\n> \n> \t#!/bin/sh\n> \t#!/usr/bin/env bash\n> \n> Yes, the latter has to assume that everybody installs \"env\" at that\n> path and not as /bin/env or /usr/local/bin/env, but this currently\n> is the best we could do.\n\nMakes sense to me to be consistent and I also think `#!/usr/bin/env bash`\nis probably the best route. Other than the small typo this looks good to\nme.\n\n-Justin\n"},{"id":"498332","messageId":"lu7o24bwwh5ntarnpfjkmceuvzxs6rdykcrojonqkhfcvq7vka@7h3rev4n7wxr","threadId":"61750","inReplyTo":"CAOLa=ZTuBziBPY1B0P3gTWMhqThuyFsFW1aWtwUconYN4gH+aA@mail.gmail.com","subject":"Re: [PATCH 7/8] ci: run style check on GitHub and GitLab","fromName":"Justin Tobler","fromEmail":"jltobler@gmail.com","sentAt":"2024-07-09T00:22:48Z","receivedAt":"2024-07-09T00:23:18Z","isPatch":true,"sender":{"key":"jltobler@gmail.com","avatar":"https://avatars.githubusercontent.com/u/53454972?v=4"},"body":"On 24/07/08 02:16PM, Karthik Nayak wrote:\n> Justin Tobler writes:\n> \n> > On 24/07/08 11:23AM, Karthik Nayak wrote:\n> >> We don't run style checks on our CI, even though we have a\n> >> '.clang-format' setup in the repository. Let's add one, the job will\n> >> validate only against the new commits added and will only run on merge\n> >> requests. Since we're introducing it for the first time, let's allow\n> >> this job to fail, so we can validate if this is useful and eventually\n> >> enforce it.\n> >\n> > [snip]\n> >\n> >> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml\n> >> index 37b991e080..65fd261e5e 100644\n> >> --- a/.gitlab-ci.yml\n> >> +++ b/.gitlab-ci.yml\n> >> @@ -123,6 +123,18 @@ check-whitespace:\n> >> rules:\n> >> - if: $CI_PIPELINE_SOURCE == 'merge_request_event'\n> >>\n> >> +check-style:\n> >> + image: ubuntu:latest\n> >> + allow_failure: true\n> >> + variables:\n> >> + CC: clang\n> >> + before_script:\n> >> + - ./ci/install-dependencies.sh\n> >> + script:\n> >> + - ./ci/run-style-check.sh \"$CI_MERGE_REQUEST_DIFF_BASE_SHA\"\n> >\n> > One downside to using $CI_MERGE_REQUEST_DIFF_BASE_SHA is that for GitLab\n> > merge pipeines, commits from the merge that are not part of the MR\n> > changes are also included. This could lead to somewhat confusing\n> > failures.\n> >\n> \n> I'm not sure I follow.\n> \n> > Example failure occuring on this patch series:\n> > https://gitlab.com/gitlab-org/git/-/jobs/7284442220\n> >\n> \n> If you notice this job, it points to the commit: 1c6551488, and the\n> parent commit of that commit is: 614dff2011.\n> \n> The parent commit [1] is a test commit I added to check the failures. So\n> isn't this working as expected?\n\nAh ok, I misunderstood the setup of that CI job, but the problem is\nstill present. Here is an example CI job I've run demonstrating it:\n\nCI - https://gitlab.com/gitlab-org/git/-/jobs/7291829941\nMR - https://gitlab.com/gitlab-org/git/-/merge_requests/174\n\nFor the MR that spawned this CI job, This patch series is the source\nbranch and the target branch is a version of master one commit ahead\ncontaining a clang format error. Because this is a merge pipeline, using \n$CI_MERGE_REQUEST_DIFF_BASE_SHA will include changes from either side of\nthe base commit. This means it would be possible for the CI job to fail\ndue to commits ahead in the target branch, but not in the source branch.\nFor the check-whitespace CI job, I specifically chose \n$CI_MERGE_REQUEST_TARGET_BRANCH_SHA for this reason.j\n\n> \n> > It might be best to use $CI_MERGE_REQUEST_TARGET_BRANCH_SHA instead.\n> >\n> \n> I actually started with $CI_MERGE_REQUEST_TARGET_BRANCH_SHA, it didn't\n> work, because the value was undefined.\n> \n> See: https://gitlab.com/gitlab-org/git/-/jobs/7283724903\n> \n> This is why I also decided to fix and change the whitespace check.\n\nI'm not seeing $CI_MERGE_REQUEST_TARGET_BRANCH_SHA as undefined in the\njob. Here is a modified version on the check-style CI job printing the\nenvironment variables:\n\nhttps://gitlab.com/gitlab-org/git/-/jobs/7291792329#L2470\n\nDo you have an example of the check-whitespace job failing in GitLab CI?\nMaybe I'm missing something, but I don't see a problem.\n\n-Justin\n"},{"id":"498335","messageId":"ZoyK1iZIRVDKQ4-f@tapette.crustytoothpaste.net","threadId":"61750","inReplyTo":"xmqqwmlvcx9g.fsf_-_@gitster.g","subject":"Re: Re* [PATCH 7/8] ci: run style check on GitHub and GitLab","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2024-07-09T00:56:54Z","receivedAt":"2024-07-09T00:56:57Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2024-07-08 at 22:52:11, Junio C Hamano wrote:\n> Subject: [PATCH] ci: unify bash calling convention\n> \n> Under ci/ hierarchy, we run scripts under either \"sh\" (any Bourne\n> compatible POSIX shell would work) or specifically \"bash\" (as they\n> require features from bash, e.g., $(parameter/pattern/string}\n> expansion). As we have the CI envionment under our control, we can\n> expect that /bin/sh will always be fine to run the scripts that only\n> require Bourne, but we may not know where \"bash\" gets installed\n> depending on distros.\n> \n> So let's make sure we start these scripts with either one of these:\n> \n> \t#!/bin/sh\n> \t#!/usr/bin/env bash\n> \n> Yes, the latter has to assume that everybody installs \"env\" at that\n> path and not as /bin/env or /usr/local/bin/env, but this currently\n> is the best we could do.\n\nThis seems sensible. We know that /bin/sh is not POSIX-compatible on\nsome proprietary Unices, but we're not targeting those in CI, and Git\nfor Windows, macOS, and all of the major open-source Linux and BSD\ndistros have /bin/sh as a POSIX-compatible shell.\n\n/usr/bin/env bash is also safer than /bin/bash, because bash is not in\n/usr/bin on most of the BSDs. Every other project I've seen writes\n/usr/bin/env, so I think that's a fairly safe assumption most places,\nand I agree that it's the best we can do.\n\nSo I think is the right move.\n-- \nbrian m. carlson (they/them or he/him)\nToronto, Ontario, CA\n"},{"id":"498348","messageId":"CAOLa=ZQiHcCU9G6BFO98Y1VAPYgTDdJzbWC5bnMQwx9jsTJ0tg@mail.gmail.com","threadId":"61750","inReplyTo":"lu7o24bwwh5ntarnpfjkmceuvzxs6rdykcrojonqkhfcvq7vka@7h3rev4n7wxr","subject":"Re: [PATCH 7/8] ci: run style check on GitHub and GitLab","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-09T08:44:20Z","receivedAt":"2024-07-09T08:44:23Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"Justin Tobler writes:\n\n> On 24/07/08 02:16PM, Karthik Nayak wrote:\n>> Justin Tobler writes:\n>>\n>> > On 24/07/08 11:23AM, Karthik Nayak wrote:\n>> >> We don't run style checks on our CI, even though we have a\n>> >> '.clang-format' setup in the repository. Let's add one, the job will\n>> >> validate only against the new commits added and will only run on merge\n>> >> requests. Since we're introducing it for the first time, let's allow\n>> >> this job to fail, so we can validate if this is useful and eventually\n>> >> enforce it.\n>> >\n>> > [snip]\n>> >\n>> >> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml\n>> >> index 37b991e080..65fd261e5e 100644\n>> >> --- a/.gitlab-ci.yml\n>> >> +++ b/.gitlab-ci.yml\n>> >> @@ -123,6 +123,18 @@ check-whitespace:\n>> >> rules:\n>> >> - if: $CI_PIPELINE_SOURCE == 'merge_request_event'\n>> >>\n>> >> +check-style:\n>> >> + image: ubuntu:latest\n>> >> + allow_failure: true\n>> >> + variables:\n>> >> + CC: clang\n>> >> + before_script:\n>> >> + - ./ci/install-dependencies.sh\n>> >> + script:\n>> >> + - ./ci/run-style-check.sh \"$CI_MERGE_REQUEST_DIFF_BASE_SHA\"\n>> >\n>> > One downside to using $CI_MERGE_REQUEST_DIFF_BASE_SHA is that for GitLab\n>> > merge pipeines, commits from the merge that are not part of the MR\n>> > changes are also included. This could lead to somewhat confusing\n>> > failures.\n>> >\n>>\n>> I'm not sure I follow.\n>>\n>> > Example failure occuring on this patch series:\n>> > https://gitlab.com/gitlab-org/git/-/jobs/7284442220\n>> >\n>>\n>> If you notice this job, it points to the commit: 1c6551488, and the\n>> parent commit of that commit is: 614dff2011.\n>>\n>> The parent commit [1] is a test commit I added to check the failures. So\n>> isn't this working as expected?\n>\n> Ah ok, I misunderstood the setup of that CI job, but the problem is\n> still present. Here is an example CI job I've run demonstrating it:\n>\n> CI - https://gitlab.com/gitlab-org/git/-/jobs/7291829941\n> MR - https://gitlab.com/gitlab-org/git/-/merge_requests/174\n>\n> For the MR that spawned this CI job, This patch series is the source\n> branch and the target branch is a version of master one commit ahead\n> containing a clang format error. Because this is a merge pipeline, using\n> $CI_MERGE_REQUEST_DIFF_BASE_SHA will include changes from either side of\n> the base commit. This means it would be possible for the CI job to fail\n> due to commits ahead in the target branch, but not in the source branch.\n> For the check-whitespace CI job, I specifically chose\n> $CI_MERGE_REQUEST_TARGET_BRANCH_SHA for this reason.j\n>\n\nYou're right indeed. I did some more reading about this and I think the\nsolution lies somewhere in between..\n\n>>\n>> > It might be best to use $CI_MERGE_REQUEST_TARGET_BRANCH_SHA instead.\n>> >\n>>\n>> I actually started with $CI_MERGE_REQUEST_TARGET_BRANCH_SHA, it didn't\n>> work, because the value was undefined.\n>>\n>> See: https://gitlab.com/gitlab-org/git/-/jobs/7283724903\n>>\n>> This is why I also decided to fix and change the whitespace check.\n>\n> I'm not seeing $CI_MERGE_REQUEST_TARGET_BRANCH_SHA as undefined in the\n> job. Here is a modified version on the check-style CI job printing the\n> environment variables:\n>\n\nYou can see the output\n\n $ ./ci/run-style-check.sh \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\"\n fatal: ambiguous argument '': unknown revision or path not in the\nworking tree.\n Use '--' to separate paths from revisions, like this:\n 'git [...] -- [...]'\n\nThis only happens if \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\" is empty.\n\n> https://gitlab.com/gitlab-org/git/-/jobs/7291792329#L2470\n>\n> Do you have an example of the check-whitespace job failing in GitLab CI?\n> Maybe I'm missing something, but I don't see a problem.\n>\n> -Justin\n\nSo I think I get the issue, GitLab has two kinds of pipelines it runs:\n1. merge pipeline: Here the pipeline runs on the source branch (the\nfeature branch which has to be merged).\n2. merged pipeline: Here the pipeline creates a merge commit using the\nsource and target branch and then runs the pipeline on the merged\ncommit.\n\nAnd \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\" is only defined in the 'merged\npipeline'. If you see the pipelines for my branch on GitLab [1]. You'll\nsee only one of them is marked as 'merge results' and the others being\nmarked as 'merged results'. The former includes the job I mentioned\nabove, where \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\" is not defined.\n\nI'm still not sure why it marked only one of the pipelines as such, but\nthis means there is chance that it could happen.\n\nSo I guess the best outcome is to use\n\"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\", but fallback to\n\"$CI_MERGE_REQUEST_DIFF_BASE_SHA\", if the former is not defined.\n\n[1]: https://gitlab.com/gitlab-org/git/-/merge_requests/172/pipelines\n"},{"id":"498366","messageId":"q4mixa3suepyjrp5lkd3wio2pcsdbjch757n2p55fzxpk3sc4u@lysauvdyiq4c","threadId":"61750","inReplyTo":"CAOLa=ZQiHcCU9G6BFO98Y1VAPYgTDdJzbWC5bnMQwx9jsTJ0tg@mail.gmail.com","subject":"Re: [PATCH 7/8] ci: run style check on GitHub and GitLab","fromName":"Justin Tobler","fromEmail":"jltobler@gmail.com","sentAt":"2024-07-09T14:44:28Z","receivedAt":"2024-07-09T14:44:59Z","isPatch":true,"sender":{"key":"jltobler@gmail.com","avatar":"https://avatars.githubusercontent.com/u/53454972?v=4"},"body":"On 24/07/09 01:44AM, Karthik Nayak wrote:\n> Justin Tobler writes:\n> \n> > On 24/07/08 02:16PM, Karthik Nayak wrote:\n> >> Justin Tobler writes:\n> >>\n> >> > On 24/07/08 11:23AM, Karthik Nayak wrote:\n> >> >> We don't run style checks on our CI, even though we have a\n> >> >> '.clang-format' setup in the repository. Let's add one, the job will\n> >> >> validate only against the new commits added and will only run on merge\n> >> >> requests. Since we're introducing it for the first time, let's allow\n> >> >> this job to fail, so we can validate if this is useful and eventually\n> >> >> enforce it.\n> >> >\n> >> > [snip]\n> >> >\n> >> >> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml\n> >> >> index 37b991e080..65fd261e5e 100644\n> >> >> --- a/.gitlab-ci.yml\n> >> >> +++ b/.gitlab-ci.yml\n> >> >> @@ -123,6 +123,18 @@ check-whitespace:\n> >> >> rules:\n> >> >> - if: $CI_PIPELINE_SOURCE == 'merge_request_event'\n> >> >>\n> >> >> +check-style:\n> >> >> + image: ubuntu:latest\n> >> >> + allow_failure: true\n> >> >> + variables:\n> >> >> + CC: clang\n> >> >> + before_script:\n> >> >> + - ./ci/install-dependencies.sh\n> >> >> + script:\n> >> >> + - ./ci/run-style-check.sh \"$CI_MERGE_REQUEST_DIFF_BASE_SHA\"\n> >> >\n> >> > One downside to using $CI_MERGE_REQUEST_DIFF_BASE_SHA is that for GitLab\n> >> > merge pipeines, commits from the merge that are not part of the MR\n> >> > changes are also included. This could lead to somewhat confusing\n> >> > failures.\n> >> >\n> >>\n> >> I'm not sure I follow.\n> >>\n> >> > Example failure occuring on this patch series:\n> >> > https://gitlab.com/gitlab-org/git/-/jobs/7284442220\n> >> >\n> >>\n> >> If you notice this job, it points to the commit: 1c6551488, and the\n> >> parent commit of that commit is: 614dff2011.\n> >>\n> >> The parent commit [1] is a test commit I added to check the failures. So\n> >> isn't this working as expected?\n> >\n> > Ah ok, I misunderstood the setup of that CI job, but the problem is\n> > still present. Here is an example CI job I've run demonstrating it:\n> >\n> > CI - https://gitlab.com/gitlab-org/git/-/jobs/7291829941\n> > MR - https://gitlab.com/gitlab-org/git/-/merge_requests/174\n> >\n> > For the MR that spawned this CI job, This patch series is the source\n> > branch and the target branch is a version of master one commit ahead\n> > containing a clang format error. Because this is a merge pipeline, using\n> > $CI_MERGE_REQUEST_DIFF_BASE_SHA will include changes from either side of\n> > the base commit. This means it would be possible for the CI job to fail\n> > due to commits ahead in the target branch, but not in the source branch.\n> > For the check-whitespace CI job, I specifically chose\n> > $CI_MERGE_REQUEST_TARGET_BRANCH_SHA for this reason.j\n> >\n> \n> You're right indeed. I did some more reading about this and I think the\n> solution lies somewhere in between..\n> \n> >>\n> >> > It might be best to use $CI_MERGE_REQUEST_TARGET_BRANCH_SHA instead.\n> >> >\n> >>\n> >> I actually started with $CI_MERGE_REQUEST_TARGET_BRANCH_SHA, it didn't\n> >> work, because the value was undefined.\n> >>\n> >> See: https://gitlab.com/gitlab-org/git/-/jobs/7283724903\n> >>\n> >> This is why I also decided to fix and change the whitespace check.\n> >\n> > I'm not seeing $CI_MERGE_REQUEST_TARGET_BRANCH_SHA as undefined in the\n> > job. Here is a modified version on the check-style CI job printing the\n> > environment variables:\n> >\n> \n> You can see the output\n> \n> $ ./ci/run-style-check.sh \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\"\n> fatal: ambiguous argument '': unknown revision or path not in the\n> working tree.\n> Use '--' to separate paths from revisions, like this:\n> 'git [...] -- [...]'\n> \n> This only happens if \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\" is empty.\n\nYa I noticed this failure, but was wondering if it was maybe due to\nsomething else. I have been unable to reproduce it and in all the jobs I\nwas running resulted in a merge pipeline with the variable defined. But \nmaybe sometimes a regular pipeline gets run for some reason and \nconsequently $CI_MERGE_REQUEST_TARGET_BRANCH_SHA is not defined? Was the\npipeline triggered directly from the source branch?\n\n> \n> > https://gitlab.com/gitlab-org/git/-/jobs/7291792329#L2470\n> >\n> > Do you have an example of the check-whitespace job failing in GitLab CI?\n> > Maybe I'm missing something, but I don't see a problem.\n> >\n> > -Justin\n> \n> So I think I get the issue, GitLab has two kinds of pipelines it runs:\n> 1. merge pipeline: Here the pipeline runs on the source branch (the\n> feature branch which has to be merged).\n> 2. merged pipeline: Here the pipeline creates a merge commit using the\n> source and target branch and then runs the pipeline on the merged\n> commit.\n> \n\nCorrect, this is my understanding.\n\n> And \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\" is only defined in the 'merged\n> pipeline'. If you see the pipelines for my branch on GitLab [1]. You'll\n> see only one of them is marked as 'merge results' and the others being\n> marked as 'merged results'. The former includes the job I mentioned\n> above, where \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\" is not defined.\n> \n> I'm still not sure why it marked only one of the pipelines as such, but\n> this means there is chance that it could happen.\n\nHuh, I'm guessing the CI job must have been triggered from the source\nbranch directly. Did you manually run the CI job? I wonder if that could\nhave caused it.\n\n> \n> So I guess the best outcome is to use\n> \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\", but fallback to\n> \"$CI_MERGE_REQUEST_DIFF_BASE_SHA\", if the former is not defined.\n\nThis is exactly what I think we should do too. For merge pipelines we \nwill want to use $CI_MERGE_REQUEST_TARGET_BRANCH_SHA so that only the \ncommits included in the MR are scanned in CI. If that variable is not \ndefined, it makes sense to fallback to $CI_MERGE_REQUEST_DIFF_BASE_SHA.\nSince it's not a merge pipeline it will only scan commits included from\nthe MR and therefore work as expected.\n\nThis should handle both cases correctly. :)\n\n-Justin\n\n"},{"id":"498445","messageId":"CAOLa=ZTkA8jP8MD-pt-OXb-SdzkL=ByC4bsUyuvMBD3DO4zEgQ@mail.gmail.com","threadId":"61750","inReplyTo":"CAPig+cRvz7ctW8K7QbZyDSTTG_qxdU9uRmJYrXPW64OuydH4VA@mail.gmail.com","subject":"Re: [PATCH 6/8] clang-format: formalize some of the spacing rules","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-10T13:36:47Z","receivedAt":"2024-07-10T13:36:48Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"Eric Sunshine writes:\n\n> On Mon, Jul 8, 2024 at 5:24 AM Karthik Nayak wrote:\n>> There are some spacing rules that we follow in the project and it makes\n>> sen to formalize them:\n>\n> Since nobody else pointed it out: s/sen/sense/\n\nWill fix in v2.\n"},{"id":"498446","messageId":"CAOLa=ZQZchY=1crbF8xjZknJkJ1feeR80Swk0k7TR530Gw_6FA@mail.gmail.com","threadId":"61750","inReplyTo":"q4mixa3suepyjrp5lkd3wio2pcsdbjch757n2p55fzxpk3sc4u@lysauvdyiq4c","subject":"Re: [PATCH 7/8] ci: run style check on GitHub and GitLab","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-10T13:38:36Z","receivedAt":"2024-07-10T13:38:37Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"Justin Tobler writes:\n\n[snip]\n\n>>\n>> You can see the output\n>>\n>> $ ./ci/run-style-check.sh \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\"\n>> fatal: ambiguous argument '': unknown revision or path not in the\n>> working tree.\n>> Use '--' to separate paths from revisions, like this:\n>> 'git [...] -- [...]'\n>>\n>> This only happens if \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\" is empty.\n>\n> Ya I noticed this failure, but was wondering if it was maybe due to\n> something else. I have been unable to reproduce it and in all the jobs I\n> was running resulted in a merge pipeline with the variable defined. But\n> maybe sometimes a regular pipeline gets run for some reason and\n> consequently $CI_MERGE_REQUEST_TARGET_BRANCH_SHA is not defined? Was the\n> pipeline triggered directly from the source branch?\n>\n\nJust a regular push. Not sure at all why this happened. I was testing\ndifferent types of style issues on the CI and this happened once.\n\n>>\n>> > https://gitlab.com/gitlab-org/git/-/jobs/7291792329#L2470\n>> >\n>> > Do you have an example of the check-whitespace job failing in GitLab CI?\n>> > Maybe I'm missing something, but I don't see a problem.\n>> >\n>> > -Justin\n>>\n>> So I think I get the issue, GitLab has two kinds of pipelines it runs:\n>> 1. merge pipeline: Here the pipeline runs on the source branch (the\n>> feature branch which has to be merged).\n>> 2. merged pipeline: Here the pipeline creates a merge commit using the\n>> source and target branch and then runs the pipeline on the merged\n>> commit.\n>>\n>\n> Correct, this is my understanding.\n>\n>> And \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\" is only defined in the 'merged\n>> pipeline'. If you see the pipelines for my branch on GitLab [1]. You'll\n>> see only one of them is marked as 'merge results' and the others being\n>> marked as 'merged results'. The former includes the job I mentioned\n>> above, where \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\" is not defined.\n>>\n>> I'm still not sure why it marked only one of the pipelines as such, but\n>> this means there is chance that it could happen.\n>\n> Huh, I'm guessing the CI job must have been triggered from the source\n> branch directly. Did you manually run the CI job? I wonder if that could\n> have caused it.\n>\n\nNot that I remember.\n\n>>\n>> So I guess the best outcome is to use\n>> \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\", but fallback to\n>> \"$CI_MERGE_REQUEST_DIFF_BASE_SHA\", if the former is not defined.\n>\n> This is exactly what I think we should do too. For merge pipelines we\n> will want to use $CI_MERGE_REQUEST_TARGET_BRANCH_SHA so that only the\n> commits included in the MR are scanned in CI. If that variable is not\n> defined, it makes sense to fallback to $CI_MERGE_REQUEST_DIFF_BASE_SHA.\n> Since it's not a merge pipeline it will only scan commits included from\n> the MR and therefore work as expected.\n>\n> This should handle both cases correctly. :)\n>\n> -Justin\n\nYeah seems like the best solution at this point, let me implement this.\n"},{"id":"498450","messageId":"CAOLa=ZQdPTnLp63eFiq1oOkgukBGsug==Cam0hGW_9koCefhGA@mail.gmail.com","threadId":"61750","inReplyTo":"xmqqbk37hjma.fsf@gitster.g","subject":"Re: [PATCH 8/8] check-whitespace: detect if no base_commit is provided","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-10T14:06:25Z","receivedAt":"2024-07-10T14:06:27Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"Junio C Hamano writes:\n\n> Karthik Nayak writes:\n>\n>> The 'check-whitespace' CI script exists gracefully if no base commit is\n>\n> \"exists\" -> \"exits\"\n>\n\nWill fix.\n\n>> provided or if an invalid revision is provided...\n>> ...\n>> Let's fix the variable used in the GitLab CI. Let's also add a check for\n>> incorrect base_commit in the 'check-whitespace.sh' script. While here,\n>> fix a small typo too.\n>>\n>> [1]: https://docs.gitlab.com/ee/ci/variables/predefined_variables.html#predefined-variables-for-merge-request-pipelines\n>>\n>> Signed-off-by: Karthik Nayak \n>> ---\n>> .gitlab-ci.yml | 2 +-\n>> ci/check-whitespace.sh | 13 ++++++++++---\n>> 2 files changed, 11 insertions(+), 4 deletions(-)\n>>\n>> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml\n>> index 65fd261e5e..36199893d8 100644\n>> --- a/.gitlab-ci.yml\n>> +++ b/.gitlab-ci.yml\n>> @@ -119,7 +119,7 @@ check-whitespace:\n>> before_script:\n>> - ./ci/install-dependencies.sh\n>> script:\n>> - - ./ci/check-whitespace.sh \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\"\n>> + - ./ci/check-whitespace.sh \"$CI_MERGE_REQUEST_DIFF_BASE_SHA\"\n>> rules:\n>> - if: $CI_PIPELINE_SOURCE == 'merge_request_event'\n>>\n>> diff --git a/ci/check-whitespace.sh b/ci/check-whitespace.sh\n>> index db399097a5..ab023f9519 100755\n>> --- a/ci/check-whitespace.sh\n>> +++ b/ci/check-whitespace.sh\n>> @@ -9,12 +9,19 @@ baseCommit=$1\n>> outputFile=$2\n>> url=$3\n>>\n>> -if test \"$#\" -ne 1 && test \"$#\" -ne 3\n>> +if { test \"$#\" -ne 1 && test \"$#\" -ne 3; } || test -z \"$1\"\n>\n> You can just add || test -z \"$1\" after the existing one, making the\n> thing A && B || C which evaulates left to right with the same\n> precedence for && and ||.\n>\n\nWell, I prefer making it explicit so one does not have to remember the\nprecedence ordering, but it could just be my lack of shell knowledge.\nI'm okay with this change, I'll add it in the next version.\n\n>> then\n>> \techo \"USAGE: $0 [ ]\"\n>> \texit 1\n>> fi\n>>\n>> +gitLogOutput=$(git log --check --pretty=format:\"---% h% s\" \"${baseCommit}\"..)\n>\n> That is a large string to hold in a variable for a potentially large\n> series with lots of breakages. I didn't quite read the reasoning\n> behind this change in the proposed log message. Under what\n> condition do you expect the command to exit with non-zero status?\n> $basecommit being a non-empty string but does not name a valid\n> commit object or something, in which case shouldn't \"git log\n> --oneline $baseCommit..\" or something simpler should suffice?\n>\n\nYeah, makes sense. I think I'll simply add in\n\n if ! git rev-parse --quiet --verify \"${baseCommit}\"\n then\n echo \"Invalid '${baseCommit}'\"\n exit 1\n fi\n\ninstead\n\n>> +if test $? -ne 0\n>> +then\n>> +\techo -n $gitLogOutput\n>\n> What is \"-n\" doing here? Why are you squashing run of spaces in the\n> $gitLogOutput variable into a space by not \"quoting\" inside a dq-pair?\n>\n\nI actually didn't know about this. Thanks for informing.\n\n>> +\texit 1\n>> +fi\n>\n> Looking for \"--check\" in\n>\n> \t$ git log --help\n>\n> tells me that the command exits with non-zero status if problems are\n> found, so wouldn't that mean the cases with problems always exit\n> early, bypassing the while loop with full of bash-ism that comes\n> after this block?\n>\n\nIt should exist with a non-zero code, but since we're capturing it in\nthe while loop, it doesn't stop the slow. A consequence of which is that\nit'll print the stderr from the `git log` failing, but the script itself\nwill still exit with a zero exit code. This marks a success on the CI.\n\n>> problems=()\n>> commit=\n>> commitText=\n>> @@ -58,7 +65,7 @@ do\n>> \t\techo \"${dash} ${sha} ${etc}\"\n>> \t\t;;\n>> \tesac\n>> -done <<< \"$(git log --check --pretty=format:\"---% h% s\" \"${baseCommit}\"..)\"\n>> +done <<< \"$gitLogOutput\"\n>>\n>> if test ${#problems[*]} -gt 0\n>> then\n>> @@ -67,7 +74,7 @@ then\n>> \t\tgoodParent=${baseCommit: 0:7}\n>> \tfi\n>>\n>> -\techo \"A whitespace issue was found in onen of more of the commits.\"\n>> +\techo \"A whitespace issue was found in one of more of the commits.\"\n>> \techo \"Run the following command to resolve whitespace issues:\"\n>> \techo \"git rebase --whitespace=fix ${goodParent}\"\n"},{"id":"498451","messageId":"CAOLa=ZRHq4WarzBiNu9gxWxT=Fe8D0TZ00pLngXuqFUZf1j==w@mail.gmail.com","threadId":"61750","inReplyTo":"tl66b35ytbri4dep3cnppdexebblep6avyuhj4moc4mnsolnp2@xpqqwyl4oo2y","subject":"Re: [PATCH 8/8] check-whitespace: detect if no base_commit is provided","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-10T14:12:22Z","receivedAt":"2024-07-10T14:12:24Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"Justin Tobler writes:\n\n> On 24/07/08 11:23AM, Karthik Nayak wrote:\n>> The 'check-whitespace' CI script exists gracefully if no base commit is\n>> provided or if an invalid revision is provided. This is not good because\n>> if a particular CI provides an incorrect base_commit, it would fail\n>> successfully.\n>\n> s/exists/exits\n>\n> If no base commit is provided, we already fail. Here is an example\n> GitLab CI job demonstrating this:\n> https://gitlab.com/gitlab-org/git/-/jobs/7289543498#L2370\n>\n> If the base commit does not exist though, it currently prints that error occured\n> but still exits with 0. Makes sense to update and fail the job accordingly.\n>\n\nThis example is running on the 'edb990d9', whose parent's '8d9bcf0a'\nparent '57fdb00c' contains my changes, specifically the `|| test -z \"$1\"`\nsection. You can check this on master locally though.\n\n $ ./ci/check-whitespace.sh \"\"\n fatal: ..: '..' is outside repository at '/home/karthik/git'\n\n $ echo $?\n 0\n\nor for invalid value:\n\n $ ./ci/check-whitespace.sh \"random\"\n fatal: ambiguous argument 'random..': unknown revision or path not\nin the working tree.\n Use '--' to separate paths from revisions, like this:\n 'git [...] -- [...]'\n\n $ echo $status\n 0\n\n[snip]\n\n>\n> I might be misunderstanding, but this additional check seems redundant to me.\n>\n\nIt is required, as commented above\n\n>> then\n>> \techo \"USAGE: $0 [ ]\"\n>> \texit 1\n>> fi\n>>\n>> +gitLogOutput=$(git log --check --pretty=format:\"---% h% s\" \"${baseCommit}\"..)\n>> +if test $? -ne 0\n>> +then\n>> +\techo -n $gitLogOutput\n>> +\texit 1\n>> +fi\n>> +\n>> problems=()\n>> commit=\n>> commitText=\n>> @@ -58,7 +65,7 @@ do\n>> \t\techo \"${dash} ${sha} ${etc}\"\n>> \t\t;;\n>> \tesac\n>> -done <<< \"$(git log --check --pretty=format:\"---% h% s\" \"${baseCommit}\"..)\"\n>> +done <<< \"$gitLogOutput\"\n>>\n>> if test ${#problems[*]} -gt 0\n>> then\n>> @@ -67,7 +74,7 @@ then\n>> \t\tgoodParent=${baseCommit: 0:7}\n>> \tfi\n>>\n>> -\techo \"A whitespace issue was found in onen of more of the commits.\"\n>> +\techo \"A whitespace issue was found in one of more of the commits.\"\n> There is another preexisting typo:\n>\n> s/one of/one or/\n>\n\nThanks. will add\n"},{"id":"498466","messageId":"xmqq8qy9z14t.fsf@gitster.g","threadId":"61750","inReplyTo":"CAOLa=ZQdPTnLp63eFiq1oOkgukBGsug==Cam0hGW_9koCefhGA@mail.gmail.com","subject":"Re: [PATCH 8/8] check-whitespace: detect if no base_commit is provided","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-07-10T16:02:10Z","receivedAt":"2024-07-10T16:02:14Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Karthik Nayak writes:\n\n> Yeah, makes sense. I think I'll simply add in\n>\n> if ! git rev-parse --quiet --verify \"${baseCommit}\"\n> then\n> echo \"Invalid '${baseCommit}'\"\n> exit 1\n> fi\n\nIt would make the intent a lot clearer. Good.\n\n>>> +if test $? -ne 0\n>>> +then\n>>> +\techo -n $gitLogOutput\n>>\n>> What is \"-n\" doing here? Why are you squashing run of spaces in the\n>> $gitLogOutput variable into a space by not \"quoting\" inside a dq-pair?\n>>\n>\n> I actually didn't know about this. Thanks for informing.\n>\n>>> +\texit 1\n>>> +fi\n>>\n>> Looking for \"--check\" in\n>>\n>> \t$ git log --help\n>>\n>> tells me that the command exits with non-zero status if problems are\n>> found, so wouldn't that mean the cases with problems always exit\n>> early, bypassing the while loop with full of bash-ism that comes\n>> after this block?\n>>\n>\n> It should exist with a non-zero code, but since we're capturing it in\n> the while loop, it doesn't stop the slow.\n\nSorry, but I am confused. The control would not even reach a \"while\nloop\", I am afraid.\n\nI was commenting on the exit status check done here:\n\n +gitLogOutput=$(git log --check --pretty=format:\"---% h% s\" \"${baseCommit}\"..)\n +if test $? -ne 0\n +then\n +\techo -n $gitLogOutput\n +\texit 1\n +fi\n\nEven though the output is captured in a variable, the exit status of\n\"git log --check\" is still seen by the shell and \"if test $? = 0\"\nnext line say \"ah, the thing exited with non-zero status so lets\necho the whole thing and exit with 1\", before it gets to the while\nloop we have below the above piece of code, no?\n\n\n"},{"id":"498492","messageId":"CAOLa=ZSUZGqxHbEtpR3fadOFf=YPVxbo8W7SwyB9j5am14EB7A@mail.gmail.com","threadId":"61750","inReplyTo":"xmqq8qy9z14t.fsf@gitster.g","subject":"Re: [PATCH 8/8] check-whitespace: detect if no base_commit is provided","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-11T08:27:41Z","receivedAt":"2024-07-11T08:27:43Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"Junio C Hamano writes:\n\n> Karthik Nayak writes:\n>\n>> Yeah, makes sense. I think I'll simply add in\n>>\n>> if ! git rev-parse --quiet --verify \"${baseCommit}\"\n>> then\n>> echo \"Invalid '${baseCommit}'\"\n>> exit 1\n>> fi\n>\n> It would make the intent a lot clearer. Good.\n>\n>>>> +if test $? -ne 0\n>>>> +then\n>>>> +\techo -n $gitLogOutput\n>>>\n>>> What is \"-n\" doing here? Why are you squashing run of spaces in the\n>>> $gitLogOutput variable into a space by not \"quoting\" inside a dq-pair?\n>>>\n>>\n>> I actually didn't know about this. Thanks for informing.\n>>\n>>>> +\texit 1\n>>>> +fi\n>>>\n>>> Looking for \"--check\" in\n>>>\n>>> \t$ git log --help\n>>>\n>>> tells me that the command exits with non-zero status if problems are\n>>> found, so wouldn't that mean the cases with problems always exit\n>>> early, bypassing the while loop with full of bash-ism that comes\n>>> after this block?\n>>>\n>>\n>> It should exist with a non-zero code, but since we're capturing it in\n>> the while loop, it doesn't stop the slow.\n>\n> Sorry, but I am confused. The control would not even reach a \"while\n> loop\", I am afraid.\n>\n> I was commenting on the exit status check done here:\n>\n> +gitLogOutput=$(git log --check --pretty=format:\"---% h% s\" \"${baseCommit}\"..)\n> +if test $? -ne 0\n> +then\n> +\techo -n $gitLogOutput\n> +\texit 1\n> +fi\n>\n> Even though the output is captured in a variable, the exit status of\n> \"git log --check\" is still seen by the shell and \"if test $? = 0\"\n> next line say \"ah, the thing exited with non-zero status so lets\n> echo the whole thing and exit with 1\", before it gets to the while\n> loop we have below the above piece of code, no?\n\nMy bad, I thought you were referring to the code before my changes. Yes,\nhere you're right, we don't need the check since the shell would capture\nthe non-zero status.\n"},{"id":"498493","messageId":"20240711083043.1732288-1-karthik.188@gmail.com","threadId":"61750","inReplyTo":"20240708092317.267915-1-karthik.188@gmail.com","subject":"[PATCH v2 0/8] clang-format: add more rules and enable on CI","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-11T08:30:35Z","receivedAt":"2024-07-11T08:30:48Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"This is v2 of my series to add clang-format to the CI.\n\nThe series was mostly inspired by a patch sent recently to 'include\nkh_foreach* macros in ForEachMacros' [1]. I was wondering why we don't\nrun the formatting on CI and reduce some of the workload of reviewers.\n\nWe have a '.clang-format' file to provide rules for code formatting.\nThe commits 1-6 aims to add more rules to the file while deprecating old\nones.\n\nCommit 7 enables CI action on GitHub and GitLab to also check for the\ncode formatting. Currently, it is allowed to fail. This way we can build\nconfidence and fine tune the values as needed and finally enforce the\ncheck in a future patch. I'm not well versed with GitHub workflows, and\nI mostly tried to copy existing work there. Expecting some feedback in\nthat section!\n\nCommit 8 fixes an existing issue with the 'check-whitespace' job, which\nis failing as success in the GitLab CI.\n\n1: https://lore.kernel.org/git/4e7893f5-2dd9-46cf-8a64-cf780f4e1730@web.de/\n\nChanges against v1:\n* Fixed a lot of typos.\n* Added more details about the warnings specified by clang-format for\n'RemoveBracesLLVM' in commit 5. Added more details too.\n* The last two commits were modified to use \"CI_MERGE_REQUEST_TARGET_BRANCH_SHA\"\nand fallback to \"CI_MERGE_REQUEST_DIFF_BASE_SHA\" if the former is not\navailable in GitLab's CI.\n* Use `!/bin/sh` for the run-style-check script.\n* Modified the last commit to remove block around the && check in the\nwhitespace script.\n* Use `git rev-parse --verify --quiet` to verify the base commit.\n\n\nKarthik Nayak (8):\n clang-format: indent preprocessor directives after hash\n clang-format: avoid spacing around bitfield colon\n clang-format: ensure files end with newlines\n clang-format: replace deprecated option with 'SpacesInParens'\n clang-format: avoid braces on simple single-statement bodies\n clang-format: formalize some of the spacing rules\n ci: run style check on GitHub and GitLab\n check-whitespace: detect if no base_commit is provided\n\n .clang-format | 42 +++++++++++++++++++++++++++----\n .github/workflows/check-style.yml | 29 +++++++++++++++++++++\n .gitlab-ci.yml | 24 +++++++++++++++++-\n ci/check-whitespace.sh | 10 ++++++--\n ci/install-dependencies.sh | 2 +-\n ci/run-style-check.sh | 8 ++++++\n 6 files changed, 106 insertions(+), 9 deletions(-)\n create mode 100644 .github/workflows/check-style.yml\n create mode 100755 ci/run-style-check.sh\n\nRange-diff against v1:\n1: 6cf91ffc86 = 1: 6cf91ffc86 clang-format: indent preprocessor directives after hash\n2: beb002885f = 2: beb002885f clang-format: avoid spacing around bitfield colon\n3: 3031be43e7 = 3: 3031be43e7 clang-format: ensure files end with newlines\n4: bc1550e300 = 4: bc1550e300 clang-format: replace deprecated option with 'SpacesInParens'\n5: cb6097aa22 ! 5: 840318a4c9 clang-format: avoid braces on simple single-statement bodies\n @@ Commit message\n Set the 'RemoveBracesLLVM' to 'true' which ensures that we avoid curly\n braces for single-statement bodies in conditional blocks.\n \n + This option does come with two warnings:\n +\n + This option will be renamed and expanded to support other styles.\n +\n + and\n +\n + Setting this option to true could lead to incorrect code formatting\n + due to clang-format’s lack of complete semantic information. As\n + such, extra care should be taken to review code changes made by\n + this option.\n +\n + The latter seems to be of concern. But since we only use clang-format to\n + verify the format and not to apply formatting, we should be okay here.\n +\n Signed-off-by: Karthik Nayak \n \n ## .clang-format ##\n @@ .clang-format: IndentWrappedFunctionNames: false\n PointerAlignment: Right\n \n +# Remove optional braces of control statements (if, else, for, and while)\n -+# according to the LLVM coding style\n -+# This avoids braces on simple single-statement bodies of statements.\n ++# according to the LLVM coding style. This avoids braces on simple\n ++# single-statement bodies of statements but keeps braces if one side of\n ++# if/else if/.../else cascade has multi-statement body.\n +RemoveBracesLLVM: true\n +\n # Don't insert a space after a cast\n6: c4b6e1e82f ! 6: 0ecfd8d24b clang-format: formalize some of the spacing rules\n @@ Commit message\n clang-format: formalize some of the spacing rules\n \n There are some spacing rules that we follow in the project and it makes\n - sen to formalize them:\n + sense to formalize them:\n * Ensure there is no space inserted after the logical not '!' operator.\n - * Ensure there is no space before the case statement's color.\n + * Ensure there is no space before the case statement's colon.\n * Ensure there is no space before the first bracket '[' of an array.\n * Ensure there is no space in empty blocks.\n \n7: 37f1e5c702 ! 7: 11a9ac4935 ci: run style check on GitHub and GitLab\n @@ Commit message\n this job to fail, so we can validate if this is useful and eventually\n enforce it.\n \n + For GitLab, we use the 'CI_MERGE_REQUEST_TARGET_BRANCH_SHA' variable by\n + default to obtain the base SHA of the merged pipeline (which is only\n + available for merged pipelines [1]). Otherwise we use the\n + 'CI_MERGE_REQUEST_DIFF_BASE_SHA' variable.\n +\n + [1]: https://docs.gitlab.com/ee/ci/variables/predefined_variables.html#predefined-variables-for-merge-request-pipelines\n +\n Signed-off-by: Karthik Nayak \n \n ## .github/workflows/check-style.yml (new) ##\n @@ .gitlab-ci.yml: check-whitespace:\n + before_script:\n + - ./ci/install-dependencies.sh\n + script:\n -+ - ./ci/run-style-check.sh \"$CI_MERGE_REQUEST_DIFF_BASE_SHA\"\n ++ - |\n ++ if [ -z ${CI_MERGE_REQUEST_TARGET_BRANCH_SHA} ]; then\n ++ ./ci/run-style-check.sh \"$CI_MERGE_REQUEST_DIFF_BASE_SHA\"\n ++ else\n ++ ./ci/run-style-check.sh \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\"\n ++ fi\n + rules:\n + - if: $CI_PIPELINE_SOURCE == 'merge_request_event'\n +\n @@ ci/install-dependencies.sh: ubuntu-*)\n \n ## ci/run-style-check.sh (new) ##\n @@\n -+#!/usr/bin/env sh\n ++#!/bin/sh\n +#\n +# Perform style check\n +#\n8: c6d07402af < -: ---------- check-whitespace: detect if no base_commit is provided\n-: ---------- > 8: caccbf8264 check-whitespace: detect if no base_commit is provided\n-- \n2.45.1\n\n"},{"id":"498494","messageId":"20240711083043.1732288-2-karthik.188@gmail.com","threadId":"61750","inReplyTo":"20240711083043.1732288-1-karthik.188@gmail.com","subject":"[PATCH v2 1/8] clang-format: indent preprocessor directives after hash","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-11T08:30:36Z","receivedAt":"2024-07-11T08:30:49Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"We do not have a rule around the indentation of preprocessor directives.\nThis was also discussed on the list [1], noting how there is often\ninconsistency in the styling. While there was discussion, there was no\nconclusion around what is the preferred style here. One style being\nindenting after the hash:\n\n #if FOO\n # if BAR\n # include \n # endif\n #endif\n\nThe other being before the hash:\n\n #if FOO\n #if BAR\n #include \n #endif\n #endif\n\nLet's pick the former and add 'IndentPPDirectives: AfterHash' value to\nour '.clang-format'. There is no clear reason to pick one over the\nother, but it would definitely be nicer to be consistent.\n\n[1]: https://lore.kernel.org/r/xmqqwmmm1bw6.fsf@gitster.g\n\nSigned-off-by: Karthik Nayak \n---\n .clang-format | 6 ++++++\n 1 file changed, 6 insertions(+)\n\ndiff --git a/.clang-format b/.clang-format\nindex 3ed4fac753..5e128519bf 100644\n--- a/.clang-format\n+++ b/.clang-format\n@@ -96,6 +96,12 @@ BreakStringLiterals: false\n # Switch statement body is always indented one level more than case labels.\n IndentCaseLabels: false\n \n+# Indents directives before the hash.\n+# #if FOO\n+# # include \n+# #endif\n+IndentPPDirectives: AfterHash\n+\n # Don't indent a function definition or declaration if it is wrapped after the\n # type\n IndentWrappedFunctionNames: false\n-- \n2.45.1\n\n"},{"id":"498495","messageId":"20240711083043.1732288-3-karthik.188@gmail.com","threadId":"61750","inReplyTo":"20240711083043.1732288-1-karthik.188@gmail.com","subject":"[PATCH v2 2/8] clang-format: avoid spacing around bitfield colon","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-11T08:30:37Z","receivedAt":"2024-07-11T08:30:50Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"The spacing around colons is currently not standardized and as such we\nhave the following practices in our code base:\n- Spacing around the colon `int bf : 1`: 146 instances\n- No spacing around the colon `int bf:1`: 148 instances\n- Spacing before the colon `int bf :1`: 6 instances\n- Spacing after the colon `int bf: 1`: 12 instances\n\nLet's formalize this by picking the most followed pattern and add the\ncorresponding style to '.clang-format'.\n\nSigned-off-by: Karthik Nayak \n---\n .clang-format | 4 ++++\n 1 file changed, 4 insertions(+)\n\ndiff --git a/.clang-format b/.clang-format\nindex 5e128519bf..803b274dd5 100644\n--- a/.clang-format\n+++ b/.clang-format\n@@ -72,6 +72,10 @@ AlwaysBreakAfterReturnType: None\n BinPackArguments: true\n BinPackParameters: true\n \n+# Add no space around the bit field\n+# unsigned bf:2;\n+BitFieldColonSpacing: None\n+\n # Attach braces to surrounding context except break before braces on function\n # definitions.\n # void foo()\n-- \n2.45.1\n\n"},{"id":"498496","messageId":"20240711083043.1732288-4-karthik.188@gmail.com","threadId":"61750","inReplyTo":"20240711083043.1732288-1-karthik.188@gmail.com","subject":"[PATCH v2 3/8] clang-format: ensure files end with newlines","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-11T08:30:38Z","receivedAt":"2024-07-11T08:30:51Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"All our source files end with a newline, let's formalize in\n'.clang-format'.\n\nSigned-off-by: Karthik Nayak \n---\n .clang-format | 3 +++\n 1 file changed, 3 insertions(+)\n\ndiff --git a/.clang-format b/.clang-format\nindex 803b274dd5..4c9751a9db 100644\n--- a/.clang-format\n+++ b/.clang-format\n@@ -106,6 +106,9 @@ IndentCaseLabels: false\n # #endif\n IndentPPDirectives: AfterHash\n \n+# Insert a newline at end of file if missing\n+InsertNewlineAtEOF: true\n+\n # Don't indent a function definition or declaration if it is wrapped after the\n # type\n IndentWrappedFunctionNames: false\n-- \n2.45.1\n\n"},{"id":"498497","messageId":"20240711083043.1732288-5-karthik.188@gmail.com","threadId":"61750","inReplyTo":"20240711083043.1732288-1-karthik.188@gmail.com","subject":"[PATCH v2 4/8] clang-format: replace deprecated option with 'SpacesInParens'","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-11T08:30:39Z","receivedAt":"2024-07-11T08:30:52Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"Replace the deprecated options 'SpacesInParentheses' and\n'SpaceInEmptyParentheses' with the newer 'SpacesInParens' option. The\nusage is the same.\n\nSigned-off-by: Karthik Nayak \n---\n .clang-format | 9 ++++-----\n 1 file changed, 4 insertions(+), 5 deletions(-)\n\ndiff --git a/.clang-format b/.clang-format\nindex 4c9751a9db..914254a29b 100644\n--- a/.clang-format\n+++ b/.clang-format\n@@ -134,8 +134,6 @@ SpaceBeforeAssignmentOperators: true\n # }\n SpaceBeforeParens: ControlStatements\n \n-# Don't insert spaces inside empty '()'\n-SpaceInEmptyParentheses: false\n \n # The number of spaces before trailing line comments (// - comments).\n # This does not affect trailing block comments (/* - comments).\n@@ -149,9 +147,10 @@ SpacesInCStyleCastParentheses: false\n # var arr = [1, 2, 3]; not var arr = [ 1, 2, 3 ];\n SpacesInContainerLiterals: false\n \n-# Don't insert spaces after '(' or before ')'\n-# f(arg); not f( arg );\n-SpacesInParentheses: false\n+SpacesInParens: Custom\n+SpacesInParensOptions:\n+ # Don't insert spaces inside empty '()'\n+ InEmptyParentheses: false\n \n # Don't insert spaces after '[' or before ']'\n # int a[5]; not int a[ 5 ];\n-- \n2.45.1\n\n"},{"id":"498498","messageId":"20240711083043.1732288-6-karthik.188@gmail.com","threadId":"61750","inReplyTo":"20240711083043.1732288-1-karthik.188@gmail.com","subject":"[PATCH v2 5/8] clang-format: avoid braces on simple single-statement bodies","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-11T08:30:40Z","receivedAt":"2024-07-11T08:30:53Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"Set the 'RemoveBracesLLVM' to 'true' which ensures that we avoid curly\nbraces for single-statement bodies in conditional blocks.\n\nThis option does come with two warnings:\n\n This option will be renamed and expanded to support other styles.\n\nand\n\n Setting this option to true could lead to incorrect code formatting\n due to clang-format’s lack of complete semantic information. As\n such, extra care should be taken to review code changes made by\n this option.\n\nThe latter seems to be of concern. But since we only use clang-format to\nverify the format and not to apply formatting, we should be okay here.\n\nSigned-off-by: Karthik Nayak \n---\n .clang-format | 6 ++++++\n 1 file changed, 6 insertions(+)\n\ndiff --git a/.clang-format b/.clang-format\nindex 914254a29b..8b75dece80 100644\n--- a/.clang-format\n+++ b/.clang-format\n@@ -117,6 +117,12 @@ IndentWrappedFunctionNames: false\n # int *a;\n PointerAlignment: Right\n \n+# Remove optional braces of control statements (if, else, for, and while)\n+# according to the LLVM coding style. This avoids braces on simple\n+# single-statement bodies of statements but keeps braces if one side of\n+# if/else if/.../else cascade has multi-statement body.\n+RemoveBracesLLVM: true\n+\n # Don't insert a space after a cast\n # x = (int32)y; not x = (int32) y;\n SpaceAfterCStyleCast: false\n-- \n2.45.1\n\n"},{"id":"498499","messageId":"20240711083043.1732288-7-karthik.188@gmail.com","threadId":"61750","inReplyTo":"20240711083043.1732288-1-karthik.188@gmail.com","subject":"[PATCH v2 6/8] clang-format: formalize some of the spacing rules","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-11T08:30:41Z","receivedAt":"2024-07-11T08:30:54Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"There are some spacing rules that we follow in the project and it makes\nsense to formalize them:\n* Ensure there is no space inserted after the logical not '!' operator.\n* Ensure there is no space before the case statement's colon.\n* Ensure there is no space before the first bracket '[' of an array.\n* Ensure there is no space in empty blocks.\n\nSigned-off-by: Karthik Nayak \n---\n .clang-format | 14 ++++++++++++++\n 1 file changed, 14 insertions(+)\n\ndiff --git a/.clang-format b/.clang-format\nindex 8b75dece80..68c10f03da 100644\n--- a/.clang-format\n+++ b/.clang-format\n@@ -127,11 +127,18 @@ RemoveBracesLLVM: true\n # x = (int32)y; not x = (int32) y;\n SpaceAfterCStyleCast: false\n \n+# No space is inserted after the logical not operator\n+SpaceAfterLogicalNot: false\n+\n # Insert spaces before and after assignment operators\n # int a = 5; not int a=5;\n # a += 42; a+=42;\n SpaceBeforeAssignmentOperators: true\n \n+# Spaces will be removed before case colon.\n+# case 1: break; not case 1 : break;\n+SpaceBeforeCaseColon: false\n+\n # Put a space before opening parentheses only after control statement keywords.\n # void f() {\n # if (true) {\n@@ -140,6 +147,13 @@ SpaceBeforeAssignmentOperators: true\n # }\n SpaceBeforeParens: ControlStatements\n \n+# No space before first '[' in arrays\n+# int a[5][5]; not int a [5][5];\n+SpaceBeforeSquareBrackets: false\n+\n+# No space will be inserted into {}\n+# while (true) {} not while (true) { }\n+SpaceInEmptyBlock: false\n \n # The number of spaces before trailing line comments (// - comments).\n # This does not affect trailing block comments (/* - comments).\n-- \n2.45.1\n\n"},{"id":"498500","messageId":"20240711083043.1732288-9-karthik.188@gmail.com","threadId":"61750","inReplyTo":"20240711083043.1732288-1-karthik.188@gmail.com","subject":"[PATCH v2 8/8] check-whitespace: detect if no base_commit is provided","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-11T08:30:43Z","receivedAt":"2024-07-11T08:30:55Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"The 'check-whitespace' CI script exits gracefully if no base commit is\nprovided or if an invalid revision is provided. This is not good because\nif a particular CI provides an incorrect base_commit, it would fail\nsuccessfully.\n\nThis is exactly the case with the GitLab CI. The CI is using the\n\"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\" variable to get the base commit\nSHA, but variable is only defined for _merged_ pipelines. So it is empty\nfor regular pipelines [1]. This should've failed the check-whitespace\njob.\n\nLet's fallback to 'CI_MERGE_REQUEST_DIFF_BASE_SHA' if\n\"CI_MERGE_REQUEST_TARGET_BRANCH_SHA\" isn't available in GitLab CI,\nsimilar to the previous commit. Let's also add a check for incorrect\nbase_commit in the 'check-whitespace.sh' script. While here, fix a small\ntypo too.\n\n[1]: https://docs.gitlab.com/ee/ci/variables/predefined_variables.html#predefined-variables-for-merge-request-pipelines\n\nSigned-off-by: Karthik Nayak \n---\n .gitlab-ci.yml | 7 ++++++-\n ci/check-whitespace.sh | 10 ++++++++--\n 2 files changed, 14 insertions(+), 3 deletions(-)\n\ndiff --git a/.gitlab-ci.yml b/.gitlab-ci.yml\nindex dc43fc8ba8..c5a18f655a 100644\n--- a/.gitlab-ci.yml\n+++ b/.gitlab-ci.yml\n@@ -119,7 +119,12 @@ check-whitespace:\n before_script:\n - ./ci/install-dependencies.sh\n script:\n- - ./ci/check-whitespace.sh \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\"\n+ - |\n+ if [ -z ${CI_MERGE_REQUEST_TARGET_BRANCH_SHA} ]; then\n+ ./ci/check-whitespace.sh \"$CI_MERGE_REQUEST_DIFF_BASE_SHA\"\n+ else\n+ ./ci/check-whitespace.sh \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\"\n+ fi\n rules:\n - if: $CI_PIPELINE_SOURCE == 'merge_request_event'\n \ndiff --git a/ci/check-whitespace.sh b/ci/check-whitespace.sh\nindex db399097a5..c40804394c 100755\n--- a/ci/check-whitespace.sh\n+++ b/ci/check-whitespace.sh\n@@ -9,7 +9,7 @@ baseCommit=$1\n outputFile=$2\n url=$3\n \n-if test \"$#\" -ne 1 && test \"$#\" -ne 3\n+if test \"$#\" -ne 1 && test \"$#\" -ne 3 || test -z \"$1\"\n then\n \techo \"USAGE: $0 [ ]\"\n \texit 1\n@@ -21,6 +21,12 @@ commitText=\n commitTextmd=\n goodParent=\n \n+if ! git rev-parse --quiet --verify \"${baseCommit}\"\n+then\n+ echo \"Invalid '${baseCommit}'\"\n+ exit 1\n+fi\n+\n while read dash sha etc\n do\n \tcase \"${dash}\" in\n@@ -67,7 +73,7 @@ then\n \t\tgoodParent=${baseCommit: 0:7}\n \tfi\n \n-\techo \"A whitespace issue was found in onen of more of the commits.\"\n+\techo \"A whitespace issue was found in one or more of the commits.\"\n \techo \"Run the following command to resolve whitespace issues:\"\n \techo \"git rebase --whitespace=fix ${goodParent}\"\n \n-- \n2.45.1\n\n"},{"id":"498501","messageId":"20240711083043.1732288-8-karthik.188@gmail.com","threadId":"61750","inReplyTo":"20240711083043.1732288-1-karthik.188@gmail.com","subject":"[PATCH v2 7/8] ci: run style check on GitHub and GitLab","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-11T08:30:42Z","receivedAt":"2024-07-11T08:30:55Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"We don't run style checks on our CI, even though we have a\n'.clang-format' setup in the repository. Let's add one, the job will\nvalidate only against the new commits added and will only run on merge\nrequests. Since we're introducing it for the first time, let's allow\nthis job to fail, so we can validate if this is useful and eventually\nenforce it.\n\nFor GitLab, we use the 'CI_MERGE_REQUEST_TARGET_BRANCH_SHA' variable by\ndefault to obtain the base SHA of the merged pipeline (which is only\navailable for merged pipelines [1]). Otherwise we use the\n'CI_MERGE_REQUEST_DIFF_BASE_SHA' variable.\n\n[1]: https://docs.gitlab.com/ee/ci/variables/predefined_variables.html#predefined-variables-for-merge-request-pipelines\n\nSigned-off-by: Karthik Nayak \n---\n .github/workflows/check-style.yml | 29 +++++++++++++++++++++++++++++\n .gitlab-ci.yml | 17 +++++++++++++++++\n ci/install-dependencies.sh | 2 +-\n ci/run-style-check.sh | 8 ++++++++\n 4 files changed, 55 insertions(+), 1 deletion(-)\n create mode 100644 .github/workflows/check-style.yml\n create mode 100755 ci/run-style-check.sh\n\ndiff --git a/.github/workflows/check-style.yml b/.github/workflows/check-style.yml\nnew file mode 100644\nindex 0000000000..27276dfe5e\n--- /dev/null\n+++ b/.github/workflows/check-style.yml\n@@ -0,0 +1,29 @@\n+name: check-style\n+\n+# Get the repository with all commits to ensure that we can analyze\n+# all of the commits contributed via the Pull Request.\n+\n+on:\n+ pull_request:\n+ types: [opened, synchronize]\n+\n+# Avoid unnecessary builds. Unlike the main CI jobs, these are not\n+# ci-configurable (but could be).\n+concurrency:\n+ group: ${{ github.workflow }}-${{ github.ref }}\n+ cancel-in-progress: true\n+\n+jobs:\n+ check-style:\n+ runs-on: ubuntu-latest\n+ steps:\n+ - uses: actions/checkout@v4\n+ with:\n+ fetch-depth: 0\n+\n+ - name: git clang-format\n+ continue-on-error: true\n+ id: check_out\n+ run: |\n+ ./ci/run-style-check.sh \\\n+ \"${{github.event.pull_request.base.sha}}\"\ndiff --git a/.gitlab-ci.yml b/.gitlab-ci.yml\nindex 37b991e080..dc43fc8ba8 100644\n--- a/.gitlab-ci.yml\n+++ b/.gitlab-ci.yml\n@@ -123,6 +123,23 @@ check-whitespace:\n rules:\n - if: $CI_PIPELINE_SOURCE == 'merge_request_event'\n \n+check-style:\n+ image: ubuntu:latest\n+ allow_failure: true\n+ variables:\n+ CC: clang\n+ before_script:\n+ - ./ci/install-dependencies.sh\n+ script:\n+ - |\n+ if [ -z ${CI_MERGE_REQUEST_TARGET_BRANCH_SHA} ]; then\n+ ./ci/run-style-check.sh \"$CI_MERGE_REQUEST_DIFF_BASE_SHA\"\n+ else\n+ ./ci/run-style-check.sh \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\"\n+ fi\n+ rules:\n+ - if: $CI_PIPELINE_SOURCE == 'merge_request_event'\n+\n documentation:\n image: ubuntu:latest\n variables:\ndiff --git a/ci/install-dependencies.sh b/ci/install-dependencies.sh\nindex 6ec0f85972..46fe12a690 100755\n--- a/ci/install-dependencies.sh\n+++ b/ci/install-dependencies.sh\n@@ -43,7 +43,7 @@ ubuntu-*)\n \t\tmake libssl-dev libcurl4-openssl-dev libexpat-dev wget sudo default-jre \\\n \t\ttcl tk gettext zlib1g-dev perl-modules liberror-perl libauthen-sasl-perl \\\n \t\tlibemail-valid-perl libio-pty-perl libio-socket-ssl-perl libnet-smtp-ssl-perl libdbd-sqlite3-perl libcgi-pm-perl \\\n-\t\t${CC_PACKAGE:-${CC:-gcc}} $PYTHON_PACKAGE\n+\t\t${CC_PACKAGE:-${CC:-gcc}} $PYTHON_PACKAGE clang-format\n \n \tmkdir --parents \"$CUSTOM_PATH\"\n \twget --quiet --directory-prefix=\"$CUSTOM_PATH\" \\\ndiff --git a/ci/run-style-check.sh b/ci/run-style-check.sh\nnew file mode 100755\nindex 0000000000..76dd37d22b\n--- /dev/null\n+++ b/ci/run-style-check.sh\n@@ -0,0 +1,8 @@\n+#!/bin/sh\n+#\n+# Perform style check\n+#\n+\n+baseCommit=$1\n+\n+git clang-format --style file --diff --extensions c,h \"$baseCommit\"\n-- \n2.45.1\n\n"},{"id":"498514","messageId":"xmqqsewgng80.fsf@gitster.g","threadId":"61750","inReplyTo":"CAOLa=ZSUZGqxHbEtpR3fadOFf=YPVxbo8W7SwyB9j5am14EB7A@mail.gmail.com","subject":"Re: [PATCH 8/8] check-whitespace: detect if no base_commit is provided","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-07-11T14:41:35Z","receivedAt":"2024-07-11T14:41:40Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Karthik Nayak writes:\n\n>> I was commenting on the exit status check done here:\n>>\n>> +gitLogOutput=$(git log --check --pretty=format:\"---% h% s\" \"${baseCommit}\"..)\n>> +if test $? -ne 0\n>> +then\n>> +\techo -n $gitLogOutput\n>> +\texit 1\n>> +fi\n>>\n>> Even though the output is captured in a variable, the exit status of\n>> \"git log --check\" is still seen by the shell and \"if test $? = 0\"\n>> next line say \"ah, the thing exited with non-zero status so lets\n>> echo the whole thing and exit with 1\", before it gets to the while\n>> loop we have below the above piece of code, no?\n>\n> My bad, I thought you were referring to the code before my changes. Yes,\n> here you're right, we don't need the check since the shell would capture\n> the non-zero status.\n\nOK. \n\nBecause in the next round, you'd be checking the error condition\nof \"git rev-parse $baseCommit\" or something that is specifically\ndesigned to check the validity of user input, and not the error\nresult from the actual \"log --check\", the above becomes moot ;-)\n\nThanks.\n\n"},{"id":"498516","messageId":"zq2x3k5gshs5jgx6zglfdzu4kx6vrrzugfvd4w4pjfh6uyjc4r@4x2zt2ftfmsq","threadId":"61750","inReplyTo":"20240711083043.1732288-9-karthik.188@gmail.com","subject":"Re: [PATCH v2 8/8] check-whitespace: detect if no base_commit is provided","fromName":"Justin Tobler","fromEmail":"jltobler@gmail.com","sentAt":"2024-07-11T14:48:48Z","receivedAt":"2024-07-11T14:49:22Z","isPatch":true,"sender":{"key":"jltobler@gmail.com","avatar":"https://avatars.githubusercontent.com/u/53454972?v=4"},"body":"On 24/07/11 10:30AM, Karthik Nayak wrote:\n> The 'check-whitespace' CI script exits gracefully if no base commit is\n> provided or if an invalid revision is provided. This is not good because\n> if a particular CI provides an incorrect base_commit, it would fail\n> successfully.\n> \n> This is exactly the case with the GitLab CI. The CI is using the\n> \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\" variable to get the base commit\n> SHA, but variable is only defined for _merged_ pipelines. So it is empty\n> for regular pipelines [1]. This should've failed the check-whitespace\n> job.\n> \n> Let's fallback to 'CI_MERGE_REQUEST_DIFF_BASE_SHA' if\n> \"CI_MERGE_REQUEST_TARGET_BRANCH_SHA\" isn't available in GitLab CI,\n> similar to the previous commit. Let's also add a check for incorrect\n> base_commit in the 'check-whitespace.sh' script. While here, fix a small\n> typo too.\n> \n> [1]: https://docs.gitlab.com/ee/ci/variables/predefined_variables.html#predefined-variables-for-merge-request-pipelines\n> \n> Signed-off-by: Karthik Nayak \n> ---\n> .gitlab-ci.yml | 7 ++++++-\n> ci/check-whitespace.sh | 10 ++++++++--\n> 2 files changed, 14 insertions(+), 3 deletions(-)\n> \n> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml\n> index dc43fc8ba8..c5a18f655a 100644\n> --- a/.gitlab-ci.yml\n> +++ b/.gitlab-ci.yml\n> @@ -119,7 +119,12 @@ check-whitespace:\n> before_script:\n> - ./ci/install-dependencies.sh\n> script:\n> - - ./ci/check-whitespace.sh \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\"\n> + - |\n> + if [ -z ${CI_MERGE_REQUEST_TARGET_BRANCH_SHA} ]; then\n> + ./ci/check-whitespace.sh \"$CI_MERGE_REQUEST_DIFF_BASE_SHA\"\n> + else\n> + ./ci/check-whitespace.sh \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\"\n> + fi\n\nNot worth a reroll, but it would be nice to have a comment here\nexplaining why we have this fallback as, to me at least, it is not very\nobvious.\n\n> rules:\n> - if: $CI_PIPELINE_SOURCE == 'merge_request_event'\n> \n[snip]\n\nOverall the GitLab CI changes look good to me. Thanks :)\n\n-Justin\n"},{"id":"498521","messageId":"xmqqikxbsy4d.fsf@gitster.g","threadId":"61750","inReplyTo":"zq2x3k5gshs5jgx6zglfdzu4kx6vrrzugfvd4w4pjfh6uyjc4r@4x2zt2ftfmsq","subject":"Re: [PATCH v2 8/8] check-whitespace: detect if no base_commit is provided","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-07-11T16:16:02Z","receivedAt":"2024-07-11T16:16:07Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Justin Tobler writes:\n\n>> + if [ -z ${CI_MERGE_REQUEST_TARGET_BRANCH_SHA} ]; then\n>> + ./ci/check-whitespace.sh \"$CI_MERGE_REQUEST_DIFF_BASE_SHA\"\n>> + else\n>> + ./ci/check-whitespace.sh \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\"\n>> + fi\n>\n> Not worth a reroll, but it would be nice to have a comment here\n> explaining why we have this fallback as, to me at least, it is not very\n> obvious.\n\nFWIW, it is not obvious to me, either ;-)\n\nAnother thing that I find somewhat disturbing is that the\nconditional seems the other way around. It shouldn't be saying \"If\nB is not available, use A, otherwise use B\", as if A is known to be\nusable always. It should be more like\n\n\tif test -n \"$CI_MERGE_REQUEST_DIFF_BASE_SHA\"\n\tthen\n\t\tci/check-whitespace.sh \"$CI_MERGE_REQUEST_DIFF_BASE_SHA\"\n\telif test -n \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\"\n\tthen\n\t\tci/check-whitespace.sh \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\"\n\telse\n\t\t... noop? barf? ...\n\tfi\n\nshouldn't it?\n\n>> rules:\n>> - if: $CI_PIPELINE_SOURCE == 'merge_request_event'\n>> \n> [snip]\n>\n> Overall the GitLab CI changes look good to me. Thanks :)\n\nThanks for a review. Very much appreciated.\n\n\n"},{"id":"498522","messageId":"xmqqcynjswz7.fsf@gitster.g","threadId":"61750","inReplyTo":"20240711083043.1732288-6-karthik.188@gmail.com","subject":"Re: [PATCH v2 5/8] clang-format: avoid braces on simple single-statement bodies","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-07-11T16:40:44Z","receivedAt":"2024-07-11T16:40:50Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Karthik Nayak writes:\n\n> Setting this option to true could lead to incorrect code formatting\n> due to clang-format’s lack of complete semantic information. As\n> such, extra care should be taken to review code changes made by\n> this option.\n>\n> The latter seems to be of concern. But since we only use clang-format to\n> verify the format and not to apply formatting, we should be okay here.\n\nHmph. Could you tell me where I can read more about \"we tell\nclang-format only to verify but not to apply\"? If that is truely\nthe case, perhaps I shouldn't be worried to much, but it is not\nclear to me how we enforce that this is to be used only for\nverification with non-zero false positive, and never for\nreformatting before submission.\n\nThe senario I was worried about was this. We aadd to .clang-format\nthat is in-tree, and not just CI jobs but our human contributors may\nuse it to check what they newly wrote before committing and they may\neven take the differences as suggested fixes (which may end up\nbreaking their working code).\n\nThanks.\n"},{"id":"498524","messageId":"xmqq8qy7ssr4.fsf@gitster.g","threadId":"61750","inReplyTo":"20240711083043.1732288-1-karthik.188@gmail.com","subject":"Re: [PATCH v2 0/8] clang-format: add more rules and enable on CI","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-07-11T18:11:59Z","receivedAt":"2024-07-11T18:12:13Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Karthik Nayak writes:\n\n> This is v2 of my series to add clang-format to the CI.\n\nAside from a few comments, the series looked good.\n\nWill queue. Thanks.\n"},{"id":"498571","messageId":"CAOLa=ZSJ-PQ+8rsURP16QQ_K8rR8xrhFO8tnAPSZD88COrzj1w@mail.gmail.com","threadId":"61750","inReplyTo":"xmqqcynjswz7.fsf@gitster.g","subject":"Re: [PATCH v2 5/8] clang-format: avoid braces on simple single-statement bodies","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-12T08:48:58Z","receivedAt":"2024-07-12T08:49:00Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"Junio C Hamano writes:\n\n> Karthik Nayak writes:\n>\n>> Setting this option to true could lead to incorrect code formatting\n>> due to clang-format’s lack of complete semantic information. As\n>> such, extra care should be taken to review code changes made by\n>> this option.\n>>\n>> The latter seems to be of concern. But since we only use clang-format to\n>> verify the format and not to apply formatting, we should be okay here.\n>\n> Hmph. Could you tell me where I can read more about \"we tell\n> clang-format only to verify but not to apply\"? If that is truely\n> the case, perhaps I shouldn't be worried to much, but it is not\n> clear to me how we enforce that this is to be used only for\n> verification with non-zero false positive, and never for\n> reformatting before submission.\n>\n\nI was referring to the fact that, we expose '.clang-format' via 'make\nstyle' which only prints the diff to the STDOUT. The user has to still\nmanually make these changes.\n\nHowever users could be using tools to auto-format on save and this could\nbe an issue.\n\n> The senario I was worried about was this. We aadd to .clang-format\n> that is in-tree, and not just CI jobs but our human contributors may\n> use it to check what they newly wrote before committing and they may\n> even take the differences as suggested fixes (which may end up\n> breaking their working code).\n>\n> Thanks.\n\nI totally see your point here.\n\nIf the contributors do end up with bad formatting because clang messed\nit up, that is an okay situation, since that shouldn't happen often, and\nwhen it does, it would be the same situation as without this check,\nwherein we rely on reviewers. The issue is whether it would break their\ncode, I couldn't find anything on this.\n\nBut overall, while I personally find this check useful, I'm happy to\ndrop it, My goal is to ensure we run this on CI as a first step :)\n"},{"id":"498572","messageId":"CAOLa=ZSR=mMMnYNrpKc9ivOx4vbzJF7c5e3632NpX4XYFdLMmg@mail.gmail.com","threadId":"61750","inReplyTo":"xmqqikxbsy4d.fsf@gitster.g","subject":"Re: [PATCH v2 8/8] check-whitespace: detect if no base_commit is provided","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-12T08:51:22Z","receivedAt":"2024-07-12T08:51:24Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"Junio C Hamano writes:\n\n> Justin Tobler writes:\n>\n>>> + if [ -z ${CI_MERGE_REQUEST_TARGET_BRANCH_SHA} ]; then\n>>> + ./ci/check-whitespace.sh \"$CI_MERGE_REQUEST_DIFF_BASE_SHA\"\n>>> + else\n>>> + ./ci/check-whitespace.sh \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\"\n>>> + fi\n>>\n>> Not worth a reroll, but it would be nice to have a comment here\n>> explaining why we have this fallback as, to me at least, it is not very\n>> obvious.\n>\n> FWIW, it is not obvious to me, either ;-)\n>\n> Another thing that I find somewhat disturbing is that the\n> conditional seems the other way around. It shouldn't be saying \"If\n> B is not available, use A, otherwise use B\", as if A is known to be\n> usable always. It should be more like\n>\n> \tif test -n \"$CI_MERGE_REQUEST_DIFF_BASE_SHA\"\n> \tthen\n> \t\tci/check-whitespace.sh \"$CI_MERGE_REQUEST_DIFF_BASE_SHA\"\n> \telif test -n \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\"\n> \tthen\n> \t\tci/check-whitespace.sh \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\"\n> \telse\n> \t\t... noop? barf? ...\n> \tfi\n>\n> shouldn't it?\n>\n\nAgreed, that a comment would be nice here. Will add if I reroll!\n\nIn this case A (\"$CI_MERGE_REQUEST_DIFF_BASE_SHA\") is known to be usable\nalways [1].\n\n[1]: https://docs.gitlab.com/ee/ci/variables/predefined_variables.html\n\n>>> rules:\n>>> - if: $CI_PIPELINE_SOURCE == 'merge_request_event'\n>>>\n>> [snip]\n>>\n>> Overall the GitLab CI changes look good to me. Thanks :)\n>\n> Thanks for a review. Very much appreciated.\n\nThanks both of you!\n"},{"id":"498582","messageId":"xmqq7cdqpry4.fsf@gitster.g","threadId":"61750","inReplyTo":"CAOLa=ZSJ-PQ+8rsURP16QQ_K8rR8xrhFO8tnAPSZD88COrzj1w@mail.gmail.com","subject":"Re: [PATCH v2 5/8] clang-format: avoid braces on simple single-statement bodies","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-07-12T15:09:55Z","receivedAt":"2024-07-12T15:09:58Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Karthik Nayak writes:\n\n> Junio C Hamano writes:\n>\n>> Karthik Nayak writes:\n>>\n>>> Setting this option to true could lead to incorrect code formatting\n>>> due to clang-format’s lack of complete semantic information. As\n>>> such, extra care should be taken to review code changes made by\n>>> this option.\n>>>\n>>> The latter seems to be of concern. But since we only use clang-format to\n>>> verify the format and not to apply formatting, we should be okay here.\n>>\n>> Hmph. Could you tell me where I can read more about \"we tell\n>> clang-format only to verify but not to apply\"? If that is truely\n>> the case, perhaps I shouldn't be worried to much, but it is not\n>> clear to me how we enforce that this is to be used only for\n>> verification with non-zero false positive, and never for\n>> reformatting before submission.\n>>\n>\n> I was referring to the fact that, we expose '.clang-format' via 'make\n> style' which only prints the diff to the STDOUT. The user has to still\n> manually make these changes.\n>\n> However users could be using tools to auto-format on save and this could\n> be an issue.\n\nYes.\n\nOf course if we really wanted to avoid end-user confusion and still\nwant to have this in CI (if only to see how well the rule fares, and\nwhat the actual false-positive rate is), we _could_ run CI's job\nwith custom .clang-format file that is not visible to end-users in\ntheir normal checkout, or something silly like that. If we are\ngoing to use it, then we should use it everywhere, making sure\neverybody is careful. If the cost of forcing everybody to be\ncareful is too high, we may want to retract it, but we won't know\nuntil we try.\n\nThanks.\n"},{"id":"498583","messageId":"xmqq34oeprui.fsf@gitster.g","threadId":"61750","inReplyTo":"CAOLa=ZSR=mMMnYNrpKc9ivOx4vbzJF7c5e3632NpX4XYFdLMmg@mail.gmail.com","subject":"Re: [PATCH v2 8/8] check-whitespace: detect if no base_commit is provided","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-07-12T15:12:05Z","receivedAt":"2024-07-12T15:12:09Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Karthik Nayak writes:\n\n>> Another thing that I find somewhat disturbing is that the\n>> conditional seems the other way around. It shouldn't be saying \"If\n>> B is not available, use A, otherwise use B\", as if A is known to be\n>> usable always. It should be more like ...\n>> shouldn't it?\n>>\n>\n> Agreed, that a comment would be nice here. Will add if I reroll!\n>\n> In this case A (\"$CI_MERGE_REQUEST_DIFF_BASE_SHA\") is known to be usable\n> always [1].\n>\n> [1]: https://docs.gitlab.com/ee/ci/variables/predefined_variables.html\n\nOk, if so check the one you want to use, if exists, first, and then\nfall back to what is supposed to exist always but is your second\nchoice, e.g.,\n\n \tif test -n \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\"\n \tthen\n \t\tci/check-whitespace.sh \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\"\n \telif \n \tthen test -n \"$CI_MERGE_REQUEST_DIFF_BASE_SHA\"\n \t\tci/check-whitespace.sh \"$CI_MERGE_REQUEST_DIFF_BASE_SHA\"\n \telse\n \t\tBUG CI_MERGE_REQUEST_DIFF_BASE_SHA should always exist!\n \tfi\n\nThanks.\n"},{"id":"498584","messageId":"12830e1d-598d-4e7d-abd6-3349800e277a@gmail.com","threadId":"61750","inReplyTo":"CAOLa=ZSb_S7X7pdFPp0r5bfNc3o95mGe5pU+rC1T_yM89NRqCw@mail.gmail.com","subject":"Re: [PATCH 5/8] clang-format: avoid braces on simple single-statement bodies","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2024-07-12T15:24:34Z","receivedAt":"2024-07-12T15:24:40Z","isPatch":true,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Karthik\n\nOn 08/07/2024 21:25, Karthik Nayak wrote:\n> Junio C Hamano writes:\n> \n>> Karthik Nayak writes:\n>>\n>>> Set the 'RemoveBracesLLVM' to 'true' which ensures that we avoid curly\n>>> braces for single-statement bodies in conditional blocks.\n>>\n>> Hmph, two warnings in its documentation [*] sound ominous, especially\n>> the second one that says:\n>>\n>> Warning\n>>\n>> Setting this option to true could lead to incorrect code\n>> formatting due to clang-format’s lack of complete semantic\n>> information. As such, extra care should be taken to review code\n>> changes made by this option.\n>>\n>> which implies it may not necessarily a good idea to add to\n>> automation without telling contributors that they may get hit with a\n>> false positive (or incorrect rewrite).\n> \n> Agreed on this one. I'm a bit skeptical to be honest too. I think I\n> should have added information about the warning in the commit too. I\n> will for next round. Overall, this also contributes to the reason why I\n> decided these CI jobs need to be allowed to fail.\n\nI'm a bit confused - what does \"allowed to fail\" mean? We don't have any \nautomated requirements on the CI passing. We don't want to train \ncontributors to routinely ignore CI failures but if they don't get a \nnotification that this job failed how do they know to correct the \nformatting?\n\n>> Reading from the examples in that documentation page, it was unclear\n>> how it would handle if/else if/.../else cascade where not all branches\n>> are multi-statement blocks, e.g.,\n>>\n>> \tif (A) {\n>> \t\tdo_A_thing();\n>> \t} else if (B) {\n>> \t\tdo_B_thing();\n>> \t} else {\n>> \t\tdo_C_things();\n>> \t\tdo_other_things();\n>> \t}\n>>\n>> but looking around I am getting a feeling that the tool would do the\n>> right thing, i.e., to match our preference that is to use {braces}\n>> around all branches, if I am not mistaken.\n>>\n> \n> Yup, that was my understanding and what I could see from some quick\n> trials that I did too.\n> \n> It would be a great win to have this though, because it is one of the\n> things that always get me.\n\nYes, having the formatting automated would be really helpful. It is a \nshame the documentation doesn't really explain what the issue is (i.e. \nwhen does it generate invalid code) so we don't know how likely we are \nto be affected by it.\n\nBest Wishes\n\nPhillip\n\n>>\n>> [Reference]\n>>\n>> * https://releases.llvm.org/16.0.0/tools/clang/docs/ClangFormatStyleOptions.html#:~:text=RemoveBracesLLVM\n>>\n>>> +# Remove optional braces of control statements (if, else, for, and while)\n>>> +# according to the LLVM coding style\n>>> +# This avoids braces on simple single-statement bodies of statements.\n>>\n>> \"... but keeps braces if one side of if/else if/.../else cascade has\n>> multi-statement body.\"\n>>\n> \n> Makes sense, will add.\n> \n>>> +RemoveBracesLLVM: true\n> \n> Overall I must say, I'd be okay if this patch is also dropped from this\n> series.\n"},{"id":"498585","messageId":"42867b72-58e0-48d7-86eb-7c312db942dd@gmail.com","threadId":"61750","inReplyTo":"xmqq7cdqpry4.fsf@gitster.g","subject":"Re: [PATCH v2 5/8] clang-format: avoid braces on simple single-statement bodies","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2024-07-12T15:29:37Z","receivedAt":"2024-07-12T15:29:43Z","isPatch":true,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"On 12/07/2024 16:09, Junio C Hamano wrote:\n\n> Of course if we really wanted to avoid end-user confusion and still\n> want to have this in CI (if only to see how well the rule fares, and\n> what the actual false-positive rate is), we _could_ run CI's job\n> with custom .clang-format file that is not visible to end-users in\n> their normal checkout, or something silly like that.\n\nGetting some idea of how useful the auto-formatter is would be valuable \nI think.\n\n> If we are\n> going to use it, then we should use it everywhere, making sure\n> everybody is careful. If the cost of forcing everybody to be\n> careful is too high, we may want to retract it, but we won't know\n> until we try.\n\nIt would be great if we could find a way to auto-format the code without \ninconveniencing contributors.\n\nBest Wishes\n\nPhillip\n\n"},{"id":"498610","messageId":"CAOLa=ZSrVOBkziX+z3g1RqudiLp=SN4gW=OL5Ky++KukPF=QXA@mail.gmail.com","threadId":"61750","inReplyTo":"12830e1d-598d-4e7d-abd6-3349800e277a@gmail.com","subject":"Re: [PATCH 5/8] clang-format: avoid braces on simple single-statement bodies","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-13T12:30:26Z","receivedAt":"2024-07-13T12:30:28Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"Phillip Wood writes:\n\n> Hi Karthik\n>\n> On 08/07/2024 21:25, Karthik Nayak wrote:\n>> Junio C Hamano writes:\n>>\n>>> Karthik Nayak writes:\n>>>\n>>>> Set the 'RemoveBracesLLVM' to 'true' which ensures that we avoid curly\n>>>> braces for single-statement bodies in conditional blocks.\n>>>\n>>> Hmph, two warnings in its documentation [*] sound ominous, especially\n>>> the second one that says:\n>>>\n>>> Warning\n>>>\n>>> Setting this option to true could lead to incorrect code\n>>> formatting due to clang-format’s lack of complete semantic\n>>> information. As such, extra care should be taken to review code\n>>> changes made by this option.\n>>>\n>>> which implies it may not necessarily a good idea to add to\n>>> automation without telling contributors that they may get hit with a\n>>> false positive (or incorrect rewrite).\n>>\n>> Agreed on this one. I'm a bit skeptical to be honest too. I think I\n>> should have added information about the warning in the commit too. I\n>> will for next round. Overall, this also contributes to the reason why I\n>> decided these CI jobs need to be allowed to fail.\n>\n> I'm a bit confused - what does \"allowed to fail\" mean? We don't have any\n> automated requirements on the CI passing. We don't want to train\n> contributors to routinely ignore CI failures but if they don't get a\n> notification that this job failed how do they know to correct the\n> formatting?\n>\n\nWell, it mostly means that the CI would show the style-check job as\nfailed, but the overall pipeline would be successful. We want to ideally\nfail the pipeline too, but I'm being careful to not disrupt things\nsuddenly and I think once we see what false positive rate is and once we\nfine tune this settings maybe over the next release or so, we can\nenforce this.\n\n[snip]\n"},{"id":"498614","messageId":"20240713134518.773053-1-karthik.188@gmail.com","threadId":"61750","inReplyTo":"20240711083043.1732288-1-karthik.188@gmail.com","subject":"[PATCH v3 0/8] clang-format: add more rules and enable on CI","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-13T13:45:10Z","receivedAt":"2024-07-13T13:45:23Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"This is v3 of my series to add clang-format to the CI.\n\nThe series was mostly inspired by a patch sent recently to 'include\nkh_foreach* macros in ForEachMacros' [1]. I was wondering why we don't\nrun the formatting on CI and reduce some of the workload of reviewers.\n\nWe have a '.clang-format' file to provide rules for code formatting.\nThe commits 1-5 aims to add more rules to the file while deprecating old\nones.\n\nCommit 6 enables CI action on GitHub and GitLab to also check for the\ncode formatting. Currently, it is allowed to fail. This way we can build\nconfidence and fine tune the values as needed and finally enforce the\ncheck in a future patch. I'm not well versed with GitHub workflows, and\nI mostly tried to copy existing work there. Expecting some feedback in\nthat section!\n\nCommit 7 fixes an existing issue with the 'check-whitespace' job, which\nis failing as success in the GitLab CI.\n\nCommit 8 adds the `RemoveBracesLLVM` only in the context of the CI. If we\ndecide against it, we could drop this commit from the series.\n\n1: https://lore.kernel.org/git/4e7893f5-2dd9-46cf-8a64-cf780f4e1730@web.de/\n\nChanges against v2:\n* Dropped the commit to add 'RemoveBracesLLVM' to the in-tree '.clang-format'.\nNow, we only add it in the CI context.\n* Added comments for the reasoning and picking of the ENV variables in GitLab's\nCI. Also changed the syntax to be more readable.\n\nKarthik Nayak (8):\n clang-format: indent preprocessor directives after hash\n clang-format: avoid spacing around bitfield colon\n clang-format: ensure files end with newlines\n clang-format: replace deprecated option with 'SpacesInParens'\n clang-format: formalize some of the spacing rules\n ci: run style check on GitHub and GitLab\n check-whitespace: detect if no base_commit is provided\n ci/style-check: add `RemoveBracesLLVM` to '.clang-format'\n\n .clang-format | 36 +++++++++++++++++++++++++----\n .github/workflows/check-style.yml | 29 +++++++++++++++++++++++\n .gitlab-ci.yml | 38 ++++++++++++++++++++++++++++++-\n ci/check-whitespace.sh | 10 ++++++--\n ci/install-dependencies.sh | 2 +-\n ci/run-style-check.sh | 21 +++++++++++++++++\n 6 files changed, 127 insertions(+), 9 deletions(-)\n create mode 100644 .github/workflows/check-style.yml\n create mode 100755 ci/run-style-check.sh\n\nRange-diff against v2:\n1: 6cf91ffc86 = 1: 6cf91ffc86 clang-format: indent preprocessor directives after hash\n2: beb002885f = 2: beb002885f clang-format: avoid spacing around bitfield colon\n3: 3031be43e7 = 3: 3031be43e7 clang-format: ensure files end with newlines\n4: bc1550e300 = 4: bc1550e300 clang-format: replace deprecated option with 'SpacesInParens'\n5: 840318a4c9 < -: ---------- clang-format: avoid braces on simple single-statement bodies\n6: 0ecfd8d24b ! 5: 4586c0094b clang-format: formalize some of the spacing rules\n @@ Commit message\n Signed-off-by: Karthik Nayak \n \n ## .clang-format ##\n -@@ .clang-format: RemoveBracesLLVM: true\n +@@ .clang-format: PointerAlignment: Right\n # x = (int32)y; not x = (int32) y;\n SpaceAfterCStyleCast: false\n \n7: 11a9ac4935 ! 6: c18cb23369 ci: run style check on GitHub and GitLab\n @@ .gitlab-ci.yml: check-whitespace:\n + CC: clang\n + before_script:\n + - ./ci/install-dependencies.sh\n ++ # Since $CI_MERGE_REQUEST_TARGET_BRANCH_SHA is only defined for merged\n ++ # pipelines, we fallback to $CI_MERGE_REQUEST_DIFF_BASE_SHA, which should\n ++ # be defined in all pipelines.\n + script:\n + - |\n -+ if [ -z ${CI_MERGE_REQUEST_TARGET_BRANCH_SHA} ]; then\n ++ if test -n \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\"\n ++ then\n ++ ./ci/run-style-check.sh \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\"\n ++ elif test -n \"$CI_MERGE_REQUEST_DIFF_BASE_SHA\"\n ++ then\n + ./ci/run-style-check.sh \"$CI_MERGE_REQUEST_DIFF_BASE_SHA\"\n + else\n -+ ./ci/run-style-check.sh \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\"\n ++ echo \"CI_MERGE_REQUEST_DIFF_BASE_SHA should always exist!\"; exit 1\n + fi\n + rules:\n + - if: $CI_PIPELINE_SOURCE == 'merge_request_event'\n8: caccbf8264 ! 7: 4d08c570bb check-whitespace: detect if no base_commit is provided\n @@ Commit message\n \n ## .gitlab-ci.yml ##\n @@ .gitlab-ci.yml: check-whitespace:\n + image: ubuntu:latest\n before_script:\n - ./ci/install-dependencies.sh\n ++ # Since $CI_MERGE_REQUEST_TARGET_BRANCH_SHA is only defined for merged\n ++ # pipelines, we fallback to $CI_MERGE_REQUEST_DIFF_BASE_SHA, which should\n ++ # be defined in all pipelines.\n script:\n - - ./ci/check-whitespace.sh \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\"\n + - |\n -+ if [ -z ${CI_MERGE_REQUEST_TARGET_BRANCH_SHA} ]; then\n ++ if test -n \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\"\n ++ then\n ++ ./ci/check-whitespace.sh \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\"\n ++ elif test -n \"$CI_MERGE_REQUEST_DIFF_BASE_SHA\"\n ++ then\n + ./ci/check-whitespace.sh \"$CI_MERGE_REQUEST_DIFF_BASE_SHA\"\n + else\n -+ ./ci/check-whitespace.sh \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\"\n ++ echo \"CI_MERGE_REQUEST_DIFF_BASE_SHA should always exist!\"; exit 1\n + fi\n rules:\n - if: $CI_PIPELINE_SOURCE == 'merge_request_event'\n-: ---------- > 8: 2b39431f93 ci/style-check: add `RemoveBracesLLVM` to '.clang-format'\n-- \n2.45.2\n\n"},{"id":"498615","messageId":"20240713134518.773053-2-karthik.188@gmail.com","threadId":"61750","inReplyTo":"20240713134518.773053-1-karthik.188@gmail.com","subject":"[PATCH v3 1/8] clang-format: indent preprocessor directives after hash","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-13T13:45:11Z","receivedAt":"2024-07-13T13:45:24Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"We do not have a rule around the indentation of preprocessor directives.\nThis was also discussed on the list [1], noting how there is often\ninconsistency in the styling. While there was discussion, there was no\nconclusion around what is the preferred style here. One style being\nindenting after the hash:\n\n #if FOO\n # if BAR\n # include \n # endif\n #endif\n\nThe other being before the hash:\n\n #if FOO\n #if BAR\n #include \n #endif\n #endif\n\nLet's pick the former and add 'IndentPPDirectives: AfterHash' value to\nour '.clang-format'. There is no clear reason to pick one over the\nother, but it would definitely be nicer to be consistent.\n\n[1]: https://lore.kernel.org/r/xmqqwmmm1bw6.fsf@gitster.g\n\nSigned-off-by: Karthik Nayak \n---\n .clang-format | 6 ++++++\n 1 file changed, 6 insertions(+)\n\ndiff --git a/.clang-format b/.clang-format\nindex 3ed4fac753..5e128519bf 100644\n--- a/.clang-format\n+++ b/.clang-format\n@@ -96,6 +96,12 @@ BreakStringLiterals: false\n # Switch statement body is always indented one level more than case labels.\n IndentCaseLabels: false\n \n+# Indents directives before the hash.\n+# #if FOO\n+# # include \n+# #endif\n+IndentPPDirectives: AfterHash\n+\n # Don't indent a function definition or declaration if it is wrapped after the\n # type\n IndentWrappedFunctionNames: false\n-- \n2.45.2\n\n"},{"id":"498616","messageId":"20240713134518.773053-3-karthik.188@gmail.com","threadId":"61750","inReplyTo":"20240713134518.773053-1-karthik.188@gmail.com","subject":"[PATCH v3 2/8] clang-format: avoid spacing around bitfield colon","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-13T13:45:12Z","receivedAt":"2024-07-13T13:45:25Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"The spacing around colons is currently not standardized and as such we\nhave the following practices in our code base:\n- Spacing around the colon `int bf : 1`: 146 instances\n- No spacing around the colon `int bf:1`: 148 instances\n- Spacing before the colon `int bf :1`: 6 instances\n- Spacing after the colon `int bf: 1`: 12 instances\n\nLet's formalize this by picking the most followed pattern and add the\ncorresponding style to '.clang-format'.\n\nSigned-off-by: Karthik Nayak \n---\n .clang-format | 4 ++++\n 1 file changed, 4 insertions(+)\n\ndiff --git a/.clang-format b/.clang-format\nindex 5e128519bf..803b274dd5 100644\n--- a/.clang-format\n+++ b/.clang-format\n@@ -72,6 +72,10 @@ AlwaysBreakAfterReturnType: None\n BinPackArguments: true\n BinPackParameters: true\n \n+# Add no space around the bit field\n+# unsigned bf:2;\n+BitFieldColonSpacing: None\n+\n # Attach braces to surrounding context except break before braces on function\n # definitions.\n # void foo()\n-- \n2.45.2\n\n"},{"id":"498617","messageId":"20240713134518.773053-4-karthik.188@gmail.com","threadId":"61750","inReplyTo":"20240713134518.773053-1-karthik.188@gmail.com","subject":"[PATCH v3 3/8] clang-format: ensure files end with newlines","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-13T13:45:13Z","receivedAt":"2024-07-13T13:45:26Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"All our source files end with a newline, let's formalize in\n'.clang-format'.\n\nSigned-off-by: Karthik Nayak \n---\n .clang-format | 3 +++\n 1 file changed, 3 insertions(+)\n\ndiff --git a/.clang-format b/.clang-format\nindex 803b274dd5..4c9751a9db 100644\n--- a/.clang-format\n+++ b/.clang-format\n@@ -106,6 +106,9 @@ IndentCaseLabels: false\n # #endif\n IndentPPDirectives: AfterHash\n \n+# Insert a newline at end of file if missing\n+InsertNewlineAtEOF: true\n+\n # Don't indent a function definition or declaration if it is wrapped after the\n # type\n IndentWrappedFunctionNames: false\n-- \n2.45.2\n\n"},{"id":"498618","messageId":"20240713134518.773053-5-karthik.188@gmail.com","threadId":"61750","inReplyTo":"20240713134518.773053-1-karthik.188@gmail.com","subject":"[PATCH v3 4/8] clang-format: replace deprecated option with 'SpacesInParens'","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-13T13:45:14Z","receivedAt":"2024-07-13T13:45:27Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"Replace the deprecated options 'SpacesInParentheses' and\n'SpaceInEmptyParentheses' with the newer 'SpacesInParens' option. The\nusage is the same.\n\nSigned-off-by: Karthik Nayak \n---\n .clang-format | 9 ++++-----\n 1 file changed, 4 insertions(+), 5 deletions(-)\n\ndiff --git a/.clang-format b/.clang-format\nindex 4c9751a9db..914254a29b 100644\n--- a/.clang-format\n+++ b/.clang-format\n@@ -134,8 +134,6 @@ SpaceBeforeAssignmentOperators: true\n # }\n SpaceBeforeParens: ControlStatements\n \n-# Don't insert spaces inside empty '()'\n-SpaceInEmptyParentheses: false\n \n # The number of spaces before trailing line comments (// - comments).\n # This does not affect trailing block comments (/* - comments).\n@@ -149,9 +147,10 @@ SpacesInCStyleCastParentheses: false\n # var arr = [1, 2, 3]; not var arr = [ 1, 2, 3 ];\n SpacesInContainerLiterals: false\n \n-# Don't insert spaces after '(' or before ')'\n-# f(arg); not f( arg );\n-SpacesInParentheses: false\n+SpacesInParens: Custom\n+SpacesInParensOptions:\n+ # Don't insert spaces inside empty '()'\n+ InEmptyParentheses: false\n \n # Don't insert spaces after '[' or before ']'\n # int a[5]; not int a[ 5 ];\n-- \n2.45.2\n\n"},{"id":"498619","messageId":"20240713134518.773053-6-karthik.188@gmail.com","threadId":"61750","inReplyTo":"20240713134518.773053-1-karthik.188@gmail.com","subject":"[PATCH v3 5/8] clang-format: formalize some of the spacing rules","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-13T13:45:15Z","receivedAt":"2024-07-13T13:45:28Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"There are some spacing rules that we follow in the project and it makes\nsense to formalize them:\n* Ensure there is no space inserted after the logical not '!' operator.\n* Ensure there is no space before the case statement's colon.\n* Ensure there is no space before the first bracket '[' of an array.\n* Ensure there is no space in empty blocks.\n\nSigned-off-by: Karthik Nayak \n---\n .clang-format | 14 ++++++++++++++\n 1 file changed, 14 insertions(+)\n\ndiff --git a/.clang-format b/.clang-format\nindex 914254a29b..a0dd1f2eb9 100644\n--- a/.clang-format\n+++ b/.clang-format\n@@ -121,11 +121,18 @@ PointerAlignment: Right\n # x = (int32)y; not x = (int32) y;\n SpaceAfterCStyleCast: false\n \n+# No space is inserted after the logical not operator\n+SpaceAfterLogicalNot: false\n+\n # Insert spaces before and after assignment operators\n # int a = 5; not int a=5;\n # a += 42; a+=42;\n SpaceBeforeAssignmentOperators: true\n \n+# Spaces will be removed before case colon.\n+# case 1: break; not case 1 : break;\n+SpaceBeforeCaseColon: false\n+\n # Put a space before opening parentheses only after control statement keywords.\n # void f() {\n # if (true) {\n@@ -134,6 +141,13 @@ SpaceBeforeAssignmentOperators: true\n # }\n SpaceBeforeParens: ControlStatements\n \n+# No space before first '[' in arrays\n+# int a[5][5]; not int a [5][5];\n+SpaceBeforeSquareBrackets: false\n+\n+# No space will be inserted into {}\n+# while (true) {} not while (true) { }\n+SpaceInEmptyBlock: false\n \n # The number of spaces before trailing line comments (// - comments).\n # This does not affect trailing block comments (/* - comments).\n-- \n2.45.2\n\n"},{"id":"498620","messageId":"20240713134518.773053-7-karthik.188@gmail.com","threadId":"61750","inReplyTo":"20240713134518.773053-1-karthik.188@gmail.com","subject":"[PATCH v3 6/8] ci: run style check on GitHub and GitLab","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-13T13:45:16Z","receivedAt":"2024-07-13T13:45:29Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"We don't run style checks on our CI, even though we have a\n'.clang-format' setup in the repository. Let's add one, the job will\nvalidate only against the new commits added and will only run on merge\nrequests. Since we're introducing it for the first time, let's allow\nthis job to fail, so we can validate if this is useful and eventually\nenforce it.\n\nFor GitLab, we use the 'CI_MERGE_REQUEST_TARGET_BRANCH_SHA' variable by\ndefault to obtain the base SHA of the merged pipeline (which is only\navailable for merged pipelines [1]). Otherwise we use the\n'CI_MERGE_REQUEST_DIFF_BASE_SHA' variable.\n\n[1]: https://docs.gitlab.com/ee/ci/variables/predefined_variables.html#predefined-variables-for-merge-request-pipelines\n\nSigned-off-by: Karthik Nayak \n---\n .github/workflows/check-style.yml | 29 +++++++++++++++++++++++++++++\n .gitlab-ci.yml | 24 ++++++++++++++++++++++++\n ci/install-dependencies.sh | 2 +-\n ci/run-style-check.sh | 8 ++++++++\n 4 files changed, 62 insertions(+), 1 deletion(-)\n create mode 100644 .github/workflows/check-style.yml\n create mode 100755 ci/run-style-check.sh\n\ndiff --git a/.github/workflows/check-style.yml b/.github/workflows/check-style.yml\nnew file mode 100644\nindex 0000000000..27276dfe5e\n--- /dev/null\n+++ b/.github/workflows/check-style.yml\n@@ -0,0 +1,29 @@\n+name: check-style\n+\n+# Get the repository with all commits to ensure that we can analyze\n+# all of the commits contributed via the Pull Request.\n+\n+on:\n+ pull_request:\n+ types: [opened, synchronize]\n+\n+# Avoid unnecessary builds. Unlike the main CI jobs, these are not\n+# ci-configurable (but could be).\n+concurrency:\n+ group: ${{ github.workflow }}-${{ github.ref }}\n+ cancel-in-progress: true\n+\n+jobs:\n+ check-style:\n+ runs-on: ubuntu-latest\n+ steps:\n+ - uses: actions/checkout@v4\n+ with:\n+ fetch-depth: 0\n+\n+ - name: git clang-format\n+ continue-on-error: true\n+ id: check_out\n+ run: |\n+ ./ci/run-style-check.sh \\\n+ \"${{github.event.pull_request.base.sha}}\"\ndiff --git a/.gitlab-ci.yml b/.gitlab-ci.yml\nindex 37b991e080..14f9d3dc8e 100644\n--- a/.gitlab-ci.yml\n+++ b/.gitlab-ci.yml\n@@ -123,6 +123,30 @@ check-whitespace:\n rules:\n - if: $CI_PIPELINE_SOURCE == 'merge_request_event'\n \n+check-style:\n+ image: ubuntu:latest\n+ allow_failure: true\n+ variables:\n+ CC: clang\n+ before_script:\n+ - ./ci/install-dependencies.sh\n+ # Since $CI_MERGE_REQUEST_TARGET_BRANCH_SHA is only defined for merged\n+ # pipelines, we fallback to $CI_MERGE_REQUEST_DIFF_BASE_SHA, which should\n+ # be defined in all pipelines.\n+ script:\n+ - |\n+ if test -n \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\"\n+ then\n+ ./ci/run-style-check.sh \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\"\n+ elif test -n \"$CI_MERGE_REQUEST_DIFF_BASE_SHA\"\n+ then\n+ ./ci/run-style-check.sh \"$CI_MERGE_REQUEST_DIFF_BASE_SHA\"\n+ else\n+ echo \"CI_MERGE_REQUEST_DIFF_BASE_SHA should always exist!\"; exit 1\n+ fi\n+ rules:\n+ - if: $CI_PIPELINE_SOURCE == 'merge_request_event'\n+\n documentation:\n image: ubuntu:latest\n variables:\ndiff --git a/ci/install-dependencies.sh b/ci/install-dependencies.sh\nindex 6ec0f85972..46fe12a690 100755\n--- a/ci/install-dependencies.sh\n+++ b/ci/install-dependencies.sh\n@@ -43,7 +43,7 @@ ubuntu-*)\n \t\tmake libssl-dev libcurl4-openssl-dev libexpat-dev wget sudo default-jre \\\n \t\ttcl tk gettext zlib1g-dev perl-modules liberror-perl libauthen-sasl-perl \\\n \t\tlibemail-valid-perl libio-pty-perl libio-socket-ssl-perl libnet-smtp-ssl-perl libdbd-sqlite3-perl libcgi-pm-perl \\\n-\t\t${CC_PACKAGE:-${CC:-gcc}} $PYTHON_PACKAGE\n+\t\t${CC_PACKAGE:-${CC:-gcc}} $PYTHON_PACKAGE clang-format\n \n \tmkdir --parents \"$CUSTOM_PATH\"\n \twget --quiet --directory-prefix=\"$CUSTOM_PATH\" \\\ndiff --git a/ci/run-style-check.sh b/ci/run-style-check.sh\nnew file mode 100755\nindex 0000000000..76dd37d22b\n--- /dev/null\n+++ b/ci/run-style-check.sh\n@@ -0,0 +1,8 @@\n+#!/bin/sh\n+#\n+# Perform style check\n+#\n+\n+baseCommit=$1\n+\n+git clang-format --style file --diff --extensions c,h \"$baseCommit\"\n-- \n2.45.2\n\n"},{"id":"498621","messageId":"20240713134518.773053-8-karthik.188@gmail.com","threadId":"61750","inReplyTo":"20240713134518.773053-1-karthik.188@gmail.com","subject":"[PATCH v3 7/8] check-whitespace: detect if no base_commit is provided","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-13T13:45:17Z","receivedAt":"2024-07-13T13:45:30Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"The 'check-whitespace' CI script exits gracefully if no base commit is\nprovided or if an invalid revision is provided. This is not good because\nif a particular CI provides an incorrect base_commit, it would fail\nsuccessfully.\n\nThis is exactly the case with the GitLab CI. The CI is using the\n\"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\" variable to get the base commit\nSHA, but variable is only defined for _merged_ pipelines. So it is empty\nfor regular pipelines [1]. This should've failed the check-whitespace\njob.\n\nLet's fallback to 'CI_MERGE_REQUEST_DIFF_BASE_SHA' if\n\"CI_MERGE_REQUEST_TARGET_BRANCH_SHA\" isn't available in GitLab CI,\nsimilar to the previous commit. Let's also add a check for incorrect\nbase_commit in the 'check-whitespace.sh' script. While here, fix a small\ntypo too.\n\n[1]: https://docs.gitlab.com/ee/ci/variables/predefined_variables.html#predefined-variables-for-merge-request-pipelines\n\nSigned-off-by: Karthik Nayak \n---\n .gitlab-ci.yml | 14 +++++++++++++-\n ci/check-whitespace.sh | 10 ++++++++--\n 2 files changed, 21 insertions(+), 3 deletions(-)\n\ndiff --git a/.gitlab-ci.yml b/.gitlab-ci.yml\nindex 14f9d3dc8e..0596a01b68 100644\n--- a/.gitlab-ci.yml\n+++ b/.gitlab-ci.yml\n@@ -118,8 +118,20 @@ check-whitespace:\n image: ubuntu:latest\n before_script:\n - ./ci/install-dependencies.sh\n+ # Since $CI_MERGE_REQUEST_TARGET_BRANCH_SHA is only defined for merged\n+ # pipelines, we fallback to $CI_MERGE_REQUEST_DIFF_BASE_SHA, which should\n+ # be defined in all pipelines.\n script:\n- - ./ci/check-whitespace.sh \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\"\n+ - |\n+ if test -n \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\"\n+ then\n+ ./ci/check-whitespace.sh \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\"\n+ elif test -n \"$CI_MERGE_REQUEST_DIFF_BASE_SHA\"\n+ then\n+ ./ci/check-whitespace.sh \"$CI_MERGE_REQUEST_DIFF_BASE_SHA\"\n+ else\n+ echo \"CI_MERGE_REQUEST_DIFF_BASE_SHA should always exist!\"; exit 1\n+ fi\n rules:\n - if: $CI_PIPELINE_SOURCE == 'merge_request_event'\n \ndiff --git a/ci/check-whitespace.sh b/ci/check-whitespace.sh\nindex db399097a5..c40804394c 100755\n--- a/ci/check-whitespace.sh\n+++ b/ci/check-whitespace.sh\n@@ -9,7 +9,7 @@ baseCommit=$1\n outputFile=$2\n url=$3\n \n-if test \"$#\" -ne 1 && test \"$#\" -ne 3\n+if test \"$#\" -ne 1 && test \"$#\" -ne 3 || test -z \"$1\"\n then\n \techo \"USAGE: $0 [ ]\"\n \texit 1\n@@ -21,6 +21,12 @@ commitText=\n commitTextmd=\n goodParent=\n \n+if ! git rev-parse --quiet --verify \"${baseCommit}\"\n+then\n+ echo \"Invalid '${baseCommit}'\"\n+ exit 1\n+fi\n+\n while read dash sha etc\n do\n \tcase \"${dash}\" in\n@@ -67,7 +73,7 @@ then\n \t\tgoodParent=${baseCommit: 0:7}\n \tfi\n \n-\techo \"A whitespace issue was found in onen of more of the commits.\"\n+\techo \"A whitespace issue was found in one or more of the commits.\"\n \techo \"Run the following command to resolve whitespace issues:\"\n \techo \"git rebase --whitespace=fix ${goodParent}\"\n \n-- \n2.45.2\n\n"},{"id":"498622","messageId":"20240713134518.773053-9-karthik.188@gmail.com","threadId":"61750","inReplyTo":"20240713134518.773053-1-karthik.188@gmail.com","subject":"[PATCH v3 8/8] ci/style-check: add `RemoveBracesLLVM` to '.clang-format'","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-13T13:45:18Z","receivedAt":"2024-07-13T13:45:31Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"For 'clang-format' setting 'RemoveBracesLLVM' to 'true', adds a check\nto ensure we avoid curly braces for single-statement bodies in\nconditional blocks.\n\nHowever, the option does come with two warnings [1]:\n\n This option will be renamed and expanded to support other styles.\n\nand\n\n Setting this option to true could lead to incorrect code formatting\n due to clang-format’s lack of complete semantic information. As\n such, extra care should be taken to review code changes made by\n this option.\n\nThe latter seems to be of concern. While we want to experiment with the\nrule, adding it to the in-tree '.clang-format' could affect end-users.\nLet's only add it to the CI jobs for now. With time, we can evaluate\nits efficacy and decide if we want to add it to '.clang-format' or\nretract it entirely.\n\n[1]: https://clang.llvm.org/docs/ClangFormatStyleOptions.html#removebracesllvm\n\nSigned-off-by: Karthik Nayak \n---\n ci/run-style-check.sh | 13 +++++++++++++\n 1 file changed, 13 insertions(+)\n\ndiff --git a/ci/run-style-check.sh b/ci/run-style-check.sh\nindex 76dd37d22b..1dce50a0ac 100755\n--- a/ci/run-style-check.sh\n+++ b/ci/run-style-check.sh\n@@ -5,4 +5,17 @@\n \n baseCommit=$1\n \n+# Remove optional braces of control statements (if, else, for, and while)\n+# according to the LLVM coding style. This avoids braces on simple\n+# single-statement bodies of statements but keeps braces if one side of\n+# if/else if/.../else cascade has multi-statement body.\n+#\n+# As this rule comes with a warning [1], we want to experiment with it\n+# before adding it in-tree. since the CI job for the style check is allowed\n+# to fail, appending the rule here allows us to validate its efficacy.\n+# While also ensuring that end-users are not affected directly.\n+#\n+# [1]: https://clang.llvm.org/docs/ClangFormatStyleOptions.html#removebracesllvm\n+echo \"RemoveBracesLLVM: true\" >> .clang-format\n+\n git clang-format --style file --diff --extensions c,h \"$baseCommit\"\n-- \n2.45.2\n\n"},{"id":"498623","messageId":"57402963-a95a-4bd8-9eb1-1764e0611bb5@gmail.com","threadId":"61750","inReplyTo":"CAOLa=ZSrVOBkziX+z3g1RqudiLp=SN4gW=OL5Ky++KukPF=QXA@mail.gmail.com","subject":"Re: [PATCH 5/8] clang-format: avoid braces on simple single-statement bodies","fromName":"","fromEmail":"phillip.wood123@gmail.com","sentAt":"2024-07-13T13:58:12Z","receivedAt":"2024-07-13T13:58:15Z","isPatch":true,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"On 13/07/2024 13:30, Karthik Nayak wrote:\n> Phillip Wood writes:\n >\n>> I'm a bit confused - what does \"allowed to fail\" mean? We don't have any\n>> automated requirements on the CI passing. We don't want to train\n>> contributors to routinely ignore CI failures but if they don't get a\n>> notification that this job failed how do they know to correct the\n>> formatting?\n>>\n> \n> Well, it mostly means that the CI would show the style-check job as\n> failed, but the overall pipeline would be successful.\n\nAh, I didn't know that was a possibility - do users still get emails \nabout the failed job?\n\n> We want to ideally\n> fail the pipeline too, but I'm being careful to not disrupt things\n> suddenly and I think once we see what false positive rate is and once we\n> fine tune this settings maybe over the next release or so, we can\n> enforce this.\n\nStarting gently to get some experience with the auto formatter sounds \nsensible. Thanks for working on this, I really hope that once we've got \nmore experience with clang format we can figure out how to enable it \nunconditionally.\n\nBest Wishes\n\nPhillip\n"},{"id":"498624","messageId":"CAOLa=ZSiJArgDr6oDTbHN2vaF1mjUjrKbKbw4aDOjMf-bMUFyA@mail.gmail.com","threadId":"61750","inReplyTo":"57402963-a95a-4bd8-9eb1-1764e0611bb5@gmail.com","subject":"Re: [PATCH 5/8] clang-format: avoid braces on simple single-statement bodies","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-13T14:16:35Z","receivedAt":"2024-07-13T14:16:37Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"phillip.wood123@gmail.com writes:\n\n> On 13/07/2024 13:30, Karthik Nayak wrote:\n>> Phillip Wood writes:\n> >\n>>> I'm a bit confused - what does \"allowed to fail\" mean? We don't have any\n>>> automated requirements on the CI passing. We don't want to train\n>>> contributors to routinely ignore CI failures but if they don't get a\n>>> notification that this job failed how do they know to correct the\n>>> formatting?\n>>>\n>>\n>> Well, it mostly means that the CI would show the style-check job as\n>> failed, but the overall pipeline would be successful.\n>\n> Ah, I didn't know that was a possibility - do users still get emails\n> about the failed job?\n>\n\nI know in GitLab, users _wouldn't_ get an email. This would be a nice\nintermediate step, but I think it is still okay.\n\n>> We want to ideally\n>> fail the pipeline too, but I'm being careful to not disrupt things\n>> suddenly and I think once we see what false positive rate is and once we\n>> fine tune this settings maybe over the next release or so, we can\n>> enforce this.\n>\n> Starting gently to get some experience with the auto formatter sounds\n> sensible. Thanks for working on this, I really hope that once we've got\n> more experience with clang format we can figure out how to enable it\n> unconditionally.\n>\n> Best Wishes\n>\n> Phillip\n\nJust to clarify, enabling an auto-formatter would always be left to the\nuser. From the project's perspective, the goal would be to have checks\nto notify us (us as in the Git project) if a particular patch series\nfails to comply to our standards.\n\nThis is done by enforcing the CI rule _eventually_. Users can also\nbenefit from this if they use the CI for development purposes. One good\nexample being users of GitGitGadget, where they would be notified of\nfailures in the CI. Another example is contributions coming from GitLab,\nwhere our team uses the CI before sending patches upstream.\n\nSince the Git project already comes with a '.clang-format', users can\nalready enable auto-formatting on their end. I know the clangd LSP\nalready supports this. ;)\n\nThanks\nKarthik\n"},{"id":"498625","messageId":"xmqqa5ilcngi.fsf@gitster.g","threadId":"61750","inReplyTo":"20240713134518.773053-9-karthik.188@gmail.com","subject":"Re: [PATCH v3 8/8] ci/style-check: add `RemoveBracesLLVM` to '.clang-format'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-07-13T15:37:33Z","receivedAt":"2024-07-13T15:37:36Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Karthik Nayak writes:\n\n> +# [1]: https://clang.llvm.org/docs/ClangFormatStyleOptions.html#removebracesllvm\n> +echo \"RemoveBracesLLVM: true\" >> .clang-format\n> +\n> git clang-format --style file --diff --extensions c,h \"$baseCommit\"\n\nStyle: lose the SP between the redirection operator and its operand.\n\nI know this is well intentioned, but will there be any downsides for\nrunning the check always against a dirty working tree? \n\nI know during a CI run, the working tree will not be completely\nclean, as we create and leave build artifacts, but this is as far as\nI know the first instance of us munging a tracked path, changing the\nworking tree in a way that \"git describe --dirty\" would notice.\n\nThis is done as the last (and only) step of check-style job and the\nci/run-style-check.sh script may not do anything like \"git describe\n--dirty\" right now, but things can change. Perhaps I am worried\nabout this a bit too much.\n\nI unfortunately couldn't find an option to \"git clang-format\" to\ntell it to read from an extra file in addition to the usual\n\".clang-format\" file---if such an option existed, we obviously could\nuse an untracked/ignored file to prepare the custom format file and\nuse it without making the working tree dirty.\n\nSo perhaps the posted change, while making us feel dirty, is the\nbest we could do for this step.\n\nThanks.\n\n\n"},{"id":"498626","messageId":"xmqqwmlpb8er.fsf@gitster.g","threadId":"61750","inReplyTo":"20240713134518.773053-7-karthik.188@gmail.com","subject":"Re: [PATCH v3 6/8] ci: run style check on GitHub and GitLab","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-07-13T15:47:56Z","receivedAt":"2024-07-13T15:47:59Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Karthik Nayak writes:\n\n> + # Since $CI_MERGE_REQUEST_TARGET_BRANCH_SHA is only defined for merged\n> + # pipelines, we fallback to $CI_MERGE_REQUEST_DIFF_BASE_SHA, which should\n> + # be defined in all pipelines.\n> + script:\n> + - |\n> + if test -n \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\"\n> + then\n> + ./ci/run-style-check.sh \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\"\n> + elif test -n \"$CI_MERGE_REQUEST_DIFF_BASE_SHA\"\n> + then\n> + ./ci/run-style-check.sh \"$CI_MERGE_REQUEST_DIFF_BASE_SHA\"\n> + else\n> + echo \"CI_MERGE_REQUEST_DIFF_BASE_SHA should always exist!\"; exit 1\n> + fi\n\nThis is fine but we may want to reduce the repetition of the long path\nto the script, e.g., by doing something like\n\n\tif test -n \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\"\n\tthen\n\t\tR=$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\n\telif test -n \"$CI_MERGE_REQUEST_DIFF_BASE_SHA\"\n\tthen\n\t\tR=\"$CI_MERGE_REQUEST_DIFF_BASE_SHA\"\n\tfi\n\n\tif test -z \"$R\"\n\tthen\n\t\techo \"CI_MERGE_REQUEST_DIFF_BASE_SHA should always exist!\"\n\t\texit 1\n\tfi\n\t./ci/run-style-check.sh \"$R\"\n\nin a separate \"after the dust settles\" clean-up #leftoverbits topic.\nWe could replace the first 7 lines with a single-liner\n\n\tR=${CI_MERGE_REQUEST_TARGET_BRANCH_SHA-${CI_MERGE_REQUEST_DIFF_BASE_SHA?}}\n\nif we wanted to, but all of that will be mere clean-up changes.\n"},{"id":"498637","messageId":"CAOLa=ZTkYs_Wz2YM82Nm0yPJX8-hYV3WC-aMEqYNRoS+2ZpG3A@mail.gmail.com","threadId":"61750","inReplyTo":"xmqqa5ilcngi.fsf@gitster.g","subject":"Re: [PATCH v3 8/8] ci/style-check: add `RemoveBracesLLVM` to '.clang-format'","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-13T16:46:16Z","receivedAt":"2024-07-13T16:46:18Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"Junio C Hamano writes:\n\n> Karthik Nayak writes:\n>\n>> +# [1]: https://clang.llvm.org/docs/ClangFormatStyleOptions.html#removebracesllvm\n>> +echo \"RemoveBracesLLVM: true\" >> .clang-format\n>> +\n>> git clang-format --style file --diff --extensions c,h \"$baseCommit\"\n>\n> Style: lose the SP between the redirection operator and its operand.\n>\n\nWill change.\n\n> I know this is well intentioned, but will there be any downsides for\n> running the check always against a dirty working tree?\n>\n> I know during a CI run, the working tree will not be completely\n> clean, as we create and leave build artifacts, but this is as far as\n> I know the first instance of us munging a tracked path, changing the\n> working tree in a way that \"git describe --dirty\" would notice.\n>\n> This is done as the last (and only) step of check-style job and the\n> ci/run-style-check.sh script may not do anything like \"git describe\n> --dirty\" right now, but things can change. Perhaps I am worried\n> about this a bit too much.\n>\n\nExactly my thoughts too. I did test on GitLab's CI and all other jobs\nwere unaffected. So I think we're good here.\n\n---\n\nAfter reading your mail, I figured I should also check GitHub's CI for\nthis particular change and realized there is a slight issue with my\ncurrent series.\n\nGitLab's CI highlights style check jobs which failed with a yellow\nwarning symbol [1], even with the 'ignore failing check-style'\ndirective. But GitHub's actions, simply marks the job as successful even\nif the job failed [1]. This was an oversight on my side, since I\nexpected similar behavior. Seems like the required dependency wasn't\neven installed on GitHub causing 'git clang-format' to fail.\n\nUnfortunately this means all GitHub workflows for style-check will be\ngreen even if there were style issues found. I couldn't find a way to\nfix this from reading the documentation.\n\nThis will not be an issue once we enforce, but till then users cannot\nrely on the job's outcome for the job's status in GitHub. They will have\nto see the logs to know if style check failed.\n\nI will re-roll with a fix, but will wait a day or so, to avoid spamming.\n\n> I unfortunately couldn't find an option to \"git clang-format\" to\n> tell it to read from an extra file in addition to the usual\n> \".clang-format\" file---if such an option existed, we obviously could\n> use an untracked/ignored file to prepare the custom format file and\n> use it without making the working tree dirty.\n>\n\nThis was also something I looked for, but couldn't find. I should have\nadded that to the commit message. Will do so in the reroll.\n\n> So perhaps the posted change, while making us feel dirty, is the\n> best we could do for this step.\n>\n> Thanks.\n\nYes, I think it is okay. I'm hoping we can move it in-tree someday.\n\n[1]: https://gitlab.com/gitlab-org/git/-/pipelines/1372326813\n[2]: https://github.com/KarthikNayak/git/actions/runs/9921272597/job/27409047062\n"},{"id":"498653","messageId":"cccf899d-12c4-4046-a958-33374bb870c6@ramsayjones.plus.com","threadId":"61750","inReplyTo":"CAOLa=ZTkYs_Wz2YM82Nm0yPJX8-hYV3WC-aMEqYNRoS+2ZpG3A@mail.gmail.com","subject":"Re: [PATCH v3 8/8] ci/style-check: add `RemoveBracesLLVM` to '.clang-format'","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2024-07-13T23:18:32Z","receivedAt":"2024-07-13T23:21:42Z","isPatch":true,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"\n\nOn 13/07/2024 17:46, Karthik Nayak wrote:\n> Junio C Hamano writes:\n[snip]\n\n>> I unfortunately couldn't find an option to \"git clang-format\" to\n>> tell it to read from an extra file in addition to the usual\n>> \".clang-format\" file---if such an option existed, we obviously could\n>> use an untracked/ignored file to prepare the custom format file and\n>> use it without making the working tree dirty.\n>>\n> \n> This was also something I looked for, but couldn't find. I should have\n> added that to the commit message. Will do so in the reroll.\n> \n\nI had a need recently to try applying the git '.clang-format' file to a\ndifferent project:\n \n $ pwd\n /home/ramsay/sparse\n $ clang-format --style=file:/home/ramsay/git/.clang-format sparse.c >xxx.c\n $ meld sparse.c xxx.c # oh my lord :)\n\nNote that I had to specify '/home/ramsay/' rather than just '~', since it\ndoes not get recognized/expanded in that position:\n\n $ clang-format --style=file:~/git/.clang-format sparse.c >xxx.c\n Error reading ~/git/.clang-format: No such file or directory\n $ rm xxx.c\n\nAlso, as you can see, this was 'clang-format' not 'git-clang-format' (which\nis what would actually be used in this situation), but the '--help' text\nclaims that:\n\n $ git-clang-format --help | grep style\n clangFormat.style\n --style STYLE passed to clang-format\n $ \n\n.. so it should work (but I have not actually tried it, so YMMV ;) ).\n\n[So, munging the .clang-format file with sed (say) to a temp file and\nusing the --style=file:tmp-file syntax should (hopefully) work]\n\nATB,\nRamsay Jones\n\n \n\n"},{"id":"498709","messageId":"CAOLa=ZQfhD21Anzd3wWwWcxji7tJydaiD7mrhReH5zLQdXBWng@mail.gmail.com","threadId":"61750","inReplyTo":"cccf899d-12c4-4046-a958-33374bb870c6@ramsayjones.plus.com","subject":"Re: [PATCH v3 8/8] ci/style-check: add `RemoveBracesLLVM` to '.clang-format'","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-15T08:10:49Z","receivedAt":"2024-07-15T08:10:52Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"Ramsay Jones writes:\n\n> On 13/07/2024 17:46, Karthik Nayak wrote:\n>> Junio C Hamano writes:\n> [snip]\n>\n>>> I unfortunately couldn't find an option to \"git clang-format\" to\n>>> tell it to read from an extra file in addition to the usual\n>>> \".clang-format\" file---if such an option existed, we obviously could\n>>> use an untracked/ignored file to prepare the custom format file and\n>>> use it without making the working tree dirty.\n>>>\n>>\n>> This was also something I looked for, but couldn't find. I should have\n>> added that to the commit message. Will do so in the reroll.\n>>\n>\n> I had a need recently to try applying the git '.clang-format' file to a\n> different project:\n>\n> $ pwd\n> /home/ramsay/sparse\n> $ clang-format --style=file:/home/ramsay/git/.clang-format sparse.c >xxx.c\n> $ meld sparse.c xxx.c # oh my lord :)\n>\n> Note that I had to specify '/home/ramsay/' rather than just '~', since it\n> does not get recognized/expanded in that position:\n>\n> $ clang-format --style=file:~/git/.clang-format sparse.c >xxx.c\n> Error reading ~/git/.clang-format: No such file or directory\n> $ rm xxx.c\n>\n> Also, as you can see, this was 'clang-format' not 'git-clang-format' (which\n> is what would actually be used in this situation), but the '--help' text\n> claims that:\n>\n> $ git-clang-format --help | grep style\n> clangFormat.style\n> --style STYLE passed to clang-format\n> $\n>\n> .. so it should work (but I have not actually tried it, so YMMV ;) ).\n>\n> [So, munging the .clang-format file with sed (say) to a temp file and\n> using the --style=file:tmp-file syntax should (hopefully) work]\n>\n> ATB,\n> Ramsay Jones\n>\n>\n\nHello,\n\nProviding a path does work indeed. But we were discussing the option to\nprovide an additional path apart from the default '.clang-format'. The\noption you mentioned `--style=` will set the config to the\ncontents of , but we want to add on top of that. So that we\ncould hypothetically do something like\n\n $ git clang-format --style file --style-append '.ci-clang-format'\n--diff --extensions c,h\n\nBut seems like this is currently not possible.\n"},{"id":"498710","messageId":"20240715093047.49321-1-karthik.188@gmail.com","threadId":"61750","inReplyTo":"20240713134518.773053-1-karthik.188@gmail.com","subject":"[PATCH v4 0/8] clang-format: add more rules and enable on CI","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-15T09:30:39Z","receivedAt":"2024-07-15T09:30:51Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"This is v3 of my series to add clang-format to the CI.\n\nThe series was mostly inspired by a patch sent recently to 'include\nkh_foreach* macros in ForEachMacros' [1]. I was wondering why we don't\nrun the formatting on CI and reduce some of the workload of reviewers.\n\nWe have a '.clang-format' file to provide rules for code formatting.\nThe commits 1-5 aims to add more rules to the file while deprecating old\nones.\n\nCommit 6 enables CI action on GitHub and GitLab to also check for the\ncode formatting. Currently, it is allowed to fail. This way we can build\nconfidence and fine tune the values as needed and finally enforce the\ncheck in a future patch. I'm not well versed with GitHub workflows, and\nI mostly tried to copy existing work there. Expecting some feedback in\nthat section!\n\nCommit 7 fixes an existing issue with the 'check-whitespace' job, which\nis failing as success in the GitLab CI.\n\nCommit 8 adds the `RemoveBracesLLVM` only in the context of the CI. If we\ndecide against it, we could drop this commit from the series.\n\n1: https://lore.kernel.org/git/4e7893f5-2dd9-46cf-8a64-cf780f4e1730@web.de/\n\nChanges against v3:\n- The job was actually failing on GitHub but showing a success since we added\nthe allow to fail clause. This was because the dependency wasn't installed.\nHave fixed that in this version.\n- Simplified the bash script in the GitLab job, thanks to Junio.\n- Fixed a style issue with redirection. \n- Added some more details to the commit messages. \n\nJob running on:\n- GitHub: https://github.com/KarthikNayak/git/actions/runs/9936188558/job/27443871938?pr=1\n- GitLab: https://gitlab.com/gitlab-org/git/-/jobs/7340770469\n\nKarthik Nayak (8):\n clang-format: indent preprocessor directives after hash\n clang-format: avoid spacing around bitfield colon\n clang-format: ensure files end with newlines\n clang-format: replace deprecated option with 'SpacesInParens'\n clang-format: formalize some of the spacing rules\n ci: run style check on GitHub and GitLab\n check-whitespace: detect if no base_commit is provided\n ci/style-check: add `RemoveBracesLLVM` to '.clang-format'\n\n .clang-format | 36 +++++++++++++++++++++++++-----\n .github/workflows/check-style.yml | 34 ++++++++++++++++++++++++++++\n .gitlab-ci.yml | 37 ++++++++++++++++++++++++++++++-\n ci/check-whitespace.sh | 10 +++++++--\n ci/install-dependencies.sh | 6 ++++-\n ci/run-style-check.sh | 21 ++++++++++++++++++\n 6 files changed, 135 insertions(+), 9 deletions(-)\n create mode 100644 .github/workflows/check-style.yml\n create mode 100755 ci/run-style-check.sh\n\nRange-diff against v3:\n1: 6cf91ffc86 = 1: 6cf91ffc86 clang-format: indent preprocessor directives after hash\n2: beb002885f = 2: beb002885f clang-format: avoid spacing around bitfield colon\n3: 3031be43e7 = 3: 3031be43e7 clang-format: ensure files end with newlines\n4: bc1550e300 = 4: bc1550e300 clang-format: replace deprecated option with 'SpacesInParens'\n5: 4586c0094b = 5: 4586c0094b clang-format: formalize some of the spacing rules\n6: c18cb23369 ! 6: f8eba92c0c ci: run style check on GitHub and GitLab\n @@ Commit message\n this job to fail, so we can validate if this is useful and eventually\n enforce it.\n \n - For GitLab, we use the 'CI_MERGE_REQUEST_TARGET_BRANCH_SHA' variable by\n - default to obtain the base SHA of the merged pipeline (which is only\n - available for merged pipelines [1]). Otherwise we use the\n + For GitHub, we allow the job to pass by adding 'continue-on-error: true'\n + to the workflow. This means the job would show as passed, even if the\n + style check failed. To know the status of the job, users have to\n + manually check the logs.\n +\n + For GitLab, we allow the job to pass by adding 'allow_failure: true', to\n + the job. Unlike GitHub, here the job will show as failed with a yellow\n + warning symbol, but the pipeline would still show as passed.\n +\n + Also for GitLab, we use the 'CI_MERGE_REQUEST_TARGET_BRANCH_SHA'\n + variable by default to obtain the base SHA of the merged pipeline (which\n + is only available for merged pipelines [1]). Otherwise we use the\n 'CI_MERGE_REQUEST_DIFF_BASE_SHA' variable.\n \n [1]: https://docs.gitlab.com/ee/ci/variables/predefined_variables.html#predefined-variables-for-merge-request-pipelines\n \n + Helped-by: Junio C Hamano \n Signed-off-by: Karthik Nayak \n \n ## .github/workflows/check-style.yml (new) ##\n @@ .github/workflows/check-style.yml (new)\n +\n +jobs:\n + check-style:\n ++ env:\n ++ CC: clang\n ++ jobname: ClangFormat\n + runs-on: ubuntu-latest\n + steps:\n + - uses: actions/checkout@v4\n + with:\n + fetch-depth: 0\n +\n ++ - run: ci/install-dependencies.sh\n ++\n + - name: git clang-format\n + continue-on-error: true\n + id: check_out\n @@ .gitlab-ci.yml: check-whitespace:\n + allow_failure: true\n + variables:\n + CC: clang\n ++ jobname: ClangFormat\n + before_script:\n + - ./ci/install-dependencies.sh\n + # Since $CI_MERGE_REQUEST_TARGET_BRANCH_SHA is only defined for merged\n @@ .gitlab-ci.yml: check-whitespace:\n + # be defined in all pipelines.\n + script:\n + - |\n -+ if test -n \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\"\n -+ then\n -+ ./ci/run-style-check.sh \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\"\n -+ elif test -n \"$CI_MERGE_REQUEST_DIFF_BASE_SHA\"\n ++ R=${CI_MERGE_REQUEST_TARGET_BRANCH_SHA-${CI_MERGE_REQUEST_DIFF_BASE_SHA?}}\n ++\n ++ if test -z \"$R\"\n + then\n -+ ./ci/run-style-check.sh \"$CI_MERGE_REQUEST_DIFF_BASE_SHA\"\n -+ else\n -+ echo \"CI_MERGE_REQUEST_DIFF_BASE_SHA should always exist!\"; exit 1\n ++ echo \"CI_MERGE_REQUEST_DIFF_BASE_SHA should always exist!\"\n ++ exit 1\n + fi\n ++ ./ci/run-style-check.sh \"$R\"\n + rules:\n + - if: $CI_PIPELINE_SOURCE == 'merge_request_event'\n +\n @@ ci/install-dependencies.sh: ubuntu-*)\n \n \tmkdir --parents \"$CUSTOM_PATH\"\n \twget --quiet --directory-prefix=\"$CUSTOM_PATH\" \\\n +@@ ci/install-dependencies.sh: macos-*)\n + esac\n + \n + case \"$jobname\" in\n ++ClangFormat)\n ++\tsudo apt-get -q update\n ++\tsudo apt-get -q -y install clang-format\n ++\t;;\n + StaticAnalysis)\n + \tsudo apt-get -q update\n + \tsudo apt-get -q -y install coccinelle libcurl4-openssl-dev libssl-dev \\\n \n ## ci/run-style-check.sh (new) ##\n @@\n7: 4d08c570bb ! 7: 477419fc6b check-whitespace: detect if no base_commit is provided\n @@ Commit message\n \n [1]: https://docs.gitlab.com/ee/ci/variables/predefined_variables.html#predefined-variables-for-merge-request-pipelines\n \n + Helped-by: Junio C Hamano \n Signed-off-by: Karthik Nayak \n \n ## .gitlab-ci.yml ##\n @@ .gitlab-ci.yml: check-whitespace:\n script:\n - - ./ci/check-whitespace.sh \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\"\n + - |\n -+ if test -n \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\"\n -+ then\n -+ ./ci/check-whitespace.sh \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\"\n -+ elif test -n \"$CI_MERGE_REQUEST_DIFF_BASE_SHA\"\n ++ R=${CI_MERGE_REQUEST_TARGET_BRANCH_SHA-${CI_MERGE_REQUEST_DIFF_BASE_SHA?}}\n ++\n ++ if test -z \"$R\"\n + then\n -+ ./ci/check-whitespace.sh \"$CI_MERGE_REQUEST_DIFF_BASE_SHA\"\n -+ else\n -+ echo \"CI_MERGE_REQUEST_DIFF_BASE_SHA should always exist!\"; exit 1\n ++ echo \"CI_MERGE_REQUEST_DIFF_BASE_SHA should always exist!\"\n ++ exit 1\n + fi\n ++ ./ci/check-whitespace.sh \"$R\"\n rules:\n - if: $CI_PIPELINE_SOURCE == 'merge_request_event'\n \n8: 2b39431f93 ! 8: 50007c17da ci/style-check: add `RemoveBracesLLVM` to '.clang-format'\n @@ Commit message\n its efficacy and decide if we want to add it to '.clang-format' or\n retract it entirely.\n \n + A more ideal solution would be if 'clang-format' allowed us to append\n + rules to the existing '.clang-format' when invoked. But such an option\n + does not exist. Since modifying the in-tree '.clang-format' is only done\n + on the CI job for style-check and doesn't affect any other jobs and is\n + not persisted in any ways, this hack should be okay.\n +\n [1]: https://clang.llvm.org/docs/ClangFormatStyleOptions.html#removebracesllvm\n \n Signed-off-by: Karthik Nayak \n @@ ci/run-style-check.sh\n +# While also ensuring that end-users are not affected directly.\n +#\n +# [1]: https://clang.llvm.org/docs/ClangFormatStyleOptions.html#removebracesllvm\n -+echo \"RemoveBracesLLVM: true\" >> .clang-format\n ++echo \"RemoveBracesLLVM: true\" >>.clang-format\n +\n git clang-format --style file --diff --extensions c,h \"$baseCommit\"\n-- \n2.45.2\n\n"},{"id":"498711","messageId":"20240715093047.49321-2-karthik.188@gmail.com","threadId":"61750","inReplyTo":"20240715093047.49321-1-karthik.188@gmail.com","subject":"[PATCH v4 1/8] clang-format: indent preprocessor directives after hash","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-15T09:30:40Z","receivedAt":"2024-07-15T09:30:52Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"We do not have a rule around the indentation of preprocessor directives.\nThis was also discussed on the list [1], noting how there is often\ninconsistency in the styling. While there was discussion, there was no\nconclusion around what is the preferred style here. One style being\nindenting after the hash:\n\n #if FOO\n # if BAR\n # include \n # endif\n #endif\n\nThe other being before the hash:\n\n #if FOO\n #if BAR\n #include \n #endif\n #endif\n\nLet's pick the former and add 'IndentPPDirectives: AfterHash' value to\nour '.clang-format'. There is no clear reason to pick one over the\nother, but it would definitely be nicer to be consistent.\n\n[1]: https://lore.kernel.org/r/xmqqwmmm1bw6.fsf@gitster.g\n\nSigned-off-by: Karthik Nayak \n---\n .clang-format | 6 ++++++\n 1 file changed, 6 insertions(+)\n\ndiff --git a/.clang-format b/.clang-format\nindex 3ed4fac753..5e128519bf 100644\n--- a/.clang-format\n+++ b/.clang-format\n@@ -96,6 +96,12 @@ BreakStringLiterals: false\n # Switch statement body is always indented one level more than case labels.\n IndentCaseLabels: false\n \n+# Indents directives before the hash.\n+# #if FOO\n+# # include \n+# #endif\n+IndentPPDirectives: AfterHash\n+\n # Don't indent a function definition or declaration if it is wrapped after the\n # type\n IndentWrappedFunctionNames: false\n-- \n2.45.2\n\n"},{"id":"498712","messageId":"20240715093047.49321-3-karthik.188@gmail.com","threadId":"61750","inReplyTo":"20240715093047.49321-1-karthik.188@gmail.com","subject":"[PATCH v4 2/8] clang-format: avoid spacing around bitfield colon","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-15T09:30:41Z","receivedAt":"2024-07-15T09:30:53Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"The spacing around colons is currently not standardized and as such we\nhave the following practices in our code base:\n- Spacing around the colon `int bf : 1`: 146 instances\n- No spacing around the colon `int bf:1`: 148 instances\n- Spacing before the colon `int bf :1`: 6 instances\n- Spacing after the colon `int bf: 1`: 12 instances\n\nLet's formalize this by picking the most followed pattern and add the\ncorresponding style to '.clang-format'.\n\nSigned-off-by: Karthik Nayak \n---\n .clang-format | 4 ++++\n 1 file changed, 4 insertions(+)\n\ndiff --git a/.clang-format b/.clang-format\nindex 5e128519bf..803b274dd5 100644\n--- a/.clang-format\n+++ b/.clang-format\n@@ -72,6 +72,10 @@ AlwaysBreakAfterReturnType: None\n BinPackArguments: true\n BinPackParameters: true\n \n+# Add no space around the bit field\n+# unsigned bf:2;\n+BitFieldColonSpacing: None\n+\n # Attach braces to surrounding context except break before braces on function\n # definitions.\n # void foo()\n-- \n2.45.2\n\n"},{"id":"498713","messageId":"20240715093047.49321-4-karthik.188@gmail.com","threadId":"61750","inReplyTo":"20240715093047.49321-1-karthik.188@gmail.com","subject":"[PATCH v4 3/8] clang-format: ensure files end with newlines","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-15T09:30:42Z","receivedAt":"2024-07-15T09:30:54Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"All our source files end with a newline, let's formalize in\n'.clang-format'.\n\nSigned-off-by: Karthik Nayak \n---\n .clang-format | 3 +++\n 1 file changed, 3 insertions(+)\n\ndiff --git a/.clang-format b/.clang-format\nindex 803b274dd5..4c9751a9db 100644\n--- a/.clang-format\n+++ b/.clang-format\n@@ -106,6 +106,9 @@ IndentCaseLabels: false\n # #endif\n IndentPPDirectives: AfterHash\n \n+# Insert a newline at end of file if missing\n+InsertNewlineAtEOF: true\n+\n # Don't indent a function definition or declaration if it is wrapped after the\n # type\n IndentWrappedFunctionNames: false\n-- \n2.45.2\n\n"},{"id":"498714","messageId":"20240715093047.49321-5-karthik.188@gmail.com","threadId":"61750","inReplyTo":"20240715093047.49321-1-karthik.188@gmail.com","subject":"[PATCH v4 4/8] clang-format: replace deprecated option with 'SpacesInParens'","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-15T09:30:43Z","receivedAt":"2024-07-15T09:30:55Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"Replace the deprecated options 'SpacesInParentheses' and\n'SpaceInEmptyParentheses' with the newer 'SpacesInParens' option. The\nusage is the same.\n\nSigned-off-by: Karthik Nayak \n---\n .clang-format | 9 ++++-----\n 1 file changed, 4 insertions(+), 5 deletions(-)\n\ndiff --git a/.clang-format b/.clang-format\nindex 4c9751a9db..914254a29b 100644\n--- a/.clang-format\n+++ b/.clang-format\n@@ -134,8 +134,6 @@ SpaceBeforeAssignmentOperators: true\n # }\n SpaceBeforeParens: ControlStatements\n \n-# Don't insert spaces inside empty '()'\n-SpaceInEmptyParentheses: false\n \n # The number of spaces before trailing line comments (// - comments).\n # This does not affect trailing block comments (/* - comments).\n@@ -149,9 +147,10 @@ SpacesInCStyleCastParentheses: false\n # var arr = [1, 2, 3]; not var arr = [ 1, 2, 3 ];\n SpacesInContainerLiterals: false\n \n-# Don't insert spaces after '(' or before ')'\n-# f(arg); not f( arg );\n-SpacesInParentheses: false\n+SpacesInParens: Custom\n+SpacesInParensOptions:\n+ # Don't insert spaces inside empty '()'\n+ InEmptyParentheses: false\n \n # Don't insert spaces after '[' or before ']'\n # int a[5]; not int a[ 5 ];\n-- \n2.45.2\n\n"},{"id":"498715","messageId":"20240715093047.49321-6-karthik.188@gmail.com","threadId":"61750","inReplyTo":"20240715093047.49321-1-karthik.188@gmail.com","subject":"[PATCH v4 5/8] clang-format: formalize some of the spacing rules","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-15T09:30:44Z","receivedAt":"2024-07-15T09:30:56Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"There are some spacing rules that we follow in the project and it makes\nsense to formalize them:\n* Ensure there is no space inserted after the logical not '!' operator.\n* Ensure there is no space before the case statement's colon.\n* Ensure there is no space before the first bracket '[' of an array.\n* Ensure there is no space in empty blocks.\n\nSigned-off-by: Karthik Nayak \n---\n .clang-format | 14 ++++++++++++++\n 1 file changed, 14 insertions(+)\n\ndiff --git a/.clang-format b/.clang-format\nindex 914254a29b..a0dd1f2eb9 100644\n--- a/.clang-format\n+++ b/.clang-format\n@@ -121,11 +121,18 @@ PointerAlignment: Right\n # x = (int32)y; not x = (int32) y;\n SpaceAfterCStyleCast: false\n \n+# No space is inserted after the logical not operator\n+SpaceAfterLogicalNot: false\n+\n # Insert spaces before and after assignment operators\n # int a = 5; not int a=5;\n # a += 42; a+=42;\n SpaceBeforeAssignmentOperators: true\n \n+# Spaces will be removed before case colon.\n+# case 1: break; not case 1 : break;\n+SpaceBeforeCaseColon: false\n+\n # Put a space before opening parentheses only after control statement keywords.\n # void f() {\n # if (true) {\n@@ -134,6 +141,13 @@ SpaceBeforeAssignmentOperators: true\n # }\n SpaceBeforeParens: ControlStatements\n \n+# No space before first '[' in arrays\n+# int a[5][5]; not int a [5][5];\n+SpaceBeforeSquareBrackets: false\n+\n+# No space will be inserted into {}\n+# while (true) {} not while (true) { }\n+SpaceInEmptyBlock: false\n \n # The number of spaces before trailing line comments (// - comments).\n # This does not affect trailing block comments (/* - comments).\n-- \n2.45.2\n\n"},{"id":"498716","messageId":"20240715093047.49321-7-karthik.188@gmail.com","threadId":"61750","inReplyTo":"20240715093047.49321-1-karthik.188@gmail.com","subject":"[PATCH v4 6/8] ci: run style check on GitHub and GitLab","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-15T09:30:45Z","receivedAt":"2024-07-15T09:30:57Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"We don't run style checks on our CI, even though we have a\n'.clang-format' setup in the repository. Let's add one, the job will\nvalidate only against the new commits added and will only run on merge\nrequests. Since we're introducing it for the first time, let's allow\nthis job to fail, so we can validate if this is useful and eventually\nenforce it.\n\nFor GitHub, we allow the job to pass by adding 'continue-on-error: true'\nto the workflow. This means the job would show as passed, even if the\nstyle check failed. To know the status of the job, users have to\nmanually check the logs.\n\nFor GitLab, we allow the job to pass by adding 'allow_failure: true', to\nthe job. Unlike GitHub, here the job will show as failed with a yellow\nwarning symbol, but the pipeline would still show as passed.\n\nAlso for GitLab, we use the 'CI_MERGE_REQUEST_TARGET_BRANCH_SHA'\nvariable by default to obtain the base SHA of the merged pipeline (which\nis only available for merged pipelines [1]). Otherwise we use the\n'CI_MERGE_REQUEST_DIFF_BASE_SHA' variable.\n\n[1]: https://docs.gitlab.com/ee/ci/variables/predefined_variables.html#predefined-variables-for-merge-request-pipelines\n\nHelped-by: Junio C Hamano \nSigned-off-by: Karthik Nayak \n---\n .github/workflows/check-style.yml | 34 +++++++++++++++++++++++++++++++\n .gitlab-ci.yml | 24 ++++++++++++++++++++++\n ci/install-dependencies.sh | 6 +++++-\n ci/run-style-check.sh | 8 ++++++++\n 4 files changed, 71 insertions(+), 1 deletion(-)\n create mode 100644 .github/workflows/check-style.yml\n create mode 100755 ci/run-style-check.sh\n\ndiff --git a/.github/workflows/check-style.yml b/.github/workflows/check-style.yml\nnew file mode 100644\nindex 0000000000..c052a5df23\n--- /dev/null\n+++ b/.github/workflows/check-style.yml\n@@ -0,0 +1,34 @@\n+name: check-style\n+\n+# Get the repository with all commits to ensure that we can analyze\n+# all of the commits contributed via the Pull Request.\n+\n+on:\n+ pull_request:\n+ types: [opened, synchronize]\n+\n+# Avoid unnecessary builds. Unlike the main CI jobs, these are not\n+# ci-configurable (but could be).\n+concurrency:\n+ group: ${{ github.workflow }}-${{ github.ref }}\n+ cancel-in-progress: true\n+\n+jobs:\n+ check-style:\n+ env:\n+ CC: clang\n+ jobname: ClangFormat\n+ runs-on: ubuntu-latest\n+ steps:\n+ - uses: actions/checkout@v4\n+ with:\n+ fetch-depth: 0\n+\n+ - run: ci/install-dependencies.sh\n+\n+ - name: git clang-format\n+ continue-on-error: true\n+ id: check_out\n+ run: |\n+ ./ci/run-style-check.sh \\\n+ \"${{github.event.pull_request.base.sha}}\"\ndiff --git a/.gitlab-ci.yml b/.gitlab-ci.yml\nindex 37b991e080..817266226e 100644\n--- a/.gitlab-ci.yml\n+++ b/.gitlab-ci.yml\n@@ -123,6 +123,30 @@ check-whitespace:\n rules:\n - if: $CI_PIPELINE_SOURCE == 'merge_request_event'\n \n+check-style:\n+ image: ubuntu:latest\n+ allow_failure: true\n+ variables:\n+ CC: clang\n+ jobname: ClangFormat\n+ before_script:\n+ - ./ci/install-dependencies.sh\n+ # Since $CI_MERGE_REQUEST_TARGET_BRANCH_SHA is only defined for merged\n+ # pipelines, we fallback to $CI_MERGE_REQUEST_DIFF_BASE_SHA, which should\n+ # be defined in all pipelines.\n+ script:\n+ - |\n+ R=${CI_MERGE_REQUEST_TARGET_BRANCH_SHA-${CI_MERGE_REQUEST_DIFF_BASE_SHA?}}\n+\n+ if test -z \"$R\"\n+ then\n+ echo \"CI_MERGE_REQUEST_DIFF_BASE_SHA should always exist!\"\n+ exit 1\n+ fi\n+ ./ci/run-style-check.sh \"$R\"\n+ rules:\n+ - if: $CI_PIPELINE_SOURCE == 'merge_request_event'\n+\n documentation:\n image: ubuntu:latest\n variables:\ndiff --git a/ci/install-dependencies.sh b/ci/install-dependencies.sh\nindex 6ec0f85972..8b01bfb89f 100755\n--- a/ci/install-dependencies.sh\n+++ b/ci/install-dependencies.sh\n@@ -43,7 +43,7 @@ ubuntu-*)\n \t\tmake libssl-dev libcurl4-openssl-dev libexpat-dev wget sudo default-jre \\\n \t\ttcl tk gettext zlib1g-dev perl-modules liberror-perl libauthen-sasl-perl \\\n \t\tlibemail-valid-perl libio-pty-perl libio-socket-ssl-perl libnet-smtp-ssl-perl libdbd-sqlite3-perl libcgi-pm-perl \\\n-\t\t${CC_PACKAGE:-${CC:-gcc}} $PYTHON_PACKAGE\n+\t\t${CC_PACKAGE:-${CC:-gcc}} $PYTHON_PACKAGE clang-format\n \n \tmkdir --parents \"$CUSTOM_PATH\"\n \twget --quiet --directory-prefix=\"$CUSTOM_PATH\" \\\n@@ -87,6 +87,10 @@ macos-*)\n esac\n \n case \"$jobname\" in\n+ClangFormat)\n+\tsudo apt-get -q update\n+\tsudo apt-get -q -y install clang-format\n+\t;;\n StaticAnalysis)\n \tsudo apt-get -q update\n \tsudo apt-get -q -y install coccinelle libcurl4-openssl-dev libssl-dev \\\ndiff --git a/ci/run-style-check.sh b/ci/run-style-check.sh\nnew file mode 100755\nindex 0000000000..76dd37d22b\n--- /dev/null\n+++ b/ci/run-style-check.sh\n@@ -0,0 +1,8 @@\n+#!/bin/sh\n+#\n+# Perform style check\n+#\n+\n+baseCommit=$1\n+\n+git clang-format --style file --diff --extensions c,h \"$baseCommit\"\n-- \n2.45.2\n\n"},{"id":"498717","messageId":"20240715093047.49321-8-karthik.188@gmail.com","threadId":"61750","inReplyTo":"20240715093047.49321-1-karthik.188@gmail.com","subject":"[PATCH v4 7/8] check-whitespace: detect if no base_commit is provided","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-15T09:30:46Z","receivedAt":"2024-07-15T09:30:58Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"The 'check-whitespace' CI script exits gracefully if no base commit is\nprovided or if an invalid revision is provided. This is not good because\nif a particular CI provides an incorrect base_commit, it would fail\nsuccessfully.\n\nThis is exactly the case with the GitLab CI. The CI is using the\n\"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\" variable to get the base commit\nSHA, but variable is only defined for _merged_ pipelines. So it is empty\nfor regular pipelines [1]. This should've failed the check-whitespace\njob.\n\nLet's fallback to 'CI_MERGE_REQUEST_DIFF_BASE_SHA' if\n\"CI_MERGE_REQUEST_TARGET_BRANCH_SHA\" isn't available in GitLab CI,\nsimilar to the previous commit. Let's also add a check for incorrect\nbase_commit in the 'check-whitespace.sh' script. While here, fix a small\ntypo too.\n\n[1]: https://docs.gitlab.com/ee/ci/variables/predefined_variables.html#predefined-variables-for-merge-request-pipelines\n\nHelped-by: Junio C Hamano \nSigned-off-by: Karthik Nayak \n---\n .gitlab-ci.yml | 13 ++++++++++++-\n ci/check-whitespace.sh | 10 ++++++++--\n 2 files changed, 20 insertions(+), 3 deletions(-)\n\ndiff --git a/.gitlab-ci.yml b/.gitlab-ci.yml\nindex 817266226e..320b78b9ae 100644\n--- a/.gitlab-ci.yml\n+++ b/.gitlab-ci.yml\n@@ -118,8 +118,19 @@ check-whitespace:\n image: ubuntu:latest\n before_script:\n - ./ci/install-dependencies.sh\n+ # Since $CI_MERGE_REQUEST_TARGET_BRANCH_SHA is only defined for merged\n+ # pipelines, we fallback to $CI_MERGE_REQUEST_DIFF_BASE_SHA, which should\n+ # be defined in all pipelines.\n script:\n- - ./ci/check-whitespace.sh \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\"\n+ - |\n+ R=${CI_MERGE_REQUEST_TARGET_BRANCH_SHA-${CI_MERGE_REQUEST_DIFF_BASE_SHA?}}\n+\n+ if test -z \"$R\"\n+ then\n+ echo \"CI_MERGE_REQUEST_DIFF_BASE_SHA should always exist!\"\n+ exit 1\n+ fi\n+ ./ci/check-whitespace.sh \"$R\"\n rules:\n - if: $CI_PIPELINE_SOURCE == 'merge_request_event'\n \ndiff --git a/ci/check-whitespace.sh b/ci/check-whitespace.sh\nindex db399097a5..c40804394c 100755\n--- a/ci/check-whitespace.sh\n+++ b/ci/check-whitespace.sh\n@@ -9,7 +9,7 @@ baseCommit=$1\n outputFile=$2\n url=$3\n \n-if test \"$#\" -ne 1 && test \"$#\" -ne 3\n+if test \"$#\" -ne 1 && test \"$#\" -ne 3 || test -z \"$1\"\n then\n \techo \"USAGE: $0 [ ]\"\n \texit 1\n@@ -21,6 +21,12 @@ commitText=\n commitTextmd=\n goodParent=\n \n+if ! git rev-parse --quiet --verify \"${baseCommit}\"\n+then\n+ echo \"Invalid '${baseCommit}'\"\n+ exit 1\n+fi\n+\n while read dash sha etc\n do\n \tcase \"${dash}\" in\n@@ -67,7 +73,7 @@ then\n \t\tgoodParent=${baseCommit: 0:7}\n \tfi\n \n-\techo \"A whitespace issue was found in onen of more of the commits.\"\n+\techo \"A whitespace issue was found in one or more of the commits.\"\n \techo \"Run the following command to resolve whitespace issues:\"\n \techo \"git rebase --whitespace=fix ${goodParent}\"\n \n-- \n2.45.2\n\n"},{"id":"498718","messageId":"20240715093047.49321-9-karthik.188@gmail.com","threadId":"61750","inReplyTo":"20240715093047.49321-1-karthik.188@gmail.com","subject":"[PATCH v4 8/8] ci/style-check: add `RemoveBracesLLVM` to '.clang-format'","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-15T09:30:47Z","receivedAt":"2024-07-15T09:30:59Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"For 'clang-format' setting 'RemoveBracesLLVM' to 'true', adds a check\nto ensure we avoid curly braces for single-statement bodies in\nconditional blocks.\n\nHowever, the option does come with two warnings [1]:\n\n This option will be renamed and expanded to support other styles.\n\nand\n\n Setting this option to true could lead to incorrect code formatting\n due to clang-format’s lack of complete semantic information. As\n such, extra care should be taken to review code changes made by\n this option.\n\nThe latter seems to be of concern. While we want to experiment with the\nrule, adding it to the in-tree '.clang-format' could affect end-users.\nLet's only add it to the CI jobs for now. With time, we can evaluate\nits efficacy and decide if we want to add it to '.clang-format' or\nretract it entirely.\n\nA more ideal solution would be if 'clang-format' allowed us to append\nrules to the existing '.clang-format' when invoked. But such an option\ndoes not exist. Since modifying the in-tree '.clang-format' is only done\non the CI job for style-check and doesn't affect any other jobs and is\nnot persisted in any ways, this hack should be okay.\n\n[1]: https://clang.llvm.org/docs/ClangFormatStyleOptions.html#removebracesllvm\n\nSigned-off-by: Karthik Nayak \n---\n ci/run-style-check.sh | 13 +++++++++++++\n 1 file changed, 13 insertions(+)\n\ndiff --git a/ci/run-style-check.sh b/ci/run-style-check.sh\nindex 76dd37d22b..16b593fa1b 100755\n--- a/ci/run-style-check.sh\n+++ b/ci/run-style-check.sh\n@@ -5,4 +5,17 @@\n \n baseCommit=$1\n \n+# Remove optional braces of control statements (if, else, for, and while)\n+# according to the LLVM coding style. This avoids braces on simple\n+# single-statement bodies of statements but keeps braces if one side of\n+# if/else if/.../else cascade has multi-statement body.\n+#\n+# As this rule comes with a warning [1], we want to experiment with it\n+# before adding it in-tree. since the CI job for the style check is allowed\n+# to fail, appending the rule here allows us to validate its efficacy.\n+# While also ensuring that end-users are not affected directly.\n+#\n+# [1]: https://clang.llvm.org/docs/ClangFormatStyleOptions.html#removebracesllvm\n+echo \"RemoveBracesLLVM: true\" >>.clang-format\n+\n git clang-format --style file --diff --extensions c,h \"$baseCommit\"\n-- \n2.45.2\n\n"},{"id":"498727","messageId":"xmqq7cdm90h7.fsf@gitster.g","threadId":"61750","inReplyTo":"CAOLa=ZQfhD21Anzd3wWwWcxji7tJydaiD7mrhReH5zLQdXBWng@mail.gmail.com","subject":"Re: [PATCH v3 8/8] ci/style-check: add `RemoveBracesLLVM` to '.clang-format'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-07-15T14:46:44Z","receivedAt":"2024-07-15T14:46:53Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Karthik Nayak writes:\n\n> Providing a path does work indeed. But we were discussing the option to\n> provide an additional path apart from the default '.clang-format'.\n\nBut that is not a requirement. The requirement is to allow us to\nuse what we have in .clang-format plus one other rule.\n\nAnd if that requirement is met by copying the entire contents in\n.clang-format to a temporary file, adding the other one to the same\ntemporary file, and then using the temporary file instead of\n.clang-format, that is fine, isn't it?\n\n"},{"id":"498734","messageId":"CAOLa=ZTjHKX3EMbVu1_bjdDez=3aODZQYY4npKrCY-7ZRXN1hQ@mail.gmail.com","threadId":"61750","inReplyTo":"xmqq7cdm90h7.fsf@gitster.g","subject":"Re: [PATCH v3 8/8] ci/style-check: add `RemoveBracesLLVM` to '.clang-format'","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-15T16:07:43Z","receivedAt":"2024-07-15T16:07:47Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"Junio C Hamano writes:\n\n> Karthik Nayak writes:\n>\n>> Providing a path does work indeed. But we were discussing the option to\n>> provide an additional path apart from the default '.clang-format'.\n>\n> But that is not a requirement. The requirement is to allow us to\n> use what we have in .clang-format plus one other rule.\n>\n> And if that requirement is met by copying the entire contents in\n> .clang-format to a temporary file, adding the other one to the same\n> temporary file, and then using the temporary file instead of\n> .clang-format, that is fine, isn't it?\n\nAh right. Let me summarise:\n- Method 1: Inject the extra config to '.clang-format' in the CI's job.\nThis is the current method.\n- Method 2: Create '.clang-format-ci' to use in the CI\n - Method 2.a: The new file contains '.clang-format' + CI specific\n rules.\n - Method 2.b: The new file simply contains the new rules and we inject\n the rest in the CI's job.\n\nI'd say methods '1' and '2.b' are similar, since they modify the tree on\nthe CI. So no real benefit of one over the other, no?\n\nThe issue with method '2.a' is that we have two sources of truth and we\nneed to ensure both files are updates always.\n\nSince the former methods don't have any cons of maintenance apart from\nseeming a bit hacky, I'd prefer that. But happy to go the other way too!\n"},{"id":"498737","messageId":"xmqqle224npf.fsf@gitster.g","threadId":"61750","inReplyTo":"CAOLa=ZTjHKX3EMbVu1_bjdDez=3aODZQYY4npKrCY-7ZRXN1hQ@mail.gmail.com","subject":"Re: [PATCH v3 8/8] ci/style-check: add `RemoveBracesLLVM` to '.clang-format'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-07-15T16:36:12Z","receivedAt":"2024-07-15T16:36:15Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Karthik Nayak writes:\n\n> Ah right. Let me summarise:\n> - Method 1: Inject the extra config to '.clang-format' in the CI's job.\n> This is the current method.\n> - Method 2: Create '.clang-format-ci' to use in the CI\n> - Method 2.a: The new file contains '.clang-format' + CI specific\n> rules.\n> - Method 2.b: The new file simply contains the new rules and we inject\n> the rest in the CI's job.\n>\n> I'd say methods '1' and '2.b' are similar, since they modify the tree on\n> the CI. So no real benefit of one over the other, no?\n\nSorry, but I am not sure what you are trying to say, especially with\n2.a and 2.b, your assumption on \"the new file\". Is it tracked?\n\nTry running \"git describe --dirty\" and see if the command can tell\nthe difference. If you smudge .clang-format, which is a tracked\nfile, it will be noticed.\n\nBut you can use a temporary file and use --style=file:/... to point\nat it. The temporary file can be an untracked and ignored file,\njust like any *.o files we would create during a build. Then \"git\ndescribe --dirty\" would not complain that you are making the working\ntree dirty.\n\nThe temporary file does not even have to be inside our working tree.\nIf we know we can write into /tmp/clang-format-rules file, then the\nCI script can do something like\n\n\t{\n\t\tcat .clang-format\n\t\techo echo \"RemoveBracesLLVM: true\"\n\t} >/tmp/clang-format-rules\n\tgit clang-format --style=file:/tmp/clang-format-rules \\\n\t\t --diff --extensions c,h \"$baseCommit\"\n\nright? Then \"git status\" would even say \"there is no untracked\ncruft\" (although I do not know we *need* to keep the working tree\nthat clean, without untracked cruft).\n"},{"id":"498741","messageId":"xmqq8qy24mil.fsf@gitster.g","threadId":"61750","inReplyTo":"20240715093047.49321-9-karthik.188@gmail.com","subject":"Re: [PATCH v4 8/8] ci/style-check: add `RemoveBracesLLVM` to '.clang-format'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-07-15T17:01:54Z","receivedAt":"2024-07-15T17:03:52Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Karthik Nayak writes:\n\n> A more ideal solution would be if 'clang-format' allowed us to append\n> rules to the existing '.clang-format' when invoked. But such an option\n> does not exist. Since modifying the in-tree '.clang-format' is only done\n> on the CI job for style-check and doesn't affect any other jobs and is\n> not persisted in any ways, this hack should be okay.\n\nI think our mails crossed, but I do not know why this hack is OK.\nAre there other CI jobs that muck with tracked files in the working\ntree?\n\nThanks.\n"},{"id":"498750","messageId":"CAOLa=ZQx4UKMfq7q2GMV6nYQGKeCj0dW_P4kG7yDTcdo--1HHQ@mail.gmail.com","threadId":"61750","inReplyTo":"xmqqle224npf.fsf@gitster.g","subject":"Re: [PATCH v3 8/8] ci/style-check: add `RemoveBracesLLVM` to '.clang-format'","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-15T19:31:19Z","receivedAt":"2024-07-15T19:31:21Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"Junio C Hamano writes:\n\n> Karthik Nayak writes:\n>\n>> Ah right. Let me summarise:\n>> - Method 1: Inject the extra config to '.clang-format' in the CI's job.\n>> This is the current method.\n>> - Method 2: Create '.clang-format-ci' to use in the CI\n>> - Method 2.a: The new file contains '.clang-format' + CI specific\n>> rules.\n>> - Method 2.b: The new file simply contains the new rules and we inject\n>> the rest in the CI's job.\n>>\n>> I'd say methods '1' and '2.b' are similar, since they modify the tree on\n>> the CI. So no real benefit of one over the other, no?\n>\n> Sorry, but I am not sure what you are trying to say, especially with\n> 2.a and 2.b, your assumption on \"the new file\". Is it tracked?\n>\n\nYes. I was referring to a tracked file.\n\n> Try running \"git describe --dirty\" and see if the command can tell\n> the difference. If you smudge .clang-format, which is a tracked\n> file, it will be noticed.\n>\n> But you can use a temporary file and use --style=file:/... to point\n> at it. The temporary file can be an untracked and ignored file,\n> just like any *.o files we would create during a build. Then \"git\n> describe --dirty\" would not complain that you are making the working\n> tree dirty.\n>\n> The temporary file does not even have to be inside our working tree.\n\nI feel stupid now. I completely didn't think of this and this solves\neverything. Thanks for being explicit here. The temporary file\nabsolutely doesn't have to be in our working tree.\n\n> If we know we can write into /tmp/clang-format-rules file, then the\n> CI script can do something like\n>\n> \t{\n> \t\tcat .clang-format\n> \t\techo echo \"RemoveBracesLLVM: true\"\n> \t} >/tmp/clang-format-rules\n> \tgit clang-format --style=file:/tmp/clang-format-rules \\\n> \t\t --diff --extensions c,h \"$baseCommit\"\n>\n> right? Then \"git status\" would even say \"there is no untracked\n> cruft\" (although I do not know we *need* to keep the working tree\n> that clean, without untracked cruft).\n\nYes this is the best solution.\n"},{"id":"498751","messageId":"CAOLa=ZToNFn5FvC0DDcx4V0tEgruSt1igDEunqZjkUiJCexQbA@mail.gmail.com","threadId":"61750","inReplyTo":"xmqq8qy24mil.fsf@gitster.g","subject":"Re: [PATCH v4 8/8] ci/style-check: add `RemoveBracesLLVM` to '.clang-format'","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-15T19:33:36Z","receivedAt":"2024-07-15T19:33:37Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"Junio C Hamano writes:\n\n> Karthik Nayak writes:\n>\n>> A more ideal solution would be if 'clang-format' allowed us to append\n>> rules to the existing '.clang-format' when invoked. But such an option\n>> does not exist. Since modifying the in-tree '.clang-format' is only done\n>> on the CI job for style-check and doesn't affect any other jobs and is\n>> not persisted in any ways, this hack should be okay.\n>\n> I think our mails crossed, but I do not know why this hack is OK.\n> Are there other CI jobs that muck with tracked files in the working\n> tree?\n>\n> Thanks.\n\nI mean from an operation of a CI job, the repository is discarded after\nthe job. So there isn't a problem with murking with the working tree.\n\nBut I agree to your latest response [1], it would be best to do this\nwith a temporary file outside the working tree.\n\nWill send a new version soon! Thanks\n\n[1]: https://lore.kernel.org/r/xmqqle224npf.fsf@gitster.g\n"},{"id":"498752","messageId":"xmqqcyne30eb.fsf@gitster.g","threadId":"61750","inReplyTo":"CAOLa=ZQx4UKMfq7q2GMV6nYQGKeCj0dW_P4kG7yDTcdo--1HHQ@mail.gmail.com","subject":"Re: [PATCH v3 8/8] ci/style-check: add `RemoveBracesLLVM` to '.clang-format'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-07-15T19:45:00Z","receivedAt":"2024-07-15T19:45:06Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Karthik Nayak writes:\n\n>> If we know we can write into /tmp/clang-format-rules file, then the\n>> CI script can do something like\n>>\n>> \t{\n>> \t\tcat .clang-format\n>> \t\techo echo \"RemoveBracesLLVM: true\"\n>> \t} >/tmp/clang-format-rules\n>> \tgit clang-format --style=file:/tmp/clang-format-rules \\\n>> \t\t --diff --extensions c,h \"$baseCommit\"\n>>\n>> right? Then \"git status\" would even say \"there is no untracked\n>> cruft\" (although I do not know we *need* to keep the working tree\n>> that clean, without untracked cruft).\n>\n> Yes this is the best solution.\n\nFWIW, I think an in-tree throw-away file is a better option, simply\nbecause we _know_ that the working tree can be written (by the fact\nthat we can do \"make\" and have compilers write *.o and other cruft),\nbut we do not know if the CI environment allows us to write to /tmp\nor /var/tmp or /usr/local/tmp and you do not want to run around and\nsee if there is a suitable temporary directory you can use.\n\n\n\n\t\n"},{"id":"498903","messageId":"20240718081605.452366-1-karthik.188@gmail.com","threadId":"61750","inReplyTo":"20240715093047.49321-1-karthik.188@gmail.com","subject":"[PATCH v5 0/6] : add more rules and enable on CI","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-18T08:15:59Z","receivedAt":"2024-07-18T08:16:09Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"This is v5 of my series to add clang-format to the CI.\n\nThe series was mostly inspired by a patch sent recently to 'include\nkh_foreach* macros in ForEachMacros' [1]. I was wondering why we don't\nrun the formatting on CI and reduce some of the workload of reviewers.\n\nWe have a '.clang-format' file to provide rules for code formatting.\nThe commits 1-3 aims to add more rules to the file.\n\nCommit 4 enables CI action on GitHub and GitLab to also check for the\ncode formatting. Currently, it is allowed to fail. This way we can build\nconfidence and fine tune the values as needed and finally enforce the\ncheck in a future patch. I'm not well versed with GitHub workflows, and\nI mostly tried to copy existing work there. Expecting some feedback in\nthat section!\n\nCommit 5 fixes an existing issue with the 'check-whitespace' job, which\nis failing as success in the GitLab CI.\n\nCommit 6 adds the `RemoveBracesLLVM` only in the context of the CI. If we\ndecide against it, we could drop this commit from the series.\n\n1: https://lore.kernel.org/git/4e7893f5-2dd9-46cf-8a64-cf780f4e1730@web.de/\n\nChanges against v4:\n- While testing out temp file as source for the CI, I noticed that version\nof clang-format on GitHub is much older than that of GitLab, in accordance\nwith that, I removed some of the rules which are newer and not supported.\n- Cleaned up extra dependency addition in 'install-dependencies'. \n- Instead of murking the in-tree '.clang-format', now we create a temporary\nfile and use that. \n\nTest jobs:\n- With error:\n - GitLab: https://gitlab.com/gitlab-org/git/-/jobs/7357893486\n - GitHub: https://github.com/git/git/actions/runs/9964605815/job/27533243002\n- Without error: \n - GitLab: https://gitlab.com/gitlab-org/git/-/jobs/7357903589\n - GitHub: https://github.com/git/git/actions/runs/9964631696/job/27533328240\n\nKarthik Nayak (6):\n clang-format: indent preprocessor directives after hash\n clang-format: avoid spacing around bitfield colon\n clang-format: formalize some of the spacing rules\n ci: run style check on GitHub and GitLab\n check-whitespace: detect if no base_commit is provided\n ci/style-check: add `RemoveBracesLLVM` in CI job\n\n .clang-format | 25 +++++++++++++++++++++\n .github/workflows/check-style.yml | 34 ++++++++++++++++++++++++++++\n .gitlab-ci.yml | 37 ++++++++++++++++++++++++++++++-\n ci/check-whitespace.sh | 10 +++++++--\n ci/install-dependencies.sh | 4 ++++\n ci/run-style-check.sh | 25 +++++++++++++++++++++\n 6 files changed, 132 insertions(+), 3 deletions(-)\n create mode 100644 .github/workflows/check-style.yml\n create mode 100755 ci/run-style-check.sh\n\nRange-diff against v4:\n1: 6cf91ffc86 = 1: 6cf91ffc86 clang-format: indent preprocessor directives after hash\n2: beb002885f = 2: beb002885f clang-format: avoid spacing around bitfield colon\n3: 3031be43e7 < -: ---------- clang-format: ensure files end with newlines\n4: bc1550e300 < -: ---------- clang-format: replace deprecated option with 'SpacesInParens'\n5: 4586c0094b ! 3: 3922529001 clang-format: formalize some of the spacing rules\n @@ .clang-format: PointerAlignment: Right\n # Put a space before opening parentheses only after control statement keywords.\n # void f() {\n # if (true) {\n -@@ .clang-format: SpaceBeforeAssignmentOperators: true\n - # }\n - SpaceBeforeParens: ControlStatements\n +@@ .clang-format: SpaceBeforeParens: ControlStatements\n + # Don't insert spaces inside empty '()'\n + SpaceInEmptyParentheses: false\n \n +# No space before first '[' in arrays\n +# int a[5][5]; not int a [5][5];\n @@ .clang-format: SpaceBeforeAssignmentOperators: true\n +# No space will be inserted into {}\n +# while (true) {} not while (true) { }\n +SpaceInEmptyBlock: false\n - \n ++\n # The number of spaces before trailing line comments (// - comments).\n # This does not affect trailing block comments (/* - comments).\n + SpacesBeforeTrailingComments: 1\n6: c18cb23369 ! 4: ae23eb5af8 ci: run style check on GitHub and GitLab\n @@ Commit message\n this job to fail, so we can validate if this is useful and eventually\n enforce it.\n \n - For GitLab, we use the 'CI_MERGE_REQUEST_TARGET_BRANCH_SHA' variable by\n - default to obtain the base SHA of the merged pipeline (which is only\n - available for merged pipelines [1]). Otherwise we use the\n + For GitHub, we allow the job to pass by adding 'continue-on-error: true'\n + to the workflow. This means the job would show as passed, even if the\n + style check failed. To know the status of the job, users have to\n + manually check the logs.\n +\n + For GitLab, we allow the job to pass by adding 'allow_failure: true', to\n + the job. Unlike GitHub, here the job will show as failed with a yellow\n + warning symbol, but the pipeline would still show as passed.\n +\n + Also for GitLab, we use the 'CI_MERGE_REQUEST_TARGET_BRANCH_SHA'\n + variable by default to obtain the base SHA of the merged pipeline (which\n + is only available for merged pipelines [1]). Otherwise we use the\n 'CI_MERGE_REQUEST_DIFF_BASE_SHA' variable.\n \n [1]: https://docs.gitlab.com/ee/ci/variables/predefined_variables.html#predefined-variables-for-merge-request-pipelines\n \n + Helped-by: Junio C Hamano \n Signed-off-by: Karthik Nayak \n \n ## .github/workflows/check-style.yml (new) ##\n @@ .github/workflows/check-style.yml (new)\n +\n +jobs:\n + check-style:\n ++ env:\n ++ CC: clang\n ++ jobname: ClangFormat\n + runs-on: ubuntu-latest\n + steps:\n + - uses: actions/checkout@v4\n + with:\n + fetch-depth: 0\n +\n ++ - run: ci/install-dependencies.sh\n ++\n + - name: git clang-format\n + continue-on-error: true\n + id: check_out\n @@ .gitlab-ci.yml: check-whitespace:\n + allow_failure: true\n + variables:\n + CC: clang\n ++ jobname: ClangFormat\n + before_script:\n + - ./ci/install-dependencies.sh\n + # Since $CI_MERGE_REQUEST_TARGET_BRANCH_SHA is only defined for merged\n @@ .gitlab-ci.yml: check-whitespace:\n + # be defined in all pipelines.\n + script:\n + - |\n -+ if test -n \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\"\n -+ then\n -+ ./ci/run-style-check.sh \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\"\n -+ elif test -n \"$CI_MERGE_REQUEST_DIFF_BASE_SHA\"\n ++ R=${CI_MERGE_REQUEST_TARGET_BRANCH_SHA-${CI_MERGE_REQUEST_DIFF_BASE_SHA?}}\n ++\n ++ if test -z \"$R\"\n + then\n -+ ./ci/run-style-check.sh \"$CI_MERGE_REQUEST_DIFF_BASE_SHA\"\n -+ else\n -+ echo \"CI_MERGE_REQUEST_DIFF_BASE_SHA should always exist!\"; exit 1\n ++ echo \"CI_MERGE_REQUEST_DIFF_BASE_SHA should always exist!\"\n ++ exit 1\n + fi\n ++ ./ci/run-style-check.sh \"$R\"\n + rules:\n + - if: $CI_PIPELINE_SOURCE == 'merge_request_event'\n +\n @@ .gitlab-ci.yml: check-whitespace:\n variables:\n \n ## ci/install-dependencies.sh ##\n -@@ ci/install-dependencies.sh: ubuntu-*)\n - \t\tmake libssl-dev libcurl4-openssl-dev libexpat-dev wget sudo default-jre \\\n - \t\ttcl tk gettext zlib1g-dev perl-modules liberror-perl libauthen-sasl-perl \\\n - \t\tlibemail-valid-perl libio-pty-perl libio-socket-ssl-perl libnet-smtp-ssl-perl libdbd-sqlite3-perl libcgi-pm-perl \\\n --\t\t${CC_PACKAGE:-${CC:-gcc}} $PYTHON_PACKAGE\n -+\t\t${CC_PACKAGE:-${CC:-gcc}} $PYTHON_PACKAGE clang-format\n +@@ ci/install-dependencies.sh: macos-*)\n + esac\n \n - \tmkdir --parents \"$CUSTOM_PATH\"\n - \twget --quiet --directory-prefix=\"$CUSTOM_PATH\" \\\n + case \"$jobname\" in\n ++ClangFormat)\n ++\tsudo apt-get -q update\n ++\tsudo apt-get -q -y install clang-format\n ++\t;;\n + StaticAnalysis)\n + \tsudo apt-get -q update\n + \tsudo apt-get -q -y install coccinelle libcurl4-openssl-dev libssl-dev \\\n \n ## ci/run-style-check.sh (new) ##\n @@\n7: 4d08c570bb ! 5: a38cde03a8 check-whitespace: detect if no base_commit is provided\n @@ Commit message\n \n [1]: https://docs.gitlab.com/ee/ci/variables/predefined_variables.html#predefined-variables-for-merge-request-pipelines\n \n + Helped-by: Junio C Hamano \n Signed-off-by: Karthik Nayak \n \n ## .gitlab-ci.yml ##\n @@ .gitlab-ci.yml: check-whitespace:\n script:\n - - ./ci/check-whitespace.sh \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\"\n + - |\n -+ if test -n \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\"\n -+ then\n -+ ./ci/check-whitespace.sh \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\"\n -+ elif test -n \"$CI_MERGE_REQUEST_DIFF_BASE_SHA\"\n ++ R=${CI_MERGE_REQUEST_TARGET_BRANCH_SHA-${CI_MERGE_REQUEST_DIFF_BASE_SHA?}}\n ++\n ++ if test -z \"$R\"\n + then\n -+ ./ci/check-whitespace.sh \"$CI_MERGE_REQUEST_DIFF_BASE_SHA\"\n -+ else\n -+ echo \"CI_MERGE_REQUEST_DIFF_BASE_SHA should always exist!\"; exit 1\n ++ echo \"CI_MERGE_REQUEST_DIFF_BASE_SHA should always exist!\"\n ++ exit 1\n + fi\n ++ ./ci/check-whitespace.sh \"$R\"\n rules:\n - if: $CI_PIPELINE_SOURCE == 'merge_request_event'\n \n8: 2b39431f93 ! 6: 008e77bd0a ci/style-check: add `RemoveBracesLLVM` to '.clang-format'\n @@ Metadata\n Author: Karthik Nayak \n \n ## Commit message ##\n - ci/style-check: add `RemoveBracesLLVM` to '.clang-format'\n + ci/style-check: add `RemoveBracesLLVM` in CI job\n \n - For 'clang-format' setting 'RemoveBracesLLVM' to 'true', adds a check\n + For 'clang-format', setting 'RemoveBracesLLVM' to 'true', adds a check\n to ensure we avoid curly braces for single-statement bodies in\n conditional blocks.\n \n @@ Commit message\n rule, adding it to the in-tree '.clang-format' could affect end-users.\n Let's only add it to the CI jobs for now. With time, we can evaluate\n its efficacy and decide if we want to add it to '.clang-format' or\n - retract it entirely.\n + retract it entirely. We do so, by adding the existing rules in\n + '.clang-format' and this rule to a temp file outside the working tree,\n + which is then used by 'git clang-format'. This ensures we don't murk\n + with files in-tree.\n \n [1]: https://clang.llvm.org/docs/ClangFormatStyleOptions.html#removebracesllvm\n \n @@ ci/run-style-check.sh\n \n baseCommit=$1\n \n +-git clang-format --style file --diff --extensions c,h \"$baseCommit\"\n +# Remove optional braces of control statements (if, else, for, and while)\n +# according to the LLVM coding style. This avoids braces on simple\n +# single-statement bodies of statements but keeps braces if one side of\n @@ ci/run-style-check.sh\n +# While also ensuring that end-users are not affected directly.\n +#\n +# [1]: https://clang.llvm.org/docs/ClangFormatStyleOptions.html#removebracesllvm\n -+echo \"RemoveBracesLLVM: true\" >> .clang-format\n ++{\n ++\tcat .clang-format\n ++\techo \"RemoveBracesLLVM: true\"\n ++} >/tmp/clang-format-rules\n +\n - git clang-format --style file --diff --extensions c,h \"$baseCommit\"\n ++git clang-format --style=file:/tmp/clang-format-rules \\\n ++\t--diff --extensions c,h \"$baseCommit\"\n-- \n2.45.2\n\n"},{"id":"498902","messageId":"20240718081605.452366-2-karthik.188@gmail.com","threadId":"61750","inReplyTo":"20240718081605.452366-1-karthik.188@gmail.com","subject":"[PATCH v5 1/6] clang-format: indent preprocessor directives after hash","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-18T08:16:00Z","receivedAt":"2024-07-18T08:16:10Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"We do not have a rule around the indentation of preprocessor directives.\nThis was also discussed on the list [1], noting how there is often\ninconsistency in the styling. While there was discussion, there was no\nconclusion around what is the preferred style here. One style being\nindenting after the hash:\n\n #if FOO\n # if BAR\n # include \n # endif\n #endif\n\nThe other being before the hash:\n\n #if FOO\n #if BAR\n #include \n #endif\n #endif\n\nLet's pick the former and add 'IndentPPDirectives: AfterHash' value to\nour '.clang-format'. There is no clear reason to pick one over the\nother, but it would definitely be nicer to be consistent.\n\n[1]: https://lore.kernel.org/r/xmqqwmmm1bw6.fsf@gitster.g\n\nSigned-off-by: Karthik Nayak \n---\n .clang-format | 6 ++++++\n 1 file changed, 6 insertions(+)\n\ndiff --git a/.clang-format b/.clang-format\nindex 3ed4fac753..5e128519bf 100644\n--- a/.clang-format\n+++ b/.clang-format\n@@ -96,6 +96,12 @@ BreakStringLiterals: false\n # Switch statement body is always indented one level more than case labels.\n IndentCaseLabels: false\n \n+# Indents directives before the hash.\n+# #if FOO\n+# # include \n+# #endif\n+IndentPPDirectives: AfterHash\n+\n # Don't indent a function definition or declaration if it is wrapped after the\n # type\n IndentWrappedFunctionNames: false\n-- \n2.45.2\n\n"},{"id":"498904","messageId":"20240718081605.452366-3-karthik.188@gmail.com","threadId":"61750","inReplyTo":"20240718081605.452366-1-karthik.188@gmail.com","subject":"[PATCH v5 2/6] clang-format: avoid spacing around bitfield colon","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-18T08:16:01Z","receivedAt":"2024-07-18T08:16:11Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"The spacing around colons is currently not standardized and as such we\nhave the following practices in our code base:\n- Spacing around the colon `int bf : 1`: 146 instances\n- No spacing around the colon `int bf:1`: 148 instances\n- Spacing before the colon `int bf :1`: 6 instances\n- Spacing after the colon `int bf: 1`: 12 instances\n\nLet's formalize this by picking the most followed pattern and add the\ncorresponding style to '.clang-format'.\n\nSigned-off-by: Karthik Nayak \n---\n .clang-format | 4 ++++\n 1 file changed, 4 insertions(+)\n\ndiff --git a/.clang-format b/.clang-format\nindex 5e128519bf..803b274dd5 100644\n--- a/.clang-format\n+++ b/.clang-format\n@@ -72,6 +72,10 @@ AlwaysBreakAfterReturnType: None\n BinPackArguments: true\n BinPackParameters: true\n \n+# Add no space around the bit field\n+# unsigned bf:2;\n+BitFieldColonSpacing: None\n+\n # Attach braces to surrounding context except break before braces on function\n # definitions.\n # void foo()\n-- \n2.45.2\n\n"},{"id":"498905","messageId":"20240718081605.452366-4-karthik.188@gmail.com","threadId":"61750","inReplyTo":"20240718081605.452366-1-karthik.188@gmail.com","subject":"[PATCH v5 3/6] clang-format: formalize some of the spacing rules","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-18T08:16:02Z","receivedAt":"2024-07-18T08:16:12Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"There are some spacing rules that we follow in the project and it makes\nsense to formalize them:\n* Ensure there is no space inserted after the logical not '!' operator.\n* Ensure there is no space before the case statement's colon.\n* Ensure there is no space before the first bracket '[' of an array.\n* Ensure there is no space in empty blocks.\n\nSigned-off-by: Karthik Nayak \n---\n .clang-format | 15 +++++++++++++++\n 1 file changed, 15 insertions(+)\n\ndiff --git a/.clang-format b/.clang-format\nindex 803b274dd5..3c8018a1dd 100644\n--- a/.clang-format\n+++ b/.clang-format\n@@ -118,11 +118,18 @@ PointerAlignment: Right\n # x = (int32)y; not x = (int32) y;\n SpaceAfterCStyleCast: false\n \n+# No space is inserted after the logical not operator\n+SpaceAfterLogicalNot: false\n+\n # Insert spaces before and after assignment operators\n # int a = 5; not int a=5;\n # a += 42; a+=42;\n SpaceBeforeAssignmentOperators: true\n \n+# Spaces will be removed before case colon.\n+# case 1: break; not case 1 : break;\n+SpaceBeforeCaseColon: false\n+\n # Put a space before opening parentheses only after control statement keywords.\n # void f() {\n # if (true) {\n@@ -134,6 +141,14 @@ SpaceBeforeParens: ControlStatements\n # Don't insert spaces inside empty '()'\n SpaceInEmptyParentheses: false\n \n+# No space before first '[' in arrays\n+# int a[5][5]; not int a [5][5];\n+SpaceBeforeSquareBrackets: false\n+\n+# No space will be inserted into {}\n+# while (true) {} not while (true) { }\n+SpaceInEmptyBlock: false\n+\n # The number of spaces before trailing line comments (// - comments).\n # This does not affect trailing block comments (/* - comments).\n SpacesBeforeTrailingComments: 1\n-- \n2.45.2\n\n"},{"id":"498906","messageId":"20240718081605.452366-5-karthik.188@gmail.com","threadId":"61750","inReplyTo":"20240718081605.452366-1-karthik.188@gmail.com","subject":"[PATCH v5 4/6] ci: run style check on GitHub and GitLab","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-18T08:16:03Z","receivedAt":"2024-07-18T08:16:13Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"We don't run style checks on our CI, even though we have a\n'.clang-format' setup in the repository. Let's add one, the job will\nvalidate only against the new commits added and will only run on merge\nrequests. Since we're introducing it for the first time, let's allow\nthis job to fail, so we can validate if this is useful and eventually\nenforce it.\n\nFor GitHub, we allow the job to pass by adding 'continue-on-error: true'\nto the workflow. This means the job would show as passed, even if the\nstyle check failed. To know the status of the job, users have to\nmanually check the logs.\n\nFor GitLab, we allow the job to pass by adding 'allow_failure: true', to\nthe job. Unlike GitHub, here the job will show as failed with a yellow\nwarning symbol, but the pipeline would still show as passed.\n\nAlso for GitLab, we use the 'CI_MERGE_REQUEST_TARGET_BRANCH_SHA'\nvariable by default to obtain the base SHA of the merged pipeline (which\nis only available for merged pipelines [1]). Otherwise we use the\n'CI_MERGE_REQUEST_DIFF_BASE_SHA' variable.\n\n[1]: https://docs.gitlab.com/ee/ci/variables/predefined_variables.html#predefined-variables-for-merge-request-pipelines\n\nHelped-by: Junio C Hamano \nSigned-off-by: Karthik Nayak \n---\n .github/workflows/check-style.yml | 34 +++++++++++++++++++++++++++++++\n .gitlab-ci.yml | 24 ++++++++++++++++++++++\n ci/install-dependencies.sh | 4 ++++\n ci/run-style-check.sh | 8 ++++++++\n 4 files changed, 70 insertions(+)\n create mode 100644 .github/workflows/check-style.yml\n create mode 100755 ci/run-style-check.sh\n\ndiff --git a/.github/workflows/check-style.yml b/.github/workflows/check-style.yml\nnew file mode 100644\nindex 0000000000..c052a5df23\n--- /dev/null\n+++ b/.github/workflows/check-style.yml\n@@ -0,0 +1,34 @@\n+name: check-style\n+\n+# Get the repository with all commits to ensure that we can analyze\n+# all of the commits contributed via the Pull Request.\n+\n+on:\n+ pull_request:\n+ types: [opened, synchronize]\n+\n+# Avoid unnecessary builds. Unlike the main CI jobs, these are not\n+# ci-configurable (but could be).\n+concurrency:\n+ group: ${{ github.workflow }}-${{ github.ref }}\n+ cancel-in-progress: true\n+\n+jobs:\n+ check-style:\n+ env:\n+ CC: clang\n+ jobname: ClangFormat\n+ runs-on: ubuntu-latest\n+ steps:\n+ - uses: actions/checkout@v4\n+ with:\n+ fetch-depth: 0\n+\n+ - run: ci/install-dependencies.sh\n+\n+ - name: git clang-format\n+ continue-on-error: true\n+ id: check_out\n+ run: |\n+ ./ci/run-style-check.sh \\\n+ \"${{github.event.pull_request.base.sha}}\"\ndiff --git a/.gitlab-ci.yml b/.gitlab-ci.yml\nindex 37b991e080..817266226e 100644\n--- a/.gitlab-ci.yml\n+++ b/.gitlab-ci.yml\n@@ -123,6 +123,30 @@ check-whitespace:\n rules:\n - if: $CI_PIPELINE_SOURCE == 'merge_request_event'\n \n+check-style:\n+ image: ubuntu:latest\n+ allow_failure: true\n+ variables:\n+ CC: clang\n+ jobname: ClangFormat\n+ before_script:\n+ - ./ci/install-dependencies.sh\n+ # Since $CI_MERGE_REQUEST_TARGET_BRANCH_SHA is only defined for merged\n+ # pipelines, we fallback to $CI_MERGE_REQUEST_DIFF_BASE_SHA, which should\n+ # be defined in all pipelines.\n+ script:\n+ - |\n+ R=${CI_MERGE_REQUEST_TARGET_BRANCH_SHA-${CI_MERGE_REQUEST_DIFF_BASE_SHA?}}\n+\n+ if test -z \"$R\"\n+ then\n+ echo \"CI_MERGE_REQUEST_DIFF_BASE_SHA should always exist!\"\n+ exit 1\n+ fi\n+ ./ci/run-style-check.sh \"$R\"\n+ rules:\n+ - if: $CI_PIPELINE_SOURCE == 'merge_request_event'\n+\n documentation:\n image: ubuntu:latest\n variables:\ndiff --git a/ci/install-dependencies.sh b/ci/install-dependencies.sh\nindex 6ec0f85972..fb34ced8f0 100755\n--- a/ci/install-dependencies.sh\n+++ b/ci/install-dependencies.sh\n@@ -87,6 +87,10 @@ macos-*)\n esac\n \n case \"$jobname\" in\n+ClangFormat)\n+\tsudo apt-get -q update\n+\tsudo apt-get -q -y install clang-format\n+\t;;\n StaticAnalysis)\n \tsudo apt-get -q update\n \tsudo apt-get -q -y install coccinelle libcurl4-openssl-dev libssl-dev \\\ndiff --git a/ci/run-style-check.sh b/ci/run-style-check.sh\nnew file mode 100755\nindex 0000000000..76dd37d22b\n--- /dev/null\n+++ b/ci/run-style-check.sh\n@@ -0,0 +1,8 @@\n+#!/bin/sh\n+#\n+# Perform style check\n+#\n+\n+baseCommit=$1\n+\n+git clang-format --style file --diff --extensions c,h \"$baseCommit\"\n-- \n2.45.2\n\n"},{"id":"498907","messageId":"20240718081605.452366-6-karthik.188@gmail.com","threadId":"61750","inReplyTo":"20240718081605.452366-1-karthik.188@gmail.com","subject":"[PATCH v5 5/6] check-whitespace: detect if no base_commit is provided","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-18T08:16:04Z","receivedAt":"2024-07-18T08:16:15Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"The 'check-whitespace' CI script exits gracefully if no base commit is\nprovided or if an invalid revision is provided. This is not good because\nif a particular CI provides an incorrect base_commit, it would fail\nsuccessfully.\n\nThis is exactly the case with the GitLab CI. The CI is using the\n\"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\" variable to get the base commit\nSHA, but variable is only defined for _merged_ pipelines. So it is empty\nfor regular pipelines [1]. This should've failed the check-whitespace\njob.\n\nLet's fallback to 'CI_MERGE_REQUEST_DIFF_BASE_SHA' if\n\"CI_MERGE_REQUEST_TARGET_BRANCH_SHA\" isn't available in GitLab CI,\nsimilar to the previous commit. Let's also add a check for incorrect\nbase_commit in the 'check-whitespace.sh' script. While here, fix a small\ntypo too.\n\n[1]: https://docs.gitlab.com/ee/ci/variables/predefined_variables.html#predefined-variables-for-merge-request-pipelines\n\nHelped-by: Junio C Hamano \nSigned-off-by: Karthik Nayak \n---\n .gitlab-ci.yml | 13 ++++++++++++-\n ci/check-whitespace.sh | 10 ++++++++--\n 2 files changed, 20 insertions(+), 3 deletions(-)\n\ndiff --git a/.gitlab-ci.yml b/.gitlab-ci.yml\nindex 817266226e..320b78b9ae 100644\n--- a/.gitlab-ci.yml\n+++ b/.gitlab-ci.yml\n@@ -118,8 +118,19 @@ check-whitespace:\n image: ubuntu:latest\n before_script:\n - ./ci/install-dependencies.sh\n+ # Since $CI_MERGE_REQUEST_TARGET_BRANCH_SHA is only defined for merged\n+ # pipelines, we fallback to $CI_MERGE_REQUEST_DIFF_BASE_SHA, which should\n+ # be defined in all pipelines.\n script:\n- - ./ci/check-whitespace.sh \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\"\n+ - |\n+ R=${CI_MERGE_REQUEST_TARGET_BRANCH_SHA-${CI_MERGE_REQUEST_DIFF_BASE_SHA?}}\n+\n+ if test -z \"$R\"\n+ then\n+ echo \"CI_MERGE_REQUEST_DIFF_BASE_SHA should always exist!\"\n+ exit 1\n+ fi\n+ ./ci/check-whitespace.sh \"$R\"\n rules:\n - if: $CI_PIPELINE_SOURCE == 'merge_request_event'\n \ndiff --git a/ci/check-whitespace.sh b/ci/check-whitespace.sh\nindex db399097a5..c40804394c 100755\n--- a/ci/check-whitespace.sh\n+++ b/ci/check-whitespace.sh\n@@ -9,7 +9,7 @@ baseCommit=$1\n outputFile=$2\n url=$3\n \n-if test \"$#\" -ne 1 && test \"$#\" -ne 3\n+if test \"$#\" -ne 1 && test \"$#\" -ne 3 || test -z \"$1\"\n then\n \techo \"USAGE: $0 [ ]\"\n \texit 1\n@@ -21,6 +21,12 @@ commitText=\n commitTextmd=\n goodParent=\n \n+if ! git rev-parse --quiet --verify \"${baseCommit}\"\n+then\n+ echo \"Invalid '${baseCommit}'\"\n+ exit 1\n+fi\n+\n while read dash sha etc\n do\n \tcase \"${dash}\" in\n@@ -67,7 +73,7 @@ then\n \t\tgoodParent=${baseCommit: 0:7}\n \tfi\n \n-\techo \"A whitespace issue was found in onen of more of the commits.\"\n+\techo \"A whitespace issue was found in one or more of the commits.\"\n \techo \"Run the following command to resolve whitespace issues:\"\n \techo \"git rebase --whitespace=fix ${goodParent}\"\n \n-- \n2.45.2\n\n"},{"id":"498908","messageId":"20240718081605.452366-7-karthik.188@gmail.com","threadId":"61750","inReplyTo":"20240718081605.452366-1-karthik.188@gmail.com","subject":"[PATCH v5 6/6] ci/style-check: add `RemoveBracesLLVM` in CI job","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-18T08:16:05Z","receivedAt":"2024-07-18T08:16:16Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"For 'clang-format', setting 'RemoveBracesLLVM' to 'true', adds a check\nto ensure we avoid curly braces for single-statement bodies in\nconditional blocks.\n\nHowever, the option does come with two warnings [1]:\n\n This option will be renamed and expanded to support other styles.\n\nand\n\n Setting this option to true could lead to incorrect code formatting\n due to clang-format’s lack of complete semantic information. As\n such, extra care should be taken to review code changes made by\n this option.\n\nThe latter seems to be of concern. While we want to experiment with the\nrule, adding it to the in-tree '.clang-format' could affect end-users.\nLet's only add it to the CI jobs for now. With time, we can evaluate\nits efficacy and decide if we want to add it to '.clang-format' or\nretract it entirely. We do so, by adding the existing rules in\n'.clang-format' and this rule to a temp file outside the working tree,\nwhich is then used by 'git clang-format'. This ensures we don't murk\nwith files in-tree.\n\n[1]: https://clang.llvm.org/docs/ClangFormatStyleOptions.html#removebracesllvm\n\nSigned-off-by: Karthik Nayak \n---\n ci/run-style-check.sh | 19 ++++++++++++++++++-\n 1 file changed, 18 insertions(+), 1 deletion(-)\n\ndiff --git a/ci/run-style-check.sh b/ci/run-style-check.sh\nindex 76dd37d22b..6cd4b1d934 100755\n--- a/ci/run-style-check.sh\n+++ b/ci/run-style-check.sh\n@@ -5,4 +5,21 @@\n \n baseCommit=$1\n \n-git clang-format --style file --diff --extensions c,h \"$baseCommit\"\n+# Remove optional braces of control statements (if, else, for, and while)\n+# according to the LLVM coding style. This avoids braces on simple\n+# single-statement bodies of statements but keeps braces if one side of\n+# if/else if/.../else cascade has multi-statement body.\n+#\n+# As this rule comes with a warning [1], we want to experiment with it\n+# before adding it in-tree. since the CI job for the style check is allowed\n+# to fail, appending the rule here allows us to validate its efficacy.\n+# While also ensuring that end-users are not affected directly.\n+#\n+# [1]: https://clang.llvm.org/docs/ClangFormatStyleOptions.html#removebracesllvm\n+{\n+\tcat .clang-format\n+\techo \"RemoveBracesLLVM: true\"\n+} >/tmp/clang-format-rules\n+\n+git clang-format --style=file:/tmp/clang-format-rules \\\n+\t--diff --extensions c,h \"$baseCommit\"\n-- \n2.45.2\n\n"},{"id":"498909","messageId":"CAOLa=ZQkxOTSMih+-sKuHRdRFdrzxgiJdzXdyesM3523t65RJA@mail.gmail.com","threadId":"61750","inReplyTo":"xmqqcyne30eb.fsf@gitster.g","subject":"Re: [PATCH v3 8/8] ci/style-check: add `RemoveBracesLLVM` to '.clang-format'","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-18T08:18:02Z","receivedAt":"2024-07-18T08:18:08Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"Junio C Hamano writes:\n\n> Karthik Nayak writes:\n>\n>>> If we know we can write into /tmp/clang-format-rules file, then the\n>>> CI script can do something like\n>>>\n>>> \t{\n>>> \t\tcat .clang-format\n>>> \t\techo echo \"RemoveBracesLLVM: true\"\n>>> \t} >/tmp/clang-format-rules\n>>> \tgit clang-format --style=file:/tmp/clang-format-rules \\\n>>> \t\t --diff --extensions c,h \"$baseCommit\"\n>>>\n>>> right? Then \"git status\" would even say \"there is no untracked\n>>> cruft\" (although I do not know we *need* to keep the working tree\n>>> that clean, without untracked cruft).\n>>\n>> Yes this is the best solution.\n>\n> FWIW, I think an in-tree throw-away file is a better option, simply\n> because we _know_ that the working tree can be written (by the fact\n> that we can do \"make\" and have compilers write *.o and other cruft),\n> but we do not know if the CI environment allows us to write to /tmp\n> or /var/tmp or /usr/local/tmp and you do not want to run around and\n> see if there is a suitable temporary directory you can use.\n\nSorry I got a bit busy with work. But I did end up testing out writing\nto a temp file and it works on both GitHub and GitLab CIs. Also I found\nsome of the rules are too new for the clang-format in GitHub, so I\nremoved some of them.\n\nOverall, I've sent a new version with these changes.\n"},{"id":"498917","messageId":"xmqqv812ztgu.fsf@gitster.g","threadId":"61750","inReplyTo":"CAOLa=ZQkxOTSMih+-sKuHRdRFdrzxgiJdzXdyesM3523t65RJA@mail.gmail.com","subject":"Re: [PATCH v3 8/8] ci/style-check: add `RemoveBracesLLVM` to '.clang-format'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-07-18T14:05:05Z","receivedAt":"2024-07-18T14:05:12Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Karthik Nayak writes:\n\n> Sorry I got a bit busy with work. But I did end up testing out writing\n> to a temp file and it works on both GitHub and GitLab CIs. Also I found\n> some of the rules are too new for the clang-format in GitHub, so I\n> removed some of them.\n\nThanks, both are really appreciated, especially the latter about\nchecking the features that are available.\n\n"},{"id":"498923","messageId":"xmqqmsmeycj7.fsf@gitster.g","threadId":"61750","inReplyTo":"20240718081605.452366-5-karthik.188@gmail.com","subject":"Re: [PATCH v5 4/6] ci: run style check on GitHub and GitLab","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-07-18T14:56:12Z","receivedAt":"2024-07-18T14:56:18Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Karthik Nayak writes:\n\n> + # Since $CI_MERGE_REQUEST_TARGET_BRANCH_SHA is only defined for merged\n> + # pipelines, we fallback to $CI_MERGE_REQUEST_DIFF_BASE_SHA, which should\n> + # be defined in all pipelines.\n> + script:\n> + - |\n> + R=${CI_MERGE_REQUEST_TARGET_BRANCH_SHA-${CI_MERGE_REQUEST_DIFF_BASE_SHA?}}\n> +\n> + if test -z \"$R\"\n> + then\n> + echo \"CI_MERGE_REQUEST_DIFF_BASE_SHA should always exist!\"\n> + exit 1\n> + fi\n\nIf you update the assignment to R to\n\n R=${CI_MERGE_REQUEST_TARGET_BRANCH_SHA-${CI_MERGE_REQUEST_DIFF_BASE_SHA:?}}\n\nan unset CI_MERGE_REQUEST_DIFF_BASE_SHA1 or an empty value in it\nwill be rejected there. Then you can lose the if/then/fi here.\n\n> + ./ci/run-style-check.sh \"$R\"\n> + rules:\n> + - if: $CI_PIPELINE_SOURCE == 'merge_request_event'\n> +\n> documentation:\n> image: ubuntu:latest\n> variables:\n> diff --git a/ci/install-dependencies.sh b/ci/install-dependencies.sh\n> index 6ec0f85972..fb34ced8f0 100755\n> --- a/ci/install-dependencies.sh\n> +++ b/ci/install-dependencies.sh\n> @@ -87,6 +87,10 @@ macos-*)\n> esac\n> \n> case \"$jobname\" in\n> +ClangFormat)\n> +\tsudo apt-get -q update\n> +\tsudo apt-get -q -y install clang-format\n> +\t;;\n> StaticAnalysis)\n> \tsudo apt-get -q update\n> \tsudo apt-get -q -y install coccinelle libcurl4-openssl-dev libssl-dev \\\n> diff --git a/ci/run-style-check.sh b/ci/run-style-check.sh\n> new file mode 100755\n> index 0000000000..76dd37d22b\n> --- /dev/null\n> +++ b/ci/run-style-check.sh\n> @@ -0,0 +1,8 @@\n> +#!/bin/sh\n> +#\n> +# Perform style check\n> +#\n> +\n> +baseCommit=$1\n> +\n> +git clang-format --style file --diff --extensions c,h \"$baseCommit\"\n"},{"id":"498924","messageId":"xmqqfrs6ycc3.fsf@gitster.g","threadId":"61750","inReplyTo":"20240718081605.452366-6-karthik.188@gmail.com","subject":"Re: [PATCH v5 5/6] check-whitespace: detect if no base_commit is provided","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-07-18T15:00:28Z","receivedAt":"2024-07-18T15:00:34Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Karthik Nayak writes:\n\n> + - |\n> + R=${CI_MERGE_REQUEST_TARGET_BRANCH_SHA-${CI_MERGE_REQUEST_DIFF_BASE_SHA?}}\n> +\n> + if test -z \"$R\"\n> + then\n> + echo \"CI_MERGE_REQUEST_DIFF_BASE_SHA should always exist!\"\n> + exit 1\n> + fi\n\nThe same comment applies as the previous step.\n\n\tR=${A-${B:?}} || exit\n\nshould be sufficient.\n\nA demonstration.\n\n $ unset A; unset B; C=${A-${B:?}} && echo \"C=$C\"\n bash: B: parameter null or not set\n $ A=a; unset B; C=${A-${B:?}} && echo \"C=$C\"\n C=a\n $ unset A; B=; C=${A-${B:?}} && echo \"C=$C\"\n bash: B: parameter null or not set\n $ unset A; B=b; C=${A-${B:?}} && echo \"C=$C\"\n C=b\n $ A=a; B=b; C=${A-${B:?}} && echo \"C=$C\"\n C=a\n\nNote that the broken case we do not see C= becaues the\nassignment fails with non-zero status.\n\nThanks.\n"},{"id":"498926","messageId":"xmqq1q3qybx0.fsf@gitster.g","threadId":"61750","inReplyTo":"20240718081605.452366-1-karthik.188@gmail.com","subject":"Re: [PATCH v5 0/6] : add more rules and enable on CI","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-07-18T15:09:31Z","receivedAt":"2024-07-18T15:09:34Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Karthik Nayak writes:\n\n> Changes against v4:\n> - While testing out temp file as source for the CI, I noticed that version\n> of clang-format on GitHub is much older than that of GitLab, in accordance\n> with that, I removed some of the rules which are newer and not supported.\n\nLet's see what we lost relative to the previous round.\n \n -# Insert a newline at end of file if missing\n -InsertNewlineAtEOF: true\n\nI guess we can do \"git diff --check $BASE...HEAD\", if we wanted to,\nwhich will trigger 'blank-at-eol' and other whitespace checks.\n\n +# Don't insert spaces inside empty '()'\n +SpaceInEmptyParentheses: false\n +\n -SpacesInParens: Custom\n -SpacesInParensOptions:\n - # Don't insert spaces inside empty '()'\n - InEmptyParentheses: false\n +# Don't insert spaces after '(' or before ')'\n +# f(arg); not f( arg );\n +SpacesInParentheses: false\n \nThis was to express what we used an older construct to express by\nusing a newer construct? So we are not losing anything here.\n\nSo, I guess loss of changes to a few rules is nothing to shed tears\non.\n\nUnrelated to the rules part, this caught my eyes, but\n\n diff --git c/ci/install-dependencies.sh w/ci/install-dependencies.sh\n index 8b01bfb89f..fb34ced8f0 100755\n --- c/ci/install-dependencies.sh\n +++ w/ci/install-dependencies.sh\n -\t\t${CC_PACKAGE:-${CC:-gcc}} $PYTHON_PACKAGE clang-format\n +\t\t${CC_PACKAGE:-${CC:-gcc}} $PYTHON_PACKAGE\n \nthis is to stop installing clang-format everywhere because we are\nalready installing it in ClangFormat job anyway? A good change.\n\nThanks.\n"},{"id":"498929","messageId":"xmqqmsmewusf.fsf@gitster.g","threadId":"61750","inReplyTo":"xmqqmsmeycj7.fsf@gitster.g","subject":"Re: [PATCH v5 4/6] ci: run style check on GitHub and GitLab","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-07-18T16:04:48Z","receivedAt":"2024-07-18T16:04:50Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Karthik Nayak writes:\n> ...\n>> + R=${CI_MERGE_REQUEST_TARGET_BRANCH_SHA-${CI_MERGE_REQUEST_DIFF_BASE_SHA?}}\n>> +\n>> + if test -z \"$R\"\n>> + then\n>> + echo \"CI_MERGE_REQUEST_DIFF_BASE_SHA should always exist!\"\n>> + exit 1\n>> + fi\n>\n> If you update the assignment to R to\n>\n> R=${CI_MERGE_REQUEST_TARGET_BRANCH_SHA-${CI_MERGE_REQUEST_DIFF_BASE_SHA:?}}\n>\n> an unset CI_MERGE_REQUEST_DIFF_BASE_SHA1 or an empty value in it\n> will be rejected there. Then you can lose the if/then/fi here.\n\nActually, you also need to pay attention to the exit status of the\nassignment, i.e.\n\n R=${CI_MERGE_REQUEST_TARGET_BRANCH_SHA-${CI_MERGE_REQUEST_DIFF_BASE_SHA:?}} ||\n exit\n\n"},{"id":"498956","messageId":"CAOLa=ZQhcb7O4i9E=Xn+9ZbaNhiY0gzD_a2kTqriegF2o-Eeyw@mail.gmail.com","threadId":"61750","inReplyTo":"xmqqfrs6ycc3.fsf@gitster.g","subject":"Re: [PATCH v5 5/6] check-whitespace: detect if no base_commit is provided","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-19T08:33:21Z","receivedAt":"2024-07-19T08:33:22Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"Junio C Hamano writes:\n\n> Karthik Nayak writes:\n>\n>> + - |\n>> + R=${CI_MERGE_REQUEST_TARGET_BRANCH_SHA-${CI_MERGE_REQUEST_DIFF_BASE_SHA?}}\n>> +\n>> + if test -z \"$R\"\n>> + then\n>> + echo \"CI_MERGE_REQUEST_DIFF_BASE_SHA should always exist!\"\n>> + exit 1\n>> + fi\n>\n> The same comment applies as the previous step.\n>\n> \tR=${A-${B:?}} || exit\n>\n> should be sufficient.\n>\n> A demonstration.\n>\n> $ unset A; unset B; C=${A-${B:?}} && echo \"C=$C\"\n> bash: B: parameter null or not set\n> $ A=a; unset B; C=${A-${B:?}} && echo \"C=$C\"\n> C=a\n> $ unset A; B=; C=${A-${B:?}} && echo \"C=$C\"\n> bash: B: parameter null or not set\n> $ unset A; B=b; C=${A-${B:?}} && echo \"C=$C\"\n> C=b\n> $ A=a; B=b; C=${A-${B:?}} && echo \"C=$C\"\n> C=a\n>\n> Note that the broken case we do not see C= becaues the\n> assignment fails with non-zero status.\n>\n> Thanks.\n\nThanks Junio for explaining with examples, really nice of you! I'm on\nthe fence with this, even the existing change from the previous more\nverbose code. I know this is shorter, but it is always more readable to\nuse the longer version with 'test'. I find it hard to remember the\nspecifics. But I don't really care which one makes it in the end.\n\nLet me know if you think it is worth a reroll.\n\nThanks\n"},{"id":"498966","messageId":"xmqqbk2tl8zc.fsf@gitster.g","threadId":"61750","inReplyTo":"CAOLa=ZQhcb7O4i9E=Xn+9ZbaNhiY0gzD_a2kTqriegF2o-Eeyw@mail.gmail.com","subject":"Re: [PATCH v5 5/6] check-whitespace: detect if no base_commit is provided","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-07-19T15:03:35Z","receivedAt":"2024-07-19T15:03:41Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Karthik Nayak writes:\n\n> Thanks Junio for explaining with examples, really nice of you! I'm on\n> the fence with this, even the existing change from the previous more\n> verbose code. I know this is shorter, but it is always more readable to\n> use the longer version with 'test'. I find it hard to remember the\n> specifics.\n\nYou'd never remember unless you practice, but it boils down to one\nquestion: is it reasonable to expect that most developers who need\nto touch this code find it worth to learn to read and write shell\nscripts well in this day and age? The answer is probably no.\n\nAs you may remember, this R=${A-${B?}} dance started at\n\n https://lore.kernel.org/git/xmqqwmlpb8er.fsf@gitster.g/\n\nwhere I said:\n\n ...\n in a separate \"after the dust settles\" clean-up #leftoverbits topic.\n\n We could replace the first 7 lines with a single-liner\n\n R=${CI_MERGE_REQUEST_TARGET_BRANCH_SHA-${CI_MERGE_REQUEST_DIFF_BASE_SHA?}}\n\n if we wanted to, but all of that will be mere clean-up changes.\n\nEven the longhand to set a single R with if/elif cascade so that we\ncan have a single location that invokes ci/run-style-check.sh was\nconsidered extra clean-up for #leftoverbits at least by me.\n\nBut after seeing you used the ${A-${B?}} dance, which is more\nadvanced than the #leftoverbits clean-up, I thought you were\ninterested in using such a construct that pursues parameter\nexpansion mastery, and that was the primary reason why the\ndemonstration in the message you are responding to was added.\n\nI personally do not care too deeply which one to use wrt the\nreadability, but\n\n\tR=${A-${B?}}\n\tif test -z \"$R\"\n\tthen\n\t\terror\n\tfi\n\nlooks strange and inconsistent by spreading the error check to two\nplaces. The code would be better off if it were\n\n\tR=${A-$B}\n\tif test -z \"$R\"\n\tthen\n\t\terror\n\tfi\n\n(or with R=${A:-$B}) instead. Then it makes it clear that the\nauthor wanted to take care of the error case with the if part.\n"},{"id":"499046","messageId":"CAOLa=ZQmLFrvZOkysRuGO6=7ZEf3O7c9m1=iaTdRP_uMtHXrug@mail.gmail.com","threadId":"61750","inReplyTo":"xmqqbk2tl8zc.fsf@gitster.g","subject":"Re: [PATCH v5 5/6] check-whitespace: detect if no base_commit is provided","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-22T07:22:08Z","receivedAt":"2024-07-22T07:22:09Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"Junio C Hamano writes:\n\n> Karthik Nayak writes:\n>\n>> Thanks Junio for explaining with examples, really nice of you! I'm on\n>> the fence with this, even the existing change from the previous more\n>> verbose code. I know this is shorter, but it is always more readable to\n>> use the longer version with 'test'. I find it hard to remember the\n>> specifics.\n>\n> You'd never remember unless you practice, but it boils down to one\n> question: is it reasonable to expect that most developers who need\n> to touch this code find it worth to learn to read and write shell\n> scripts well in this day and age? The answer is probably no.\n>\n> As you may remember, this R=${A-${B?}} dance started at\n>\n> https://lore.kernel.org/git/xmqqwmlpb8er.fsf@gitster.g/\n>\n> where I said:\n>\n> ...\n> in a separate \"after the dust settles\" clean-up #leftoverbits topic.\n>\n> We could replace the first 7 lines with a single-liner\n>\n> R=${CI_MERGE_REQUEST_TARGET_BRANCH_SHA-${CI_MERGE_REQUEST_DIFF_BASE_SHA?}}\n>\n> if we wanted to, but all of that will be mere clean-up changes.\n>\n> Even the longhand to set a single R with if/elif cascade so that we\n> can have a single location that invokes ci/run-style-check.sh was\n> considered extra clean-up for #leftoverbits at least by me.\n>\n> But after seeing you used the ${A-${B?}} dance, which is more\n> advanced than the #leftoverbits clean-up, I thought you were\n> interested in using such a construct that pursues parameter\n> expansion mastery, and that was the primary reason why the\n> demonstration in the message you are responding to was added.\n>\n> I personally do not care too deeply which one to use wrt the\n> readability, but\n>\n> \tR=${A-${B?}}\n> \tif test -z \"$R\"\n> \tthen\n> \t\terror\n> \tfi\n>\n> looks strange and inconsistent by spreading the error check to two\n> places. The code would be better off if it were\n>\n> \tR=${A-$B}\n> \tif test -z \"$R\"\n> \tthen\n> \t\terror\n> \tfi\n>\n> (or with R=${A:-$B}) instead. Then it makes it clear that the\n> author wanted to take care of the error case with the if part.\n\nYeah fair enough, we are deep into it and might and makes sense to make\nit more consistent. I'll incorporate your suggestion and send in a new\nversion.\n"},{"id":"499129","messageId":"20240723082111.874382-1-karthik.188@gmail.com","threadId":"61750","inReplyTo":"20240718081605.452366-1-karthik.188@gmail.com","subject":"[PATCH v6 0/6] clang-format: add more rules and enable on CI","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-23T08:21:05Z","receivedAt":"2024-07-23T08:21:15Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"This is v6 of my series to add clang-format to the CI.\n\nThe series was mostly inspired by a patch sent recently to 'include\nkh_foreach* macros in ForEachMacros' [1]. I was wondering why we don't\nrun the formatting on CI and reduce some of the workload of reviewers.\n\nWe have a '.clang-format' file to provide rules for code formatting.\nThe commits 1-3 aims to add more rules to the file.\n\nCommit 4 enables CI action on GitHub and GitLab to also check for the\ncode formatting. Currently, it is allowed to fail. This way we can build\nconfidence and fine tune the values as needed and finally enforce the\ncheck in a future patch. I'm not well versed with GitHub workflows, and\nI mostly tried to copy existing work there. Expecting some feedback in\nthat section!\n\nCommit 5 fixes an existing issue with the 'check-whitespace' job, which\nis failing as success in the GitLab CI.\n\nCommit 6 adds the `RemoveBracesLLVM` only in the context of the CI. If we\ndecide against it, we could drop this commit from the series.\n\n1: https://lore.kernel.org/git/4e7893f5-2dd9-46cf-8a64-cf780f4e1730@web.de/\n\nChanges from v5:\n- Used 'C=${A-${B:?}}' instead of 'C=${A-${B?}}' for obtaining the base OID\nin GitLab CI script. The difference being that the former also checks\nfor B being empty. With this we can simplify the script from\n\n R=${A-${B?}}\n if test -z \"$R\"\n then\n error\n fi\n\nto \n R=${A-${B:?}} || exit\n\n\n* CI without issues\n - GitLab: https://gitlab.com/gitlab-org/git/-/jobs/7394162598\n - GitHub: https://github.com/KarthikNayak/git/actions/runs/10037207688/job/27736512636?pr=1\n* CI with issues detected\n - GitLab: https://gitlab.com/gitlab-org/git/-/jobs/7394406605\n - GitHub: https://github.com/KarthikNayak/git/actions/runs/10037229508/job/27736859486\n\nKarthik Nayak (6):\n clang-format: indent preprocessor directives after hash\n clang-format: avoid spacing around bitfield colon\n clang-format: formalize some of the spacing rules\n ci: run style check on GitHub and GitLab\n check-whitespace: detect if no base_commit is provided\n ci/style-check: add `RemoveBracesLLVM` in CI job\n\n .clang-format | 25 +++++++++++++++++++++++\n .github/workflows/check-style.yml | 34 +++++++++++++++++++++++++++++++\n .gitlab-ci.yml | 25 ++++++++++++++++++++++-\n ci/check-whitespace.sh | 10 +++++++--\n ci/install-dependencies.sh | 4 ++++\n ci/run-style-check.sh | 25 +++++++++++++++++++++++\n 6 files changed, 120 insertions(+), 3 deletions(-)\n create mode 100644 .github/workflows/check-style.yml\n create mode 100755 ci/run-style-check.sh\n\nRange-diff against v5:\n1: 6cf91ffc86 = 1: 6cf91ffc86 clang-format: indent preprocessor directives after hash\n2: beb002885f = 2: beb002885f clang-format: avoid spacing around bitfield colon\n3: 3922529001 = 3: 3922529001 clang-format: formalize some of the spacing rules\n4: ae23eb5af8 ! 4: 14718625ad ci: run style check on GitHub and GitLab\n @@ .gitlab-ci.yml: check-whitespace:\n + # be defined in all pipelines.\n + script:\n + - |\n -+ R=${CI_MERGE_REQUEST_TARGET_BRANCH_SHA-${CI_MERGE_REQUEST_DIFF_BASE_SHA?}}\n -+\n -+ if test -z \"$R\"\n -+ then\n -+ echo \"CI_MERGE_REQUEST_DIFF_BASE_SHA should always exist!\"\n -+ exit 1\n -+ fi\n ++ R=${CI_MERGE_REQUEST_TARGET_BRANCH_SHA-${CI_MERGE_REQUEST_DIFF_BASE_SHA:?}} || exit\n + ./ci/run-style-check.sh \"$R\"\n + rules:\n + - if: $CI_PIPELINE_SOURCE == 'merge_request_event'\n5: a38cde03a8 ! 5: fb8c30852b check-whitespace: detect if no base_commit is provided\n @@ .gitlab-ci.yml: check-whitespace:\n script:\n - - ./ci/check-whitespace.sh \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\"\n + - |\n -+ R=${CI_MERGE_REQUEST_TARGET_BRANCH_SHA-${CI_MERGE_REQUEST_DIFF_BASE_SHA?}}\n -+\n -+ if test -z \"$R\"\n -+ then\n -+ echo \"CI_MERGE_REQUEST_DIFF_BASE_SHA should always exist!\"\n -+ exit 1\n -+ fi\n ++ R=${CI_MERGE_REQUEST_TARGET_BRANCH_SHA-${CI_MERGE_REQUEST_DIFF_BASE_SHA:?}} || exit\n + ./ci/check-whitespace.sh \"$R\"\n rules:\n - if: $CI_PIPELINE_SOURCE == 'merge_request_event'\n6: 008e77bd0a = 6: 08c5bb777d ci/style-check: add `RemoveBracesLLVM` in CI job\n-- \n2.45.2\n\n"},{"id":"499130","messageId":"20240723082111.874382-2-karthik.188@gmail.com","threadId":"61750","inReplyTo":"20240723082111.874382-1-karthik.188@gmail.com","subject":"[PATCH v6 1/6] clang-format: indent preprocessor directives after hash","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-23T08:21:06Z","receivedAt":"2024-07-23T08:21:16Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"We do not have a rule around the indentation of preprocessor directives.\nThis was also discussed on the list [1], noting how there is often\ninconsistency in the styling. While there was discussion, there was no\nconclusion around what is the preferred style here. One style being\nindenting after the hash:\n\n #if FOO\n # if BAR\n # include \n # endif\n #endif\n\nThe other being before the hash:\n\n #if FOO\n #if BAR\n #include \n #endif\n #endif\n\nLet's pick the former and add 'IndentPPDirectives: AfterHash' value to\nour '.clang-format'. There is no clear reason to pick one over the\nother, but it would definitely be nicer to be consistent.\n\n[1]: https://lore.kernel.org/r/xmqqwmmm1bw6.fsf@gitster.g\n\nSigned-off-by: Karthik Nayak \n---\n .clang-format | 6 ++++++\n 1 file changed, 6 insertions(+)\n\ndiff --git a/.clang-format b/.clang-format\nindex 3ed4fac753..5e128519bf 100644\n--- a/.clang-format\n+++ b/.clang-format\n@@ -96,6 +96,12 @@ BreakStringLiterals: false\n # Switch statement body is always indented one level more than case labels.\n IndentCaseLabels: false\n \n+# Indents directives before the hash.\n+# #if FOO\n+# # include \n+# #endif\n+IndentPPDirectives: AfterHash\n+\n # Don't indent a function definition or declaration if it is wrapped after the\n # type\n IndentWrappedFunctionNames: false\n-- \n2.45.2\n\n"},{"id":"499131","messageId":"20240723082111.874382-3-karthik.188@gmail.com","threadId":"61750","inReplyTo":"20240723082111.874382-1-karthik.188@gmail.com","subject":"[PATCH v6 2/6] clang-format: avoid spacing around bitfield colon","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-23T08:21:07Z","receivedAt":"2024-07-23T08:21:17Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"The spacing around colons is currently not standardized and as such we\nhave the following practices in our code base:\n- Spacing around the colon `int bf : 1`: 146 instances\n- No spacing around the colon `int bf:1`: 148 instances\n- Spacing before the colon `int bf :1`: 6 instances\n- Spacing after the colon `int bf: 1`: 12 instances\n\nLet's formalize this by picking the most followed pattern and add the\ncorresponding style to '.clang-format'.\n\nSigned-off-by: Karthik Nayak \n---\n .clang-format | 4 ++++\n 1 file changed, 4 insertions(+)\n\ndiff --git a/.clang-format b/.clang-format\nindex 5e128519bf..803b274dd5 100644\n--- a/.clang-format\n+++ b/.clang-format\n@@ -72,6 +72,10 @@ AlwaysBreakAfterReturnType: None\n BinPackArguments: true\n BinPackParameters: true\n \n+# Add no space around the bit field\n+# unsigned bf:2;\n+BitFieldColonSpacing: None\n+\n # Attach braces to surrounding context except break before braces on function\n # definitions.\n # void foo()\n-- \n2.45.2\n\n"},{"id":"499132","messageId":"20240723082111.874382-4-karthik.188@gmail.com","threadId":"61750","inReplyTo":"20240723082111.874382-1-karthik.188@gmail.com","subject":"[PATCH v6 3/6] clang-format: formalize some of the spacing rules","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-23T08:21:08Z","receivedAt":"2024-07-23T08:21:18Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"There are some spacing rules that we follow in the project and it makes\nsense to formalize them:\n* Ensure there is no space inserted after the logical not '!' operator.\n* Ensure there is no space before the case statement's colon.\n* Ensure there is no space before the first bracket '[' of an array.\n* Ensure there is no space in empty blocks.\n\nSigned-off-by: Karthik Nayak \n---\n .clang-format | 15 +++++++++++++++\n 1 file changed, 15 insertions(+)\n\ndiff --git a/.clang-format b/.clang-format\nindex 803b274dd5..3c8018a1dd 100644\n--- a/.clang-format\n+++ b/.clang-format\n@@ -118,11 +118,18 @@ PointerAlignment: Right\n # x = (int32)y; not x = (int32) y;\n SpaceAfterCStyleCast: false\n \n+# No space is inserted after the logical not operator\n+SpaceAfterLogicalNot: false\n+\n # Insert spaces before and after assignment operators\n # int a = 5; not int a=5;\n # a += 42; a+=42;\n SpaceBeforeAssignmentOperators: true\n \n+# Spaces will be removed before case colon.\n+# case 1: break; not case 1 : break;\n+SpaceBeforeCaseColon: false\n+\n # Put a space before opening parentheses only after control statement keywords.\n # void f() {\n # if (true) {\n@@ -134,6 +141,14 @@ SpaceBeforeParens: ControlStatements\n # Don't insert spaces inside empty '()'\n SpaceInEmptyParentheses: false\n \n+# No space before first '[' in arrays\n+# int a[5][5]; not int a [5][5];\n+SpaceBeforeSquareBrackets: false\n+\n+# No space will be inserted into {}\n+# while (true) {} not while (true) { }\n+SpaceInEmptyBlock: false\n+\n # The number of spaces before trailing line comments (// - comments).\n # This does not affect trailing block comments (/* - comments).\n SpacesBeforeTrailingComments: 1\n-- \n2.45.2\n\n"},{"id":"499133","messageId":"20240723082111.874382-5-karthik.188@gmail.com","threadId":"61750","inReplyTo":"20240723082111.874382-1-karthik.188@gmail.com","subject":"[PATCH v6 4/6] ci: run style check on GitHub and GitLab","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-23T08:21:09Z","receivedAt":"2024-07-23T08:21:19Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"We don't run style checks on our CI, even though we have a\n'.clang-format' setup in the repository. Let's add one, the job will\nvalidate only against the new commits added and will only run on merge\nrequests. Since we're introducing it for the first time, let's allow\nthis job to fail, so we can validate if this is useful and eventually\nenforce it.\n\nFor GitHub, we allow the job to pass by adding 'continue-on-error: true'\nto the workflow. This means the job would show as passed, even if the\nstyle check failed. To know the status of the job, users have to\nmanually check the logs.\n\nFor GitLab, we allow the job to pass by adding 'allow_failure: true', to\nthe job. Unlike GitHub, here the job will show as failed with a yellow\nwarning symbol, but the pipeline would still show as passed.\n\nAlso for GitLab, we use the 'CI_MERGE_REQUEST_TARGET_BRANCH_SHA'\nvariable by default to obtain the base SHA of the merged pipeline (which\nis only available for merged pipelines [1]). Otherwise we use the\n'CI_MERGE_REQUEST_DIFF_BASE_SHA' variable.\n\n[1]: https://docs.gitlab.com/ee/ci/variables/predefined_variables.html#predefined-variables-for-merge-request-pipelines\n\nHelped-by: Junio C Hamano \nSigned-off-by: Karthik Nayak \n---\n .github/workflows/check-style.yml | 34 +++++++++++++++++++++++++++++++\n .gitlab-ci.yml | 18 ++++++++++++++++\n ci/install-dependencies.sh | 4 ++++\n ci/run-style-check.sh | 8 ++++++++\n 4 files changed, 64 insertions(+)\n create mode 100644 .github/workflows/check-style.yml\n create mode 100755 ci/run-style-check.sh\n\ndiff --git a/.github/workflows/check-style.yml b/.github/workflows/check-style.yml\nnew file mode 100644\nindex 0000000000..c052a5df23\n--- /dev/null\n+++ b/.github/workflows/check-style.yml\n@@ -0,0 +1,34 @@\n+name: check-style\n+\n+# Get the repository with all commits to ensure that we can analyze\n+# all of the commits contributed via the Pull Request.\n+\n+on:\n+ pull_request:\n+ types: [opened, synchronize]\n+\n+# Avoid unnecessary builds. Unlike the main CI jobs, these are not\n+# ci-configurable (but could be).\n+concurrency:\n+ group: ${{ github.workflow }}-${{ github.ref }}\n+ cancel-in-progress: true\n+\n+jobs:\n+ check-style:\n+ env:\n+ CC: clang\n+ jobname: ClangFormat\n+ runs-on: ubuntu-latest\n+ steps:\n+ - uses: actions/checkout@v4\n+ with:\n+ fetch-depth: 0\n+\n+ - run: ci/install-dependencies.sh\n+\n+ - name: git clang-format\n+ continue-on-error: true\n+ id: check_out\n+ run: |\n+ ./ci/run-style-check.sh \\\n+ \"${{github.event.pull_request.base.sha}}\"\ndiff --git a/.gitlab-ci.yml b/.gitlab-ci.yml\nindex 37b991e080..2886f6e182 100644\n--- a/.gitlab-ci.yml\n+++ b/.gitlab-ci.yml\n@@ -123,6 +123,24 @@ check-whitespace:\n rules:\n - if: $CI_PIPELINE_SOURCE == 'merge_request_event'\n \n+check-style:\n+ image: ubuntu:latest\n+ allow_failure: true\n+ variables:\n+ CC: clang\n+ jobname: ClangFormat\n+ before_script:\n+ - ./ci/install-dependencies.sh\n+ # Since $CI_MERGE_REQUEST_TARGET_BRANCH_SHA is only defined for merged\n+ # pipelines, we fallback to $CI_MERGE_REQUEST_DIFF_BASE_SHA, which should\n+ # be defined in all pipelines.\n+ script:\n+ - |\n+ R=${CI_MERGE_REQUEST_TARGET_BRANCH_SHA-${CI_MERGE_REQUEST_DIFF_BASE_SHA:?}} || exit\n+ ./ci/run-style-check.sh \"$R\"\n+ rules:\n+ - if: $CI_PIPELINE_SOURCE == 'merge_request_event'\n+\n documentation:\n image: ubuntu:latest\n variables:\ndiff --git a/ci/install-dependencies.sh b/ci/install-dependencies.sh\nindex 6ec0f85972..fb34ced8f0 100755\n--- a/ci/install-dependencies.sh\n+++ b/ci/install-dependencies.sh\n@@ -87,6 +87,10 @@ macos-*)\n esac\n \n case \"$jobname\" in\n+ClangFormat)\n+\tsudo apt-get -q update\n+\tsudo apt-get -q -y install clang-format\n+\t;;\n StaticAnalysis)\n \tsudo apt-get -q update\n \tsudo apt-get -q -y install coccinelle libcurl4-openssl-dev libssl-dev \\\ndiff --git a/ci/run-style-check.sh b/ci/run-style-check.sh\nnew file mode 100755\nindex 0000000000..76dd37d22b\n--- /dev/null\n+++ b/ci/run-style-check.sh\n@@ -0,0 +1,8 @@\n+#!/bin/sh\n+#\n+# Perform style check\n+#\n+\n+baseCommit=$1\n+\n+git clang-format --style file --diff --extensions c,h \"$baseCommit\"\n-- \n2.45.2\n\n"},{"id":"499134","messageId":"20240723082111.874382-6-karthik.188@gmail.com","threadId":"61750","inReplyTo":"20240723082111.874382-1-karthik.188@gmail.com","subject":"[PATCH v6 5/6] check-whitespace: detect if no base_commit is provided","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-23T08:21:10Z","receivedAt":"2024-07-23T08:21:20Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"The 'check-whitespace' CI script exits gracefully if no base commit is\nprovided or if an invalid revision is provided. This is not good because\nif a particular CI provides an incorrect base_commit, it would fail\nsuccessfully.\n\nThis is exactly the case with the GitLab CI. The CI is using the\n\"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\" variable to get the base commit\nSHA, but variable is only defined for _merged_ pipelines. So it is empty\nfor regular pipelines [1]. This should've failed the check-whitespace\njob.\n\nLet's fallback to 'CI_MERGE_REQUEST_DIFF_BASE_SHA' if\n\"CI_MERGE_REQUEST_TARGET_BRANCH_SHA\" isn't available in GitLab CI,\nsimilar to the previous commit. Let's also add a check for incorrect\nbase_commit in the 'check-whitespace.sh' script. While here, fix a small\ntypo too.\n\n[1]: https://docs.gitlab.com/ee/ci/variables/predefined_variables.html#predefined-variables-for-merge-request-pipelines\n\nHelped-by: Junio C Hamano \nSigned-off-by: Karthik Nayak \n---\n .gitlab-ci.yml | 7 ++++++-\n ci/check-whitespace.sh | 10 ++++++++--\n 2 files changed, 14 insertions(+), 3 deletions(-)\n\ndiff --git a/.gitlab-ci.yml b/.gitlab-ci.yml\nindex 2886f6e182..2589098eff 100644\n--- a/.gitlab-ci.yml\n+++ b/.gitlab-ci.yml\n@@ -118,8 +118,13 @@ check-whitespace:\n image: ubuntu:latest\n before_script:\n - ./ci/install-dependencies.sh\n+ # Since $CI_MERGE_REQUEST_TARGET_BRANCH_SHA is only defined for merged\n+ # pipelines, we fallback to $CI_MERGE_REQUEST_DIFF_BASE_SHA, which should\n+ # be defined in all pipelines.\n script:\n- - ./ci/check-whitespace.sh \"$CI_MERGE_REQUEST_TARGET_BRANCH_SHA\"\n+ - |\n+ R=${CI_MERGE_REQUEST_TARGET_BRANCH_SHA-${CI_MERGE_REQUEST_DIFF_BASE_SHA:?}} || exit\n+ ./ci/check-whitespace.sh \"$R\"\n rules:\n - if: $CI_PIPELINE_SOURCE == 'merge_request_event'\n \ndiff --git a/ci/check-whitespace.sh b/ci/check-whitespace.sh\nindex db399097a5..c40804394c 100755\n--- a/ci/check-whitespace.sh\n+++ b/ci/check-whitespace.sh\n@@ -9,7 +9,7 @@ baseCommit=$1\n outputFile=$2\n url=$3\n \n-if test \"$#\" -ne 1 && test \"$#\" -ne 3\n+if test \"$#\" -ne 1 && test \"$#\" -ne 3 || test -z \"$1\"\n then\n \techo \"USAGE: $0 [ ]\"\n \texit 1\n@@ -21,6 +21,12 @@ commitText=\n commitTextmd=\n goodParent=\n \n+if ! git rev-parse --quiet --verify \"${baseCommit}\"\n+then\n+ echo \"Invalid '${baseCommit}'\"\n+ exit 1\n+fi\n+\n while read dash sha etc\n do\n \tcase \"${dash}\" in\n@@ -67,7 +73,7 @@ then\n \t\tgoodParent=${baseCommit: 0:7}\n \tfi\n \n-\techo \"A whitespace issue was found in onen of more of the commits.\"\n+\techo \"A whitespace issue was found in one or more of the commits.\"\n \techo \"Run the following command to resolve whitespace issues:\"\n \techo \"git rebase --whitespace=fix ${goodParent}\"\n \n-- \n2.45.2\n\n"},{"id":"499135","messageId":"20240723082111.874382-7-karthik.188@gmail.com","threadId":"61750","inReplyTo":"20240723082111.874382-1-karthik.188@gmail.com","subject":"[PATCH v6 6/6] ci/style-check: add `RemoveBracesLLVM` in CI job","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-23T08:21:11Z","receivedAt":"2024-07-23T08:21:21Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"For 'clang-format', setting 'RemoveBracesLLVM' to 'true', adds a check\nto ensure we avoid curly braces for single-statement bodies in\nconditional blocks.\n\nHowever, the option does come with two warnings [1]:\n\n This option will be renamed and expanded to support other styles.\n\nand\n\n Setting this option to true could lead to incorrect code formatting\n due to clang-format’s lack of complete semantic information. As\n such, extra care should be taken to review code changes made by\n this option.\n\nThe latter seems to be of concern. While we want to experiment with the\nrule, adding it to the in-tree '.clang-format' could affect end-users.\nLet's only add it to the CI jobs for now. With time, we can evaluate\nits efficacy and decide if we want to add it to '.clang-format' or\nretract it entirely. We do so, by adding the existing rules in\n'.clang-format' and this rule to a temp file outside the working tree,\nwhich is then used by 'git clang-format'. This ensures we don't murk\nwith files in-tree.\n\n[1]: https://clang.llvm.org/docs/ClangFormatStyleOptions.html#removebracesllvm\n\nSigned-off-by: Karthik Nayak \n---\n ci/run-style-check.sh | 19 ++++++++++++++++++-\n 1 file changed, 18 insertions(+), 1 deletion(-)\n\ndiff --git a/ci/run-style-check.sh b/ci/run-style-check.sh\nindex 76dd37d22b..6cd4b1d934 100755\n--- a/ci/run-style-check.sh\n+++ b/ci/run-style-check.sh\n@@ -5,4 +5,21 @@\n \n baseCommit=$1\n \n-git clang-format --style file --diff --extensions c,h \"$baseCommit\"\n+# Remove optional braces of control statements (if, else, for, and while)\n+# according to the LLVM coding style. This avoids braces on simple\n+# single-statement bodies of statements but keeps braces if one side of\n+# if/else if/.../else cascade has multi-statement body.\n+#\n+# As this rule comes with a warning [1], we want to experiment with it\n+# before adding it in-tree. since the CI job for the style check is allowed\n+# to fail, appending the rule here allows us to validate its efficacy.\n+# While also ensuring that end-users are not affected directly.\n+#\n+# [1]: https://clang.llvm.org/docs/ClangFormatStyleOptions.html#removebracesllvm\n+{\n+\tcat .clang-format\n+\techo \"RemoveBracesLLVM: true\"\n+} >/tmp/clang-format-rules\n+\n+git clang-format --style=file:/tmp/clang-format-rules \\\n+\t--diff --extensions c,h \"$baseCommit\"\n-- \n2.45.2\n\n"},{"id":"499223","messageId":"ZqCkJHC3ivdNVm9E@tanuki","threadId":"61750","inReplyTo":"20240723082111.874382-2-karthik.188@gmail.com","subject":"Re: [PATCH v6 1/6] clang-format: indent preprocessor directives after hash","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2024-07-24T06:50:12Z","receivedAt":"2024-07-24T06:50:18Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Tue, Jul 23, 2024 at 10:21:06AM +0200, Karthik Nayak wrote:\n> We do not have a rule around the indentation of preprocessor directives.\n> This was also discussed on the list [1], noting how there is often\n> inconsistency in the styling. While there was discussion, there was no\n> conclusion around what is the preferred style here. One style being\n> indenting after the hash:\n> \n> #if FOO\n> # if BAR\n> # include \n> # endif\n> #endif\n> \n> The other being before the hash:\n> \n> #if FOO\n> #if BAR\n> #include \n> #endif\n> #endif\n> \n> Let's pick the former and add 'IndentPPDirectives: AfterHash' value to\n> our '.clang-format'. There is no clear reason to pick one over the\n> other, but it would definitely be nicer to be consistent.\n> \n> [1]: https://lore.kernel.org/r/xmqqwmmm1bw6.fsf@gitster.g\n> \n> Signed-off-by: Karthik Nayak \n\nThis doesn't necessarily have to be part of this patch series, but I\nthink that we should document this as part of our CodingGuidelines, as\nwell. I planned to send an update to the coding guidelines soon anyway,\nso I can handle that once this topic lands.\n\nPatrick\n"},{"id":"499237","messageId":"CAOLa=ZQ-VAgG3Qby94xz9ih=CROgYsRSUi894p7jErKFVg1xRw@mail.gmail.com","threadId":"61750","inReplyTo":"ZqCkJHC3ivdNVm9E@tanuki","subject":"Re: [PATCH v6 1/6] clang-format: indent preprocessor directives after hash","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2024-07-24T08:55:09Z","receivedAt":"2024-07-24T08:55:11Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"Patrick Steinhardt writes:\n\n> On Tue, Jul 23, 2024 at 10:21:06AM +0200, Karthik Nayak wrote:\n>> We do not have a rule around the indentation of preprocessor directives.\n>> This was also discussed on the list [1], noting how there is often\n>> inconsistency in the styling. While there was discussion, there was no\n>> conclusion around what is the preferred style here. One style being\n>> indenting after the hash:\n>>\n>> #if FOO\n>> # if BAR\n>> # include \n>> # endif\n>> #endif\n>>\n>> The other being before the hash:\n>>\n>> #if FOO\n>> #if BAR\n>> #include \n>> #endif\n>> #endif\n>>\n>> Let's pick the former and add 'IndentPPDirectives: AfterHash' value to\n>> our '.clang-format'. There is no clear reason to pick one over the\n>> other, but it would definitely be nicer to be consistent.\n>>\n>> [1]: https://lore.kernel.org/r/xmqqwmmm1bw6.fsf@gitster.g\n>>\n>> Signed-off-by: Karthik Nayak \n>\n> This doesn't necessarily have to be part of this patch series, but I\n> think that we should document this as part of our CodingGuidelines, as\n> well. I planned to send an update to the coding guidelines soon anyway,\n> so I can handle that once this topic lands.\n>\n> Patrick\n\nYeah, that would be great indeed. I think this series is now merged to\nnext.\n\nThank Patrick\n"},{"id":"520411","messageId":"xmqq5xgrdan8.fsf@gitster.g","threadId":"61750","inReplyTo":"20240723082111.874382-7-karthik.188@gmail.com","subject":"Re: [PATCH v6 6/6] ci/style-check: add `RemoveBracesLLVM` in CI job","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-06-19T15:16:43Z","receivedAt":"2025-06-19T15:16:46Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Karthik Nayak writes:\n\n> For 'clang-format', setting 'RemoveBracesLLVM' to 'true', adds a check\n> to ensure we avoid curly braces for single-statement bodies in\n> conditional blocks.\n>\n> However, the option does come with two warnings [1]:\n>\n> This option will be renamed and expanded to support other styles.\n>\n> and\n>\n> Setting this option to true could lead to incorrect code formatting\n> due to clang-format’s lack of complete semantic information. As\n> such, extra care should be taken to review code changes made by\n> this option.\n>\n> The latter seems to be of concern. While we want to experiment with the\n> rule, adding it to the in-tree '.clang-format' could affect end-users.\n> Let's only add it to the CI jobs for now. With time, we can evaluate\n> its efficacy and decide if we want to add it to '.clang-format' or\n> retract it entirely. We do so, by adding the existing rules in\n> '.clang-format' and this rule to a temp file outside the working tree,\n> which is then used by 'git clang-format'. This ensures we don't murk\n> with files in-tree.\n>\n> [1]: https://clang.llvm.org/docs/ClangFormatStyleOptions.html#removebracesllvm\n>\n> Signed-off-by: Karthik Nayak \n> ---\n> ci/run-style-check.sh | 19 ++++++++++++++++++-\n> 1 file changed, 18 insertions(+), 1 deletion(-)\n\nHave we done enough experiment by now and don't we want to move it\nto the set of rules in our tree?\n\nHow often do people use \"git clang-format\" before they submit their\nseries these days, by the way?\n\n> diff --git a/ci/run-style-check.sh b/ci/run-style-check.sh\n> index 76dd37d22b..6cd4b1d934 100755\n> --- a/ci/run-style-check.sh\n> +++ b/ci/run-style-check.sh\n> @@ -5,4 +5,21 @@\n> \n> baseCommit=$1\n> \n> -git clang-format --style file --diff --extensions c,h \"$baseCommit\"\n> +# Remove optional braces of control statements (if, else, for, and while)\n> +# according to the LLVM coding style. This avoids braces on simple\n> +# single-statement bodies of statements but keeps braces if one side of\n> +# if/else if/.../else cascade has multi-statement body.\n> +#\n> +# As this rule comes with a warning [1], we want to experiment with it\n> +# before adding it in-tree. since the CI job for the style check is allowed\n> +# to fail, appending the rule here allows us to validate its efficacy.\n> +# While also ensuring that end-users are not affected directly.\n> +#\n> +# [1]: https://clang.llvm.org/docs/ClangFormatStyleOptions.html#removebracesllvm\n> +{\n> +\tcat .clang-format\n> +\techo \"RemoveBracesLLVM: true\"\n> +} >/tmp/clang-format-rules\n> +\n> +git clang-format --style=file:/tmp/clang-format-rules \\\n> +\t--diff --extensions c,h \"$baseCommit\"\n"},{"id":"520418","messageId":"CAOLa=ZSiGxBHiMZbUoRN0nB24YdAWypgyMYMEe-EW9EHtbx7Kw@mail.gmail.com","threadId":"61750","inReplyTo":"xmqq5xgrdan8.fsf@gitster.g","subject":"Re: [PATCH v6 6/6] ci/style-check: add `RemoveBracesLLVM` in CI job","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2025-06-19T20:25:19Z","receivedAt":"2025-06-19T20:25:21Z","isPatch":true,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"Junio C Hamano writes:\n\n> Karthik Nayak writes:\n>\n>> For 'clang-format', setting 'RemoveBracesLLVM' to 'true', adds a check\n>> to ensure we avoid curly braces for single-statement bodies in\n>> conditional blocks.\n>>\n>> However, the option does come with two warnings [1]:\n>>\n>> This option will be renamed and expanded to support other styles.\n>>\n>> and\n>>\n>> Setting this option to true could lead to incorrect code formatting\n>> due to clang-format’s lack of complete semantic information. As\n>> such, extra care should be taken to review code changes made by\n>> this option.\n>>\n>> The latter seems to be of concern. While we want to experiment with the\n>> rule, adding it to the in-tree '.clang-format' could affect end-users.\n>> Let's only add it to the CI jobs for now. With time, we can evaluate\n>> its efficacy and decide if we want to add it to '.clang-format' or\n>> retract it entirely. We do so, by adding the existing rules in\n>> '.clang-format' and this rule to a temp file outside the working tree,\n>> which is then used by 'git clang-format'. This ensures we don't murk\n>> with files in-tree.\n>>\n>> [1]: https://clang.llvm.org/docs/ClangFormatStyleOptions.html#removebracesllvm\n>>\n>> Signed-off-by: Karthik Nayak \n>> ---\n>> ci/run-style-check.sh | 19 ++++++++++++++++++-\n>> 1 file changed, 18 insertions(+), 1 deletion(-)\n>\n> Have we done enough experiment by now and don't we want to move it\n> to the set of rules in our tree?\n>\n\nChristian and I were talking about clang-format today. So great to see\nthat you too were thinking about it. I think this particular rule should\nbe okay to move our tree. For this particular rule, I found one spot it\nfails:\n\n $ ./ci/run-style-check.sh @~1\n diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c\n index 1809539201..341d9eac0d 100644\n --- a/builtin/receive-pack.c\n +++ b/builtin/receive-pack.c\n @@ -1929,12 +1929,11 @@ static void\nexecute_commands_non_atomic(struct command *commands,\n \t\t\tgoto cleanup;\n\n \tfailure:\n -\t\tfor (cmd = commands; cmd; cmd = cmd->next) {\n +\t\tfor (cmd = commands; cmd; cmd = cmd->next)\n \t\t\tif (reported_error)\n \t\t\t\tcmd->error_string = reported_error;\n \t\t\telse if (strmap_contains(&failed_refs, cmd->ref_name))\n \t\t\t\tcmd->error_string = strmap_get(&failed_refs, cmd->ref_name);\n -\t\t}\n\n \tcleanup:\n \t\tref_transaction_free(transaction);\n\nWe generally add brackets in such scenarios, but the style-check\nsuggests to use them instead.\n\n> How often do people use \"git clang-format\" before they submit their\n> series these days, by the way?\n>\n\nTo be honest, I don't think anyone does. As far as I've seen there is\ntoo many false positives currently.\n\n>> diff --git a/ci/run-style-check.sh b/ci/run-style-check.sh\n>> index 76dd37d22b..6cd4b1d934 100755\n>> --- a/ci/run-style-check.sh\n>> +++ b/ci/run-style-check.sh\n>> @@ -5,4 +5,21 @@\n>>\n>> baseCommit=$1\n>>\n>> -git clang-format --style file --diff --extensions c,h \"$baseCommit\"\n>> +# Remove optional braces of control statements (if, else, for, and while)\n>> +# according to the LLVM coding style. This avoids braces on simple\n>> +# single-statement bodies of statements but keeps braces if one side of\n>> +# if/else if/.../else cascade has multi-statement body.\n>> +#\n>> +# As this rule comes with a warning [1], we want to experiment with it\n>> +# before adding it in-tree. since the CI job for the style check is allowed\n>> +# to fail, appending the rule here allows us to validate its efficacy.\n>> +# While also ensuring that end-users are not affected directly.\n>> +#\n>> +# [1]: https://clang.llvm.org/docs/ClangFormatStyleOptions.html#removebracesllvm\n>> +{\n>> +\tcat .clang-format\n>> +\techo \"RemoveBracesLLVM: true\"\n>> +} >/tmp/clang-format-rules\n>> +\n>> +git clang-format --style=file:/tmp/clang-format-rules \\\n>> +\t--diff --extensions c,h \"$baseCommit\"\n"},{"id":"520446","messageId":"xmqqy0tn8elz.fsf@gitster.g","threadId":"61750","inReplyTo":"CAOLa=ZSiGxBHiMZbUoRN0nB24YdAWypgyMYMEe-EW9EHtbx7Kw@mail.gmail.com","subject":"Re: [PATCH v6 6/6] ci/style-check: add `RemoveBracesLLVM` in CI job","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-06-20T00:02:16Z","receivedAt":"2025-06-20T00:02:19Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Karthik Nayak writes:\n\n> \tfailure:\n> -\t\tfor (cmd = commands; cmd; cmd = cmd->next) {\n> +\t\tfor (cmd = commands; cmd; cmd = cmd->next)\n> \t\t\tif (reported_error)\n> \t\t\t\tcmd->error_string = reported_error;\n> \t\t\telse if (strmap_contains(&failed_refs, cmd->ref_name))\n> \t\t\t\tcmd->error_string = strmap_get(&failed_refs, cmd->ref_name);\n> -\t\t}\n>\n> \tcleanup:\n> \t\tref_transaction_free(transaction);\n>\n> We generally add brackets in such scenarios, but the style-check\n> suggests to use them instead.\n\nThe above falls into \"once the code is written\" category I mentioned\nin the other thread. I do not mind the original, and I do not think\nthe suggested change makes it significantly worse, but there is no\nsignificant improvement, either. If the original is in the public\ntree, it is not worth the patch churn to update it to match the\nsuggestion, but if the original is something you are yet to send it\nout to the public consumption, it would be a good idea to take the\nsuggestion before sending it out.\n\n"}]}