Python: allow class decorators in .getASubclass()

[RasmusWL]

Instead of just adding the test example, I thought I would try to fix it. I'm totally up for discussing whether this is the right approach, but personally I think it aligns with our goals.

We don't currently allow decorators for functions, so there will be a little bit of inconsistency...

[yoff]

I agree with the heuristic in this PR; I would expect decorators to preserve the sub-class relationship often enough to make this over-approximation useful. Are the evaluation results as you expect?

The suggestion is mostly me being curious, the code might well be better as is.

[RasmusWL]

Accepting this change also fixed the tests 👍 😮

The problem was this bit of modeling code (in Flask.qll)

  class FlaskMethodViewClass extends FlaskViewClass {
    FlaskMethodViewClass() {
      api_node = Views::MethodView::subclassRef() and
      this.getParent() = api_node.getAnImmediateUse().asExpr()
    }

would no longer recognize the Nested class itself as being a MethodView subclass 😞 (since the ClassExpr was not treated as a subclass)

    @flask_admin.expose_plugview("/flask-class") # $ routeSetup="/flask-class"
    @flask_admin.expose_plugview(url="/flask-class/<arg>") # $ routeSetup="/flask-class/<arg>"
    class Nested(MethodView):
        def get(self, cls, arg="default"): # $ requestHandler routedParameter=arg
            assert isinstance(cls, ExampleClass)
            ensure_tainted(arg) # $ tainted
            ensure_not_tainted(cls)
            return "GET: " + arg # $ HttpResponse

[RasmusWL]

Results from initial DCA run did not look good at all. I'll do a new one now after having accepted your fix, and hopefully that should do better 🤞

[tausbn]

I wonder if it would be even more correct to say that (for the purposes of the API graph), the results of applying the decorators are not just subclasses of the same superclass, but in fact the very same class. In some sense, decorating a class should not really change the identity of that class (though it may e.g. wrap it in some other object).

This might also be needed in order to get tracking of instances through decorators to work correctly. Consider

@foo
class Bar:
    ...
    def baz(self):
        ...

Bar().baz()

we want the call above to resolve Bar.foo, but if we just follow the flow, we'll find that Bar comes from a desugared assignment Bar = foo(Bar), which doesn't obviously have a baz method (at least, not syntactically). If we let classes "flow through" decorators, then there will be flow from the inner Bar to the call-site.

[yoff]

LGTM