RFC: Precise lint silencing #168
Conversation
|
|
||
| We will add the ability to disable lints on a specific line or range of lines through the use of special comments. | ||
|
|
||
| One method will be `--!nolint-next-line LINTNAME`. This will silence the specific lint for the next line of source code (not comments/whitespace) |
There was a problem hiding this comment.
If the next line does not actually contain the disabled lint warning, should we emit a static warning that "this nolint is redundant"?
Keeps comment purpose clear. As mentioned in your original motivation, if we end up removing the deprecated usage of "bar", we know we should clean up the comment
| There is no shortage of prior design to look at for linting, and we are for choice on alternatives. | ||
|
|
||
| ### AST Aware Scopes | ||
| Rust and selene operate on a code's AST rather than its text. In other words... |
There was a problem hiding this comment.
I'm a fan of this approach. Aside from the fact that Selene and Lute do this (meaning that folks will be used to this style of annotation) it also makes it easier to apply to blocks of code, as you've demonstrated. Of course, we could just have both AST-specific and line-specific suppression
There was a problem hiding this comment.
Does lute do this? I was asked about it under the impression it wouldn't, but was unsure if they were convinced the other way around :)
If lute does it then I will reshape this up, I do like it I just figured it was controversial
There was a problem hiding this comment.
Yeah lute does do this, there's just some ambiguity as to whether we should only suppress violations which are fully contained in the proceeding AST node or whether we should suppress violations which have any overlap with the proceeding AST node (Lute and Selene do the latter) as in the following example of an unsuccessful swap:
--!no-lint-next-node
a = b
b = a3 participants
Rendered
This proposes the ability to silence lints across a line or range of lines.