feat: Clang --werror fixes & Clang-Format Standardisation

[ninetailedtori]

• .clang-format standardisation
• add clang-format into workflow to enforce this on repo-side.
• meson formatting.
• add clang --werror build fixes.

[ninetailedtori]

I can't compile it rn, but I can't work out where the bug is. Would adore some help with this one, but I think it's my own machine.

Also @misyltoad updated your git submods and wraps to use your new username :3

[pchome]

"My first 'Fuck you, world!' contribution."

Files changed 116 / +38,124 / -31,825

So, all those 90 open PRs must be redone, most distributions (from the list) must recreate their patches, most forks and maybe even Valve themselves too ...

IDK, LGTM!

[ninetailedtori]

I wouldn't say they're that egregious. This is a wrap fallback adding system, and it manages the submodules in a unified method, that links with meson directly. It can always use system directly first, and most distributions like to package their OWN dependencies as opposed to using wrap, see Arch with arch-meson, designed with --wrapmode=nodownload and wraps disabled outside of forced fallback. I can always drop back the git submodules in, and revert this, but the idea was to clean up the meson build which has stayed rather...stagnant for the state of back-compat, and it's not too violent a change. Besides, we wouldn't be including this in a minor change, this would be in a major version change, as is natural with potentially breaking changes.

[oSoMoN]

While consistency and code linting are useful when working on a new code base, this change would be very counterproductive here. I personally use git log and git blame a lot to inspect the history and reconstruct the rationale behind some architectural decisions, or simply to understand when and why a bug/regression was introduced. Such a massive change will only serve to mask actual code changes behind an irrelevant revision, thus making this archaeology work a bit more difficult.

[ninetailedtori]

This is true, yes. For the sake of this being rather annoying when blaming for this, I'm willing to close this ticket for that, especially if that is opinion officially.

And yes, there would be more style changes, I'm willing to modify the clang-format if requested, if this PR even is accepted in draft.

[pchome]

Lets call it a month of .clang-format¹

What I would recommend You is the following²:

1. Revert all the formatting modifications.
2. Achieve almost 100% match with current code format.
3. Do separate PR only for for the .clang-format file.
   This file likely should only be modified by actual maintainers, almost static.
4. No automation at this stage! People can enable "format on typing" in their editors (if it will format only modified code).
5. All further modifications of .clang-format should be banned for contributors.
   Only maintainers should decide what to change.
   Until one exact point in the future where almost all code will follow specified code formatting.

Configuration files examples:

• not able to upload .clang-format, I don't want to hack it's extension, yours is close enough.
  ... oK, here is the diff with yours as a hint: .clang-format.patch
  (close enough, but require more tuning)

• clang-format.json
  Original schema, for local use only³, used by YAML language server(s), completion and hints in the .clang-format file.
  Helps to chose correct options.
  Remember: formatter will silently stop reading config exactly before one wrong line and produce wrong formatted code!

• layers_schema.json
  Modified original Vulkan layer schema. Added layers support.
  For local use only³.
  Just in case, to match the following example. But since this project also have a vulkan layer ...

• settings.json
  This is VSCode settings example for redhat YAML language server (and some other garbage, but left as is.)
  Likely should not be committed. To not interfere with existing user settings.

I could do superseding PR myself, but I use different editor now (Kate btw) and can't check if all this information 100% true now⁴.

Hint: internet says the solution for git blame and indentations⁵ is either rewriting git history, or git blame -w.
So we prefer do not rewrite git history.

Footnotes

1. It's a spam, don't click it: What next pchome/gamescope-lite#3 ↩

2. Remember, I 'm a random guy from the internet, not affiliated with Valve. Maybe I contributed to much to their projects, but I was a moron to push my interests. So now their developers hate me. So you on your own, feel free to accept or ignore my advises. ↩

3. About .vscode/ part. ↩ ↩²

4. IDK, my preference in the middle: bloat the project with another big file, use local copy, let software download this from internet on demand. Auto downloads sometimes ship malware to you, if the host not in the mood. ↩

5. ... tab vs paces ↩