Lint configuration source annotations

[pq]

Ideally, disabling lints will piggyback on a general method to disable warnings via source annotations in the analyzer. Pending resolution there, and perhaps to encourage it, this ticket is meant to kick off the conversation specific to disabling linting (but really about configuring the analyzer in general).

By way of a motivational example, take the following.

class BoxBad {
  var _contents;
  get contents => _contents;
}

which triggers a lint suggesting we should prefer a public final field to a getter in this instance. Suppose, just this once, we'd like to suppress that warning. How would that look?

Some prior art to get the juices flowing.

eslint

/*eslint-disable no-alert, no-console */
alert('foo');
console.log('bar');
/*eslint-enable no-alert */

alert('foo'); // eslint-disable-line

jscs

// jscs:disable requireCurlyBraces
if (x) y(); // all errors from requireCurlyBraces on this line will be ignored
// jscs:enable requireCurlyBraces
if (z) a(); // all errors, including from requireCurlyBraces, on this line will be reported

jshint

/* jshint undef: true, unused: true */

// Code here will be linted with JSHint.
/* jshint ignore:start */
// Code here will be ignored by JSHint.
/* jshint ignore:end */

ignoreThis(); // jshint ignore:line

pylint

# pylint: disable=unused-argument
print self\
    + "foo"

RubyCop:

# rubocop:disable Metrics/LineLength, Style/StringLiterals
[...]

for x in (0..19) # rubocop:disable Style/AvoidFor

stylecop

[SuppressMessage("StyleCop.CSharp.DocumentationRules", "SA1600:ElementsMustBeDocumented", Justification = "Reviewed. Suppression is OK here.")] 
public class MyUndocumentedClass 
{ 
    public void MyUndocumentedMethod 
    { 
    } 
}

tslint

/* tslint:disable */
/* tslint:disable:rule1 rule2 rule3... */ 
[…]

[zoechi]

What functionality should it provide?

• disable for the entire library when comment/annotation is on the library declaration
• disable for a part file
• disable for an entire class/function/method
• disable for the following expression
• disable-start/disable-end for an arbitrary range of lines
• inside an expression at the exact position of a warning/hint/lint

If annotations are used I guess dart2js and the VM need to be modified to ignore these annotations
Annotations need a dependency/import (which wouldn't hurt much when imports were added automatically).
Is it possible to use annotations for disable-start/end for an arbitrary range of lines? I guess not.
Annotations would provide autocompletion out of the box.

I would prefer a less verbose form than disable like

// lint- rule1, rule2
// lint+ rule1, rule2
/* lint- rule1, rule2 */
/* lint+ rule1, rule2 */

[pq]

For reference, the issue tracking a request to add language support for a proper annotation is here: https://code.google.com/p/dart/issues/detail?id=12490.

[pq]

@zoechi : all things being equal, I totally agree. Those verbose comments make me uneasy. Without thinking about it too hard, I wish we could do something as simple as:

//no_lint: unnecessary_getter

or, if we need to qualify by group:

//no_lint: style/unnecessary_getter

I'm with you on scoping. Failing an annotation proper, I'd like our support to emulate one and allow for addressing classes, members, statements, etc.

[zoechi]

With groups I would prefer

// ignore: style/unnecessary_getter
or
// ignore-style: unnecessary_getter

[pq]

@lukechurch : care to comment?

[pq]

@zoechi : I'm with you and strongly leaning towards the simplest proposal:

//ignore: unnecessary_getter

or in case it needs qualifying:

//ignore: style/unnecessary_getter

[zoechi]

@pq What would you like for the end of an arbitrary block (in case this will be supported)?

// ignore: unnecessary_getter
some code
// ignore-end: unnecessary_getter

[pq]

Closing. Suppressing lints is supported by the analyzer proper:

https://www.dartlang.org/guides/language/analysis-options#excluding-lines-within-a-file