-
Notifications
You must be signed in to change notification settings - Fork 908
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Address all remaining clang-tidy errors #16956
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Personally I don't like the idea of removing the name class when constructing an object. Having the name class makes thing looks more obvious and less error prone. In particular, instead of having this:
class_name func() {
// ... very long code
return {a, b, c,...};
}
I prefer to have this:
class_name func() {
// ... very long code
return class_name{a, b, c,...};
}
I agree with this as well but will abide by a majority vote. |
@@ -228,7 +228,8 @@ class parquet_field_string : public parquet_field { | |||
* @return True if field types mismatch or if the process of reading a | |||
* string fails | |||
*/ | |||
struct parquet_field_string_list : public parquet_field_list<std::string, FieldType::BINARY> { | |||
class parquet_field_string_list : public parquet_field_list<std::string, FieldType::BINARY> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ELI5: Why was this change required? Isn't the old version a valid equivalent?
Is it because of (the equivalent of) the Google Style Guide stating that structs
need to be POD/passive objects?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, this was necessary because the header file declares this object as a class instead of a struct. We could equivalently have changed the header to use struct instead, but the two should be aligned because under certain compilers (Windows) the results could be ABI-incompatible. See https://clang.llvm.org/docs/DiagnosticsReference.html#wmismatched-tags
[&lhs_data = lhs_data, | ||
&lhs_mask = lhs_mask, | ||
&rhs_data = rhs_data, | ||
&rhs_mask = rhs_mask, | ||
&result_mask = result_mask](auto i) -> TypeOut { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I've understood the need for this either. Why is repeating the variable name here preferred?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Structure binding cannot be captured automatically so we have to use this trick.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Structure binding cannot be captured automatically...
In which case then, how was it working before? The definitions of lhs_data
etc. haven't changed, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We were getting lucky because gcc implements this as an extension even when only compiling under C++17, but other compilers will not be so friendly: https://godbolt.org/z/9fnq6Ex84.
@@ -39,19 +39,19 @@ using cudf::device_span; | |||
*/ | |||
template <typename Decompressor> | |||
struct DecompressTest : public cudf::test::BaseFixture { | |||
std::vector<uint8_t> vector_from_string(char const* str) const | |||
[[nodiscard]] std::vector<uint8_t> vector_from_string(std::string const str) const |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: Why not std::string const& str
? It's not like str
is being std::move()
-ed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good question. I can make this change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A couple of nits and questions. But this LGTM.
To me it's a little bit like using I think I'd prefer the explicit type for clarity, but I'll follow what the team decides. |
I agree with the auto analogy. Even more than Mithun's example, this is the exact mirror of using an Personally I like the change, but I don't feel strongly enough to sway the team if other generally prefer the status quo. It seems like the vote is currently 3-1 so I'll go ahead and revert. I'll need to go through and manually revert the changes after removing the rule since these changes are not autofixes, so I'll come back to this tomorrow. |
@bdice @shrshi @vuule @PointKernel @karthikeyann @mhaseeb123 @kingcrimsontianyu @lamarr |
I like using I do understand the annoyance with long functions that return "auto", so I'm not really pushing for such |
I prefer the explicit return type for better clarity and readability as well. Also, given that many of our unary constructors are not marked as explicit but should be, using explicit return types is required in such cases. |
I prefer I am fine with using |
I think that is enough votes that I will go ahead and revert this change and remove the relevant clang-tidy rule. |
I have reverted the change. @davidwendt could you take another look and see if there's anything else that stands out? This PR has two approvals but given the discussion and subsequent changes I'd like another pair of eyes on it. |
With the config removed, can we use braces instead of parenthesis in the constructor call? I.e., instead of |
We can, but we have to do it manually. You can't have clang-tidy do that automatically for you. As such, I would prefer not to make such changes in this PR because they're a stylistic improvement that's out of scope of what clang-tidy can do. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approved CMake changes
/merge |
Description
With this set of changes I get a clean run of clang-tidy (with one caveat that I'll explain in the follow-up PR to add clang-tidy to pre-commit/CI).
Checklist