JS: Handle spread/rest in API graphs

[asgerf]

Makes sure API graphs can look through spread/rest parameters. An important situation where this occurs is in default constructors, where spread/rest are inserted automatically.

For example, the class below

import { ApolloServer } from "@apollo/server"

class CustomApollo extends ApolloServer {}

is desugared into this:

class CustomApollo extends ApolloServer {
  constructor(...args) { super(...args) }
}

We have a model that looks for arguments passed to the ApolloServer constructor,

["@apollo/server", "Member[ApolloServer,ApolloServerBase].Argument[0].AnyMember.AnyMember.AnyMember.Parameter[1]", "remote"]

This ought to pick up on calls to new CustomApollo because the arguments are forwarded to ApolloServer:

new CustomApollo({ ... })

But evaluation got stuck at Argument[0] because of two issues:

• the super call targeting the ApolloServer constructor was not being considered at all, and
• the rest parameter and spread argument ...args were not understood by API graphs

This PR fixes the above two issues, and fixes the FN from the test case.

[erik-krogh]

Looks good, just some minor comments.

I feel like the change to invocation(...) could have been it's own commit with a separate test.

[erik-krogh]

There is no getSpreadArgument() method on API::Node, which is what the toString() usually refers to.

I think it's fine here, but maybe add a small comment that this method is only used internally. (I'm counting the Label:: module as internal).

[erik-krogh]

.getALocalUse() on pred?

[asgerf]

Not needed. It would be equivalent to getALocalSource() on the rest parameter, but parameters are already a source.

[erik-krogh]

I having a hard time figuring out whether the arithmetic here is correct.

Could you add a test with some bound arguments?

[asgerf]

Good catch, there was indeed a bug here. Added a test and made the code easier to read.

[erik-krogh]

So this is modelling the parameters at (or after) the rest parameter, and modelling each entry as an array store into the spread argument.
And this is then only used for the getParameter method to be able to retrieve the correct parameter when there are spread arguments?

[asgerf]

Yes. Added a comment to clarify.

[asgerf]

And this is then only used for the getParameter method to be able to retrieve the correct parameter when there are spread arguments?

Ah, actually no, it's more than that. If a library model expects an argument to contain array elements, this will allow the model to find those array elements when the array was created by passing arguments into a rest parameter.