End location inference doesn't work for rules using the new-style context.report API

[not-an-aardvark]

Tell us about your environment

• ESLint Version: 4.3.0
• Node Version: 8.2.0
• npm Version: 5.3.0

What parser (default, Babel-ESLint, etc.) are you using?

Please show your full configuration:

Configuration

rules:
  no-whitespace-before-property: error

What did you do? Please include the actual source code causing the issue.

echo 'foo .bar' | eslint --stdin --no-eslintrc --rule 'no-whitespace-before-property: error' --format json

What did you expect to happen?

I expected the resulting problem to have an endLine and endColumn, because the no-whitespace-before-property rule reports a node.

What actually happened? Please include the actual, raw output from ESLint.

[{"filePath":"<text>","messages":[{"ruleId":"no-whitespace-before-property","severity":2,"message":"Unexpected whitespace before property bar.","line":1,"column":1,"nodeType":"MemberExpression","source":"foo .bar","fix":{"range":[3,5],"text":"."}}],"errorCount":1,"warningCount":0,"fixableErrorCount":1,"fixableWarningCount":0,"source":"foo .bar\n"}]

Note that there is no endLine and endColumn.

The issue is that the change in b0c63f0 was incomplete. It modifies the logic in lib/eslint.js (which has now been renamed to lib/linter.js) to correctly handle the case where no location is provided. However, the report conversion logic for the object-based context.report API in rule-context.js incorrectly passes the start of a node as an explicit location. The result is that lib/linter.js does not add an end location because it thinks an explicit start location was already provided.

The quick fix would be to replace descriptor.node.loc.start on this line with descriptor.node.loc. As a potentially separate fix, I think we should refactor the interaction between Linter#report and RuleContext#report. This bug occurred because the two methods don't have a clear separation of responsibilities with regard to handling locations that weren't provided by the rule.

[Arcanemagus]

Maybe I'm misunderstanding the purpose of this, but there is an endLine and endColumn in that output:

[not-an-aardvark]

You're right, I made a mistake when creating this issue. The original output that I pasted there is not the output that ESLint actually produces, because I had tweaked some things locally when narrowing down the issue. I've edited the original issue to contain the real output, which is missing endLine and endColumn properties.