Missing coverage: computed properties as shorthand props

[mroch]

The Flow parser incorrectly allowed object literals like {0} and {[x]} because it parsed the property's key and treated it as a shorthand definition when it didn't find a value.

The first case is covered already, the latter seems not to be. On one hand, it's not reasonable to test every bogus thing someone could write, but I think this one is worth testing because it's so similar to other property keys.

({x})    // covered by language/expressions/object/prop-def-id-valid.js
({0})    // covered, indirectly, by while/if/do-while tests
({true}) // covered by language/reserved-words/ident-reference-false.js
({[x]})  // not covered

[leobalter]

While I might agree with verifying {0} or {[x]}, but I'm not totally fond of it. I understand it might cover a regression in a specific implementation, but I'm afraid I don't have anything specific to cover in the spec for those.

This might scale to the uncertainty of every possibility we can use to match. {0} and {[x]} are just starters.

This doesn't mean I'm against this, I'll try my best to make a fit for these cases into Test262, somehow I want to add them to this test suite.

[mroch]

yeah, agreed that it's not reasonable to test random invalid stuff. i think the only justification here is that it's a valid computed property key when it's followed by a value, but not alone. things that are neither valid keys nor valid shorthand seem definitely out of scope. I won't be upset if you just close this, though.

[leobalter]

I think I can do this.

Starting from https://tc39.github.io/ecma262/#prod-ObjectLiteral:

PropertyDefinition:
  IdentifierReference
  ...
  PropertyName : AssignmentExpression

we need to distinguish PropertyName - that requires being followed by an AssignmentExpression - from an restricted IdentifierReference.