See also T13588.

This is relatively ripe for implementation now that inline comments support suggested edits.

I think lint could reasonably emit two warnings about this:

I believe that covers all cases of this.

However, the existence of the original code might point at a bug in the "Variable Reused as Iterator" lint check: I would expect it to have prevented the original code in the first place.

Changes in T13209 make this the only mode.

This doesn't seem actionable and is likely mooted by T13098.

This feature has been removed in experimental and wilds, and I don't currently expect to restore it.

(Future me, see also PHI343.)

The above workaround is not reliable since it skips the files entirely vs checking the remaining characters.

Oops, I filed it in the wrong place, my apologies!

Please file feature requests through the community forum (https://discourse.phabricator-community.org) or a support pact (https://admin.phacility.com/book/phacility/article/support_pacts/).

Doh!, I was looking at the jshint engine before, not the eslint engine. It looks like phab doesn't have built-in support for eslint yet. But this looks promising: maybe the autofixing eslint reports *is* on an error-by-error basis.

At Facebook we have a custom arcanist lint engine that wraps eslint with a custom (JS) runner that extracts more info about each fix:

See also PHI48.

The community forum is a better place for this discussion. You may or may not receive help there, but we're no longer providing general Phabricator support here in the upstream (nor have we for a long time).

I'm having problems with script-and-regex too. I have asked in the community forum but without luck. I’m trying to add phpstan to the arc lint workflow, as explained in the documentation, but I’m unable to capture the error message. Here are my files:

In T7091#111368, @epriestley wrote:

ScriptAndRegexLinter needs to be modernized, but is strictly more powerful than the proposed linter. Something like this will implement your desired lint rule after the linter modernizes:

"todo": {
  "type": "script-and-regex",
  "script-and-regex.script": "grep -n TODO --",
  "script-and-regex.regex": "/^(?P<file>[^:]+):(?P<line>\\d+):/"
},

done! cheers

On a purely personal/aesthetic level, the box-drawing character block is total garbage and master ASCII artisans would never use it in serious work. A true connoisseur of the craft should accept nothing more than single-byte ASCII range in their collection.

See some related discussion in T12822. In particular:

I'm going to merge this into T9846 since I think they're the same, yell if it looks like I'm missing anything.

Hey guys,

@epriestley - I have "almost" ready test suite, hovewer I can't work out line ending test with CR/LF endings. - D17814

@johnny-bit Sure, feel free.

Hi! I'd love to submit diff + better test cases for this case. I have 3 additional test cases and better character class for whitespace.

The patch above fixes the issue, but as you mention, double newlines are also considered whitespace, which is pretty bad and removes every empty line.
Additionally, \r is also covered by \s, so the patch above creates a new issue that is very similar to mine: the rule LINT_TRAILING_WHITESPACE fixes line endings even when the rule LINT_DOS_NEWLINE is disabled.

That seems to decide that "\n\n" is "trailing whitespace", which doesn't really make sense to me, but [ \t] might work better than \s.

(Ideally, accompanied by new test coverage.)

If you want to test it, I'll accept this change or some substantially similar change upstream:

In T12639#221773, @chad wrote:

I think this is T10038

I think this is T10038

See T10038: Plan the mid-term pathway for unit-test/linter bindings and Community Resources.