Also, I normally build with clang, but I set the default to gcc because clang emits a huge number of warnings:

../include/Xprintf.h:58:1: warning: '__format__' attribute argument not supported: gnu_printf [-Wignored-attributes]
   58 | _X_ATTRIBUTE_VPRINTF(2, 0);
      | ^
../include/os.h:75:26: note: expanded from macro '_X_ATTRIBUTE_VPRINTF'
   75 |           __attribute__((__format__(gnu_printf, fmt, firstarg)))
      |                          ^
1 warning generated.

Whoops, I keep forgetting to add that commit description 😅

I'm not using clang, and I'm not familiar with it, so I'll assume this is like any other linter.

If this only has warnings that actually prevent bugs, then go for it.
If this is a coding-style enforcer, e.g. while(...); vs while(...){}, then I'd rather not see it.
I also want it to have a very low (preferably none) level of false-positives,
and not make writing code unbearable, even if it can potentially prevent bugs (don't turn C into rust).
Will this run alongside regular CI?
Does it have something to silence warnings, like (void) and (void)! casts for gcc?

@notbabaisyou ping

I'm not using clang, and I'm not familiar with it, so I'll assume this is like any other linter.

If this only has warnings that actually prevent bugs, then go for it. If this is a coding-style enforcer, e.g. while(...); vs while(...){}, then I'd rather not see it. I also want it to have a very low (preferably none) level of false-positives, and not make writing code unbearable, even if it can potentially prevent bugs (don't turn C into rust). Will this run alongside regular CI? Does it have something to silence warnings, like (void) and (void)! casts for gcc?

Yep, clang-tidy is a linter/static analysis tool and has plenty of options for whether you'd prefer it to enforce a style or just look for bugs like undefined behavior, division by zero, null pointer deref, etc. It can also be bypassed with a // NOLINT comment.

This would hopefully be a start to getting it integrated in a GitHub actions workflow like some other C and C++ projects use.

As for the other files, editorconfig is simply a linter config and the clangd language server is the plumbing to bring warnings, errors, and code completion into VSCode, vim, or your other IDE of choice. For example, there are some "bugprone" warnings emitted in dix/events.c:

I can go ahead and convert this PR to draft though, there are probably some options to discuss and pare down on the configs to not be overbearing at first.

Alright, I've tried to narrow clang-tidy down to bugs only and not go crazy on style. I also added a shell script that can call clang-tidy on a file or directory and print the number of warnings emitted.