* bugprone-signed-char-misuse: Not relevant because of -funsigned-char.
* bugprone-switch-missing-default-case: Not necessarily better to add default.
* bugprone-multi-level-implicit-pointer-conversion: Common pattern.
* bugprone-assignment-in-if-condition: Common pattern, not against guidelines.
Pull Request: https://projects.blender.org/blender/blender/pulls/133734
These patterns are very common throughout the Blender codebase, which makes
the clang-tidy output and using clangd in an IDE quite noisy. They were introduced
in LLVM version 18 and 19.
* readability-math-missing-parentheses
* readability-avoid-nested-conditional-operator
* readability-enum-initial-value
* readability-avoid-unconditional-preprocessor-if
Pull Request: https://projects.blender.org/blender/blender/pulls/132462
This commit improves macOS Objective-C code linting and developer
experience by enabling clang-tidy Objective-C checks. The full list
of objc-* checks can be found here:
https://clang.llvm.org/extra/clang-tidy/checks/list.html
As these checks are pretty simple and non-invasive, they have all
been kept enabled. Currently, enabling this series of checks does
not introduce any new clang-tidy warnings in the current Objective-C
code.
Pull Request: https://projects.blender.org/blender/blender/pulls/128334
After some internal discussion it was decided that we should ignore name
variable length tidy warnings. Otherwise we would have warnings for
every variable that is under three characters long.
Additionally we will also ignore any warnings when including non header
files as the Unity library in our build system uses this excessively
This removes a lot of unnecessary code that is generated by
the compiler automatically.
In very few cases, a defaulted destructor in a .cc file is
still necessary, because of forward declarations in the header.
I removed some defaulted virtual destructors, because they are not
necessary, when the parent class has a virtual destructor already.
Defaulted constructors are only necessary when there is another
constructor, but the class should still be default constructible.
Differential Revision: https://developer.blender.org/D10911
This makes regular development more pleasant, because one does not have
to fix unrelated clang tidy mistakes when one is in the middle of something.
Before this change, I would usually turn clang-tidy off entirely, but then
forget to turn it on again.
This change has been agreed on by Sergey as well.
Resolves modernize-raw-string-literal Clang-Tidy warning
The way warning works is it suggests to use raw literal when
overhead of having escape characters is higher than the overhead
of having raw literal syntax (talking about code size overhead).
This means that the warning will not trigger for "foo\"bar".
Differential Revision: https://developer.blender.org/D10322
Replace `typedef` with `using` in C++ code.
In the case of `typedef struct SomeName { ... } SomeName;` I removed the
`typedef` altogether, as this is unnecessary in C++. Such cases have been
rewritten to `struct SomeName { ... };`
No functional changes.
Remove redundant call to `ofstream::close()` from `~PSStrokeRenderer`
and `~TextStrokeRenderer`. ofstream will be destructed automatically.
- For `~Depsgraph`, `std::function`'s constructor can throw.
- Passing throwing statements in the lambda will not be detected by
clang-tidy.
Fix these issues by using lambda as function argument.
Reviewed By: sergey, sybren
Differential Revision: https://developer.blender.org/D9497
Until it is decided whether to work on, or ignore these
warning, disable them. See T78535
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D9281
Remove redundantly nested `#if` and `#ifdef` statements.
One nested `#if 0` block was left untouched, as it's in particle code
that's no longer maintained. Furthermore, that block also has some
explanation as to the differences between the enabled & disabled parts.
One nested `#if 0` construct was completely removed, leaving only the
actually used bit of code. There was no explanation as to the usefulness
of the disabled code, and it hasn't been touched in years.
No functional changes.
Enable Clang-Tidy's `readability-function-size` rule and add a few
`NOLINT` markers to explicitly silence warnings for three functions.
These functions are huge and would IMO benefit from splitting up, but
are hard to without intimate knowledge of the code.
At least by enabling the rule, we can start tweaking the values and
refactoring other functions that bubble up as being too long/complex.
No functional changes.
This addresses warnings from Clang-Tidy's `readability-else-after-return`
rule. This should be the final commit of the series of commits that
addresses this particular rule.
No functional changes.
Those checks have been added to clang tidy within the last year.
They fail when I use a clang tidy version I built from source.
Reviewers: sergey
Differential Revision: https://developer.blender.org/D8302
