[no squash] Check for indent spaces

[sfence]

Continue of #14983

This PR checks the indent in C/C++ and Lua files if somewhere spaces are used.
It ignores spaces in multiline comments.

To do

This PR is a Ready for Review

• Fix found bad indents

How to test

Run grep commands and Python script over the test file:
test_C_file.txt

[cx384]

I'm not sure about disallowing less than 4 spaces after a tab, i.e. in my opinion grep -n -P '^\s*([ ]\t|[ ]{4})' would be strict enough. Also, I think this shouldn't get too complex, a vague check should be sufficient, otherwise you could directly use a code formatter like GNU indent or similar.
But let's wait for opinions from other code devs.

[Desour]

There's a surprisingly high amount of space indentation.

But also half of the changes are getting rid of valid alignment. Alignment is too useful for readability to forbid imo. Which is why I'm against this PR in its current state. 👎

Something more conservative could maybe work, i.e.:

• No tabs after any non-tab character.
• If a line starts with k tabs, and the next line has k' < k tabs, there must be no space character before any non-whitespace character.
  (Rationale: Alignment never takes away tabs. Hence this indicates space being used for indentation.)

[sfence]

@cx384 I tried to catch only more than 3 spaces after the tab, but it still does not work well.

So I used the less restrictive solution mentioned by @Desour.

Some badly used spaces are not recognized now.

Do you think this solution is better?

[cx384]

Otherwise, I'm fine with the indentions, but I haven't looked at the script yet.

[Desour]

Could you please add some comments, so that for example one doesn't have to read through the whole preprocess script to find out what it does?

So, what this disallows now is spaces after tabs and multiline comments that start in the same line that another multiline comment ends?
Why do we need latter? And wouldn't former still break alignment after indentation?

[sfence]

Could you please add some comments, so that for example one doesn't have to read through the whole preprocess script to find out what it does?

I added some comments, I hope it helps.

So, what this disallows now is spaces after tabs and multiline comments that start in the same line that another multiline comment ends? Why do we need latter? And wouldn't former still break alignment after indentation?

Now spaces at the beginning of the line and spaces after tabs only if the indent is smaller than on the previous line.
In other cases, spaces after the indent is ignored.

The multiline comments part is questionable.
The idea is to detect something like this:

	{
		soem code
		/*
 wtf
  wtf
		*/
	}

[Desour]

Thanks!

Python script is a bit hard to follow.

Whitespace changes look mostly good.

[sfence]

@Desour Everything should be done now.

[Desour]

(See also unresolved older comments.)

It's just a CI script, so it doesn't need to be perfect, right? I don't want to be overly pedantic.

[sfence]

@Desour Should be fixed now.

[Desour]

Looks fine from what I can tell.

One trivial thing I noticed: The python script is not marked executable. The other files in util/ci are.

Btw. add [no squash] to your PR title if you want no squashing.

[Zughy]

@sfence rebase needed

[Desour]

(My approval holds. You can merge with self-approval, btw.)