Age | Commit message (Collapse) | Author |
|
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.
|
|
See rBb9cd2f4531ca670c196b0b14b1359d0f375103c2 for more info.
|
|
This check does not work when gtests are enabled yet.
See rBb9cd2f4531ca670c196b0b14b1359d0f375103c2 for more details.
|
|
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
|
|
More detailed explanation why it is a preferred way of coding
nowadays can be found at
https://clang.llvm.org/extra/clang-tidy/checks/modernize-avoid-bind.html
Resolves modernize-avoid-bind Clang-Tidy warning.
Differential Revision: https://developer.blender.org/D10320
|
|
Resolves modernize-use-transparent-functors Clang-Tidy warning.
Differential Revision: https://developer.blender.org/D10323
|
|
Using assignment syntax as we don't use `{}` initialization yet.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D9501
|
|
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.
|
|
Forgot this in rB168909d9741.
No functional changes.
|
|
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
|
|
|
|
Replace `NULL` with `nullptr` in C++ code.
No functional changes.
|
|
|
|
|
|
|
|
|
|
Gives an idea of which warnings are affecting Blender code base.
|
|
|
|
No functional change.
|
|
No functional change.
|
|
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
|
|
No functional changes
|
|
No expected functional changes.
|
|
No functional changes.
|
|
Should cause no noticeable difference.
|
|
No functional changes. No changes except enabling the rule, even.
|
|
No functional changes.
|
|
No functional changes.
|
|
No functional changes.
|
|
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.
|
|
I added a single `NOLINT` exception with explanation.
No functional changes.
|
|
No functional changes because no code changed.
|
|
No functional changes because no code changed.
|
|
No functional changes.
|
|
Enabling it and doing a full rebuild didn't cause any warnings, so nothing
else to do here.
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
|
|
Clang Tidy reported a couple of false positives. I disabled
those `NOLINTNEXTLINE`.
Differential Revision: https://developer.blender.org/D8199
|
|
|
|
|
|
|
|
|
|
Looks like we have no assertions with side effects.
|
|
It was called `inverted` in the header.
|
|
Also enable it in the configuration.
|
|
|