Fix: func-name-matching crash on non-string literal computed keys

[not-an-aardvark]

What is the purpose of this pull request? (put an "X" next to item)

[x] Bug fix

Tell us about your environment

• ESLint Version: master
• Node Version: 7.7.2
• npm Version: 4.1.2

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

default

Please show your full configuration:

rules:
  func-name-matching: error
parserOptions:
  ecmaVersion: 2015

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

({ [null]: function foo() {} })

What did you expect to happen?

I expected ESLint to not crash.

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

ESLint crashed.

Cannot read property 'length' of null
TypeError: Cannot read property 'length' of null
    at isIdentifierNameES6 (/path/to/eslint/node_modules/esutils/lib/keyword.js:123:15)
    at Object.isIdentifierES6 (/path/to/eslint/node_modules/esutils/lib/keyword.js:150:16)
    at isIdentifier (/path/to/eslint/lib/rules/func-name-matching.js:48:32)
    at EventEmitter.Property (/path/to/eslint/lib/rules/func-name-matching.js:174:21)
    at emitOne (events.js:96:13)
    at EventEmitter.emit (events.js:191:7)
    at NodeEventGenerator.enterNode (/path/to/eslint/lib/util/node-event-generator.js:39:22)
    at CodePathAnalyzer.enterNode (/path/to/eslint/lib/code-path-analysis/code-path-analyzer.js:607:23)
    at CommentEventGenerator.enterNode (/path/to/eslint/lib/util/comment-event-generator.js:98:23)
    at Controller.enter (/path/to/eslint/lib/eslint.js:928:36)

What changes did you make? (Give an overview)

In order to detect whether it should require a function name match, the func-name-matching rule checks to see if a computed object key is a string literal, and if so, it performs operations on the value of the string literal. However, the rule was previously only verifying that the computed object key was a literal, without verifying that it was a string literal. As a result, if other literals (e.g. null) were used as computed object keys, the rule would crash. This fix updates the rule to check that the object key is a string literal.

Is there anything you'd like reviewers to focus on?

Nothing in particular

[mention-bot]

@not-an-aardvark, thanks for your PR! By analyzing the history of the files in this pull request, we identified @azhang496 and @ljharb to be potential reviewers.

[eslintbot]

LGTM

[ljharb]

I'd add more test cases with a template literal, booleans, a regex, an array, and an object, but looks good!

[eslintbot]

LGTM