Proposed graceful handling of noqa by L016 (#4248) #4424
Conversation
Pull Request Test Coverage Report for Build 4276411030
💛 - Coveralls |
Codecov ReportBase: 100.00% // Head: 100.00% // No change to project coverage 👍
Additional details and impacted files@@ Coverage Diff @@
## main #4424 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 206 206
Lines 15391 15397 +6
=========================================
+ Hits 15391 15397 +6
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
| ) | ||
|
|
||
| # Sense check a few edge cases: | ||
| if "noqa" in line_buffer[-1].segments[-1].raw: |
There was a problem hiding this comment.
Approved, but is this an ideal way to check noqa? Wouldn't this also fail on SELECT * FROM myschema.mynoqatable? Would we not want to verify type as a Comment?
There was a problem hiding this comment.
ah - good thought - but we've just confirmed that it's a comment on line 1659, so I think this is safe here.
This is a fairly blunt (but IMHO, safe) treatment of
-- noqacomments by L016. This resolves #4248.We already detect trailing inline comments in L016 so that we can handle them differently. This explicitly handles two cases as unfixable:
noqacomments.Effectively - if a line is too long with a
noqa, then we won't touch it - we will still report the error. The code diff looks worse than it is, just because I've added someifstatements and indented pre-existing code by another step.