Fixing parsing of method invocations in Javascript

[greg-at-moderne]

What's changed?

Fixing parsing of method and other function invocations in Javascript. Currently console.log("something") gets parsed as MethodInvocation(select=FieldAccess(console.log), name="") which is understandably not desired.

The design decision has been to:

• parse "normal" method invocations (with proper select and proper name) as J.MethodInvocation
• and any other function calls as a new type - called JS.FunctionCall

What's your motivation?

Avoiding wrong parsing. And providing reasonable level of compatibility with Java parsing.

[knutwannheden]

@greg-at-moderne Did we decide what to do about this?

[greg-at-moderne]

We have not, forgot about this one. It was several weeks ago.

[knutwannheden]

Looks good to me. Left a few small comments.

[knutwannheden]

It would be nice if we could detangle this a bit and have the ? be printed by the presence of the marker and then only here print the .. Would that make sense?

[greg-at-moderne]

I had it like you suggest before in my code, but then the Space handling is wrong:

- const result0 = func/*a*/?./*b*/("TS");
+ const result0 = func?/*a*/./*b*/("TS");

For that to work, the /*a*/ comment would need to land as Optional.prefix.
That in turn would make it inconsistent with how the /*a*/ comment is placed in other similar syntaxes.
See call.test.ts / with optional chaining operator.

I suggest to keep it like it is. After all the ?. is a single token with its own meaning, thus it feels OK to print it in one go.
Wdyt?

[knutwannheden]

I understand. In that case I think it probably makes sense to keep it this way, unless we want to add some kind a dedicated optionalChaining property to the JS.FunctionCall type. That would then however require parsing any calls using ?. into a JS.FunctionCall.