Swift: synthesize MethodRefExpr
#10111
Conversation
This introduces a `MethodRefExpr` node synthesized out of `DotSyntaxCallExpr` under the `LookupExpr` hierarchy. This means that much like ```free_function(1, 2)``` is a `CallExpr` with `getFunction` giving a `DeclRefExpr`, ```foo.method(1, 2)``` is now a `CallExpr` with `getFunction` giving a `MethodRefExpr`. `ApplyExpr::getStaticTarget` has been made work with it (as well as `ConstructorRefCallExpr` which for the moment has been left where it is), a new `MethodApplyExpr` has been introduced deriving from it, and control and data flow libraries have adapted. A small but was fixed in `qlgen` where the default constructor for DB types was not correctly subtracting derived IPA types depending on the order of definitions in `schema.yml`. There are still some occurrences of `DotSyntaxCallExpr`, and as already mentioned the other `SelfApply` class (`ConstructorRefCallExpr`) was left alone. Their treatment is left for a future PR.
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| or | ||
| result = f.(MethodRefExpr).getMethod() | ||
| or | ||
| result = f.(ConstructorRefCallExpr).getFunction().(DeclRefExpr).getDecl() |
There was a problem hiding this comment.
I imagine we can remove this case once MethodRefExpr includes ConstructorRefCallExpr.
There was a problem hiding this comment.
it depends how we want to do that. If we want constructors to be in the same bag as methods, then yes, though it will mean having to make MethodRefExpr a superclass of two distinct concrete IPA classes (one synthesized from DotSyntaxCallExpr and the other from ConstructorRefCallExpr). The other approach would be to make ConstructorRefExpr a sibling of MethodRefExpr under LookupExpr, then we would edit this line rather than suppress it
There was a problem hiding this comment.
Good point. In this case, I think we should follow whatever precedent Java/C# has set. Do you know if their version of MethodRef also includes constructors (assuming you can actually do this in those languages 🤔)?
Anyway, this is all for a future PR (as you noted as well!)
Also rename `getMethod` to `getMethodDeclaration` to clear up possible confusion with `getFunction`.
`getStaticTarget` gives the same result.
swift/ql/test/extractor-tests/generated/expr/DotSyntaxCallExpr/dot_syntax_call.swift
Outdated
Show resolved
Hide resolved
This introduces a
MethodRefExprnode synthesized out ofDotSyntaxCallExprunder theLookupExprhierarchy. This means thatmuch like
free_function(1, 2)is a
CallExprwithgetFunctiongiving aDeclRefExpr,foo.method(1, 2)is now a
CallExprwithgetFunctiongiving aMethodRefExpr.ApplyExpr::getStaticTargethas been made to work with it (as well aswith
ConstructorRefCallExprwhich for the moment has been left where itis), a new
MethodApplyExprhas been introduced deriving from it,and control and data flow libraries have adapted.
A small bug was fixed in
qlgenwhere the default constructor for DBtypes was not correctly subtracting derived IPA types depending on the
order of definitions in
schema.yml.There are still some occurrences of
DotSyntaxCallExpr, and as alreadymentioned the other
SelfApplyclass (ConstructorRefCallExpr) wasleft alone. Their treatment is left for a future PR.