-
Notifications
You must be signed in to change notification settings - Fork 916
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
Fix Doxygen warnings in table header files #10964
Fix Doxygen warnings in table header files #10964
Conversation
* @param lhs first element | ||
* @param rhs second element | ||
* @return Indicates the relationship between the elements in | ||
* the `lhs` and `rhs` columns. |
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.
Seems this was accidentally removed?
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. doxygen throws warning that params are documented twice because of SFINAE. These arguments are documented in other definition.
warning: argument 'lhs' from the argument list of cudf::relational_compare has multiple @param documentation sections
so, this params doc is removed.
Both @brief
will show in the documentation. https://docs.rapids.ai/api/libcudf/nightly/namespacecudf.html#a9b480332cf7484e8532a2d6f2c711a35
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.
Hmm that seems problematic. Given our extensive use of SFINAE, we should probably standardize how we choose to document that. Since as @davidwendt mentioned that most readers of our docstrings are probably developers. It's especially odd here because the null_compare
is in between the two overloads, so as a developer I wouldn't immediately know where to look for the docs. I would say for consistency that it's more important that all SFINAE overloads are documented, so maybe we need to tell doxygen to ignore certain warnings? Alternatively, if we could guarantee that all SFINAE overloads were next to each other we could standardize on documenting all overloads on just the first instance, but that's hard to enforce.
I don't know how anyone else feels, I'm sure that some people like @harrism would have opinions as well.
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.
So, honestly, any functions that requires SFINAE should probably not be in a public header. That is, I cannot picture a non-internal libcudf API that would have SFINAE semantics. And there has already been discussion on moving the row-operators into the detail
namespace. In general, I would not spend too much time on trying to get doxygen working with SFINAE'd functions.
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.
That is a fair point. I guess the question then would be, should doxygen be linting those at all? It's a bit tricky right now because we also use detail
to hold the stream versions of public APIs, and those may eventually become public, but in the longer run we probably want to tell doxygen either not to lint those files or to at least relax some requirements.
Anyway, I'm fine with this PR not resolving that question.
@@ -899,6 +928,10 @@ struct preprocessed_table { | |||
std::vector<rmm::device_buffer> _null_buffers; | |||
}; | |||
|
|||
/** | |||
* @brief Comparator for performing equality comparisons between two rows of the same table. | |||
* |
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.
Does doxygen style require this extra line after the brief even when there are no additional lines afterwards, or is that something that you are doing? It seems like an unnecessary extra line to me, but maybe it's just what we need to 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.
doxygen does not require it. The vscode doxygen extension inserts this line by default.
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 see. I think I saw a few other places where there were param/return docs after the brief, and there was no space in between. It would be nice to make those consistent, but if doxygen doesn't require it then I wouldn't waste time on that (except when adding new lines) until after these PRs are all set.
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.
AFAIK, new lines are for readability. I would prefer to leave it as the doxygen extension generates.
it does not affect generated docs.
I will create a single PR with other changes like removing dots at end of @param
, order of https://github.com/rapidsai/cudf/blob/branch-22.06/cpp/docs/DOCUMENTATION.md#function-parameters , //!<
to ///<
.
do you suggest to add "compulsory newline after @brief
" in that PR?
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 yes, I like the newline after brief. Not only is it easier to read, it makes it very obvious when the brief is not actually very brief if there's an extremely long line.
Co-authored-by: Vyas Ramasubramani <[email protected]> Co-authored-by: David Wendt <[email protected]>
Codecov Report
@@ Coverage Diff @@
## branch-22.08 #10964 +/- ##
===============================================
Coverage ? 86.32%
===============================================
Files ? 144
Lines ? 22696
Branches ? 0
===============================================
Hits ? 19593
Misses ? 3103
Partials ? 0 Continue to review full report at Codecov.
|
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 mostly happy, but would like the discussion about SFINAE overloads resolved before I approve.
@@ -899,6 +928,10 @@ struct preprocessed_table { | |||
std::vector<rmm::device_buffer> _null_buffers; | |||
}; | |||
|
|||
/** | |||
* @brief Comparator for performing equality comparisons between two rows of the same table. | |||
* |
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 yes, I like the newline after brief. Not only is it easier to read, it makes it very obvious when the brief is not actually very brief if there's an extremely long line.
* @param lhs first element | ||
* @param rhs second element | ||
* @return Indicates the relationship between the elements in | ||
* the `lhs` and `rhs` columns. |
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.
Hmm that seems problematic. Given our extensive use of SFINAE, we should probably standardize how we choose to document that. Since as @davidwendt mentioned that most readers of our docstrings are probably developers. It's especially odd here because the null_compare
is in between the two overloads, so as a developer I wouldn't immediately know where to look for the docs. I would say for consistency that it's more important that all SFINAE overloads are documented, so maybe we need to tell doxygen to ignore certain warnings? Alternatively, if we could guarantee that all SFINAE overloads were next to each other we could standardize on documenting all overloads on just the first instance, but that's hard to enforce.
I don't know how anyone else feels, I'm sure that some people like @harrism would have opinions as well.
Co-authored-by: David Wendt <[email protected]>
Co-authored-by: David Wendt <[email protected]>
Co-authored-by: David Wendt <[email protected]>
@gpucibot merge |
Fixes parts of #9373
added missing documentation to fix doxygen warnings in table headers
ignores doc generation for
strong_index_comparator_adapter
fixes 166 warnings.