JS: Add decorator edges in API graphs and corresponding MaD tokens

[asgerf]

Adds the following API::Node members:

• getADecoratedClass
• getADecoratedMember
• getADecoratedParameter

And corresponding MaD tokens:

• DecoratedClass
• DecoratedMember
• DecoratedParameter

For example:

import { D } from "foo";

@D
class C // Matched by: foo;;Member[D].DecoratedClass

DecoratedClass could alternatively be expressed in terms of Argument[0] and ReturnValue. The others are not so simple, however, as they involve passing a base object and member name as an argument to the decorator, which typically then performs a reflective lookup. We don't have API edges for reflective lookups as they're tricky to model as unary operators.

So for the time being, no argument/return edges are generated for any of the decorator patterns although it's possible we should do so for class decorators in the future.

Awaiting evaluation when DCA comes up again.

[erik-krogh]

I'm unsure if there should be a def-node for this parameter-node.
And the tests pass just fine if I move the decoratedParameter edge to the decoratorUseEdge predicate.

[asgerf]

It's technically possible for the parameter decorator to replace the whole method with one that treats that parameter as a sink.

I have never seen any decorators that would have such behaviour, though. A made-up example might be a decorator that adds some expensive runtime checks on a value, which could then be a DoS sink.

In any case, it turns out using a parameter node as a sink is actually a terrible idea, at least with the current implementation (see test case in ca145f2).

So I've changed it to only generate use-nodes 👍

[erik-krogh]

👍

You just need the autoformatter to be happy.

[asgerf]

Thanks for the reviews! I've started an evaluation

[asgerf]

Evaluation seems ok