Fix clang-tidy warnings to make it actually useful#1048
Merged
Conversation
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When we first added clang-tidy to Cesium Native, we left the warnings as merely informational, because there were too many of them to fix at the moment. Unfortunately, this leaves clang-tidy as an afterthought, because I don't imagine many of us are poking through the CI logs to see if our changes produced any new clang-tidy warnings when there's already hundreds of existing warnings. This change attempts to fix this: resolve the existing warnings, enable any useful checks that weren't already enabled, and treat the warnings as errors so we'll notice them.
Changes in this PR:
ExcludeHeaderFilterRegexconfig option we're using to removeezvcpkgheaders from the build.bugproneclang-tidy check has been enabled, with the following exceptions:bugprone-exception-escape, as fixing this is already a pending issue (Functions are declared noexcept, even though they may throw #348).bugprone-misplaced-widening-cast, as it results in extremely verbose lines (likesize_t pixels = static_cast<size_t>(image.width) * static_cast<size_t>(image.height) * static_cast<size_t>(image.channels)instead of justsize_t pixels = static_cast<size_t>(image.width * image.height * image.channels).bugprone-unhandled-exception-at-new, as this is both part of Functions are declared noexcept, even though they may throw #348, and also extremely nitpicky - I don't think we need to wrap every call tonewin atry...catch.modernizeandmiscchecks have been enabled, where they didn't conflict with the style guide or produce way too many changes for one PR. The following I decided were too much for just this PR, but they can be automatically applied at a later date usingclang-tidy-fix:misc-const-correctnessdetects every variable that could be declaredconst.modernize-loop-convertuses range-based for loops instead of manually advancing the iterator.modernize-type-traitschangestraits<...>::typeandtraits<..>::valuetotraits_t<...>andtraits_v<...>modernize-use-constraintsreplacesstd::enable_ifwith C++20requiresclauses.modernize-use-usingreplacestypedefwithusing.modernize-return-braced-init-listreplaces statements likereturn glm::dvec2(0.5, 0.5);withreturn {0.5, 0.5};modernize-use-designated-initializerswould mean adding.field=to initializer statements, like{.x = 0.5, .y = 0.5}, which would prevent bugs when changing the order of fields.performancechecks have been enabled, with the exception ofperformance-enum-size, as I felt that saving three bytes by defining an enum withint8_tinstead of the defaultint32_tdidn't seem like it was worth the change.readabilitychecks are mostly style guide-related, but might be worth looking into.readability-else-after-returnandreadability-braces-around-statementsseem like they could be good to add.Fixes #203