-
Notifications
You must be signed in to change notification settings - Fork 214
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
line length rule: add a parameter to check comments #972
base: master
Are you sure you want to change the base?
Conversation
Codecov ReportPatch coverage:
📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more Additional details and impacted files@@ Coverage Diff @@
## master #972 +/- ##
=======================================
Coverage 93.13% 93.14%
=======================================
Files 355 355
Lines 25843 25882 +39
=======================================
+ Hits 24069 24107 +38
- Misses 1774 1775 +1
☔ View full report in Codecov by Sentry. |
f8f3f18
to
6a3cbee
Compare
Yes, I think for the user's point of view a parameter I tihnk diffentiating between end-of-line and block comments w.r.t warning or not is probably too much user-confusing option than worth it (and I wouldn't see why it should make a difference). Same for different length of comment vs. non-comment. All of them should stay within the same line length. |
6a3cbee
to
544cc8c
Compare
@hzeller Thank you for your feedback. The parameter is now named |
// Recall that token_range is *unfiltered* and may contain non-essential | ||
// whitespace 'tokens'. | ||
// This shrinks the range if there are newline tokens in front/back |
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.
Can you explain why we need this newline checking at all ? Aren't we going through line by line anyway, so we wouldn't see the newlines ? Or is it because block comments come as one big whitespace token, possibly spanning multiple lines ?
The intention here needs to be explained in a comment, and possibly the block here put into a well-named function.
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've moved the part which extends token range backwards, seeking for meaningful tokens, to a new function.
Explaining this made me realize that previously there were some excessive operations for shrinking the range, I've fixed it to do what's actually needed.
I've added comments about what the functions do, but I'll also leave some information here with an example.
The rule analyzes text line by line. The function TokenRangeOnLine
which is used to retrieve tokens for that line, returns the tokens that begin on this line, not the tokens that begin somewhere earlier and continue in that line. As a result, in order to handle a long line of a token that started somewhere in preceding lines, we need to move the begin
iterator backwards.
Like in this example:
/* this is a block comment
some text
some text
some text
some very long line, let's assume the limit is 40 characters
*/
For the long line (6th), the only token retrieved by TokenRangeOnLine
would be a newline,
because TK_COMMENT_BLOCK
belongs to the 1st line (where the comment block begins).
After extending the range backwards searching for a meaningful token (to the 1st line),
even more newline tokens would be present in the back of the range.
So, when processing the 6th line, the code seeks back to the 1st line (TK_COMMENT_BLOCK is found)
and truncates the range to skip all the newlines, then AllowLongLineException
is called with that single token.
544cc8c
to
0275f8d
Compare
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 think this looks good, but we should probably move the range extension thing into its separate function, which then can 'house' all the necessary explanations why it is needed, but at the actual call-site, it is compact to read.
return make_range(token_range.begin(), last_non_newline); | ||
} | ||
|
||
static verible::TokenRange SeekTokensBackwards( |
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.
this should probably be named to what it does: SeekLastNonNewlineToken()
or something
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 idea, changed it
// Recall that token_range is *unfiltered* and may contain non-essential | ||
// whitespace 'tokens'. | ||
// This shrinks the range if there are leading newline tokens | ||
token_range = StripNewlineTokens(token_range); | ||
if (token_range.begin() == token_range.end()) { |
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.
Maybe it makes sense to put this in a separate function with a good name that describes what this token-range adjustment is doing.
That makes this code here compact and allows for the necessary explanation inside the function that deals just with this part.
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.
Done
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.
What happened to this PR, looks like we were close ?
@wsipak do you still have the branch to finish ?
{ | ||
{"length", absl::StrCat(kDefaultLineLength), | ||
"Desired line length"}, | ||
{"check_comments", "false", "Check comments."}, |
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.
Did we previously check the length in comments ? Then maybe this should default to 'true'.
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.
Changed it
e40aef7
to
5ee7eeb
Compare
Signed-off-by: Jan Bylicki <[email protected]>
Signed-off-by: Jan Bylicki <[email protected]>
Clang had issued deducing the arguments for reverse_iterator, so typing info had to be added Signed-off-by: Jan Bylicki <[email protected]>
5ee7eeb
to
3bd46d0
Compare
std::reverse_iterator<TokenSequence::const_iterator>(token_range.begin()), | ||
std::reverse_iterator<TokenSequence::const_iterator>(text_begin), | ||
[](const TokenInfo& t) { return t.token_enum() != TK_NEWLINE; }); | ||
|
||
if (found_it != | ||
std::reverse_iterator<TokenSequence::const_iterator>(text_begin)) { |
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.
Do we need explicit params for the reverse_iterator
s here? (possibly use cbegin()
if you're running into some fun template errors)
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.
cbegin
is not implemented and not having parameters has caused problems (and warnings in a compilation with -Werror
set) with parameter deduction in Clang:
| verilog/analysis/checkers/line_length_rule.cc:192:7: error: 'reverse_iterator' may not intend to support class template argument deduction [-Werror,-Wctad-maybe-unsupported]
12:23:05 | std::reverse_iterator(token_range.begin()),
12:23:05 | ^
12:23:05 | /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/stl_iterator.h:132:11: note: add a deduction guide to suppress this warning
12:23:05 | class reverse_iterator
12:23:05 | ^
12:23:05 | verilog/analysis/checkers/line_length_rule.cc:193:7: error: 'reverse_iterator' may not intend to support class template argument deduction [-Werror,-Wctad-maybe-unsupported]
12:23:05 | std::reverse_iterator(text_begin),
12:23:05 | ^
12:23:05 | /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/stl_iterator.h:132:11: note: add a deduction guide to suppress this warning
12:23:05 | class reverse_iterator
12:23:05 | ^
12:23:05 | verilog/analysis/checkers/line_length_rule.cc:196:19: error: 'reverse_iterator' may not intend to support class template argument deduction [-Werror,-Wctad-maybe-unsupported]
12:23:05 | if (found_it != std::reverse_iterator(text_begin)) {
12:23:05 | ^
12:23:05 | /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/stl_iterator.h:132:11: note: add a deduction guide to suppress this warning
12:23:05 | class reverse_iterator
// whitespace 'tokens'. | ||
// This shrinks the range if there are leading newline tokens | ||
*orig_range = StripNewlineTokens(*orig_range); | ||
if (orig_range->begin() == orig_range->end()) { |
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.
if (orig_range->begin() == orig_range->end()) { | |
if (!std::empty(*orig_range)) return *orig_range; |
Maybe something like this? Then just return StripNewlineTokens(...)
in the other branch.
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.
It does not implement enough methods to call either std::empty
or TokenRange.empty()
and your proposal (along with variations I have tried) does not compile. The implementation is at common/util/iterator_range.h
.
This addresses #941
There's a new parameter
allow_comments
ignore_comments
.When it's set to
false
, exceeding the line length limit in comments won't be forgiven.The default value is
true
, so that it doesn't change the way it works by default now.It works with single line comments and block comments, but those are not distinguished in configuration right now (Should we consider them separately?).
Also, would it be preferred to rename the parameter to something like
check_comments
so that it has the opposite meaning, and set tofalse
would result in not linting comments?Would it be better to have two separate values of length limit for non-comment and comment lines?
This probably could be addressed and implemented in another PR, but I'm noting it here as a thing to consider.