-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fixing Java field access #1862
base: main
Are you sure you want to change the base?
Fixing Java field access #1862
Conversation
Blocked by #1586 |
c781e33
to
faaa036
Compare
4c7279c
to
952f56c
Compare
952f56c
to
5f75416
Compare
5f75416
to
c7f72a6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I fail to understand most of the changes since the old code is hard to understand and the new code requires in-depth knowledge and understanding of the java parser and frontend which I do not have. However, I have some nits which should already be resolved and may support subsequent more detailed reviews.
@@ -209,7 +209,7 @@ open class SymbolResolver(ctx: TranslationContext) : ComponentPass(ctx) { | |||
// Preparation for a future without legacy call resolving. Taking the first candidate is not | |||
// ideal since we are running into an issue with function pointers here (see workaround | |||
// below). | |||
var wouldResolveTo = ref.candidates.singleOrNull() | |||
var wouldResolveTo = ref.candidates.firstOrNull() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change does no longer account for ambiguities. The old code with singleOrNull()
prefers not to resolve anything if it's not sure about the candidate. I think this was also intended, wasn't it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was semi-intended. I am ok with the old behavior, but we should at least
- have a warning if we do not resolve it
- forward the decision to the
Language
. In Java it is possible to have an ambiguity here if you statically import a field and a function and both can have the same name and end up in candidates. I need to deal with that here
val fieldRef = findByUniquePredicate(refs) { "field" == it.code } | ||
val getSuperField = findByUniqueName(methods, "getSuperField") | ||
refs = getSuperField.allChildren<MemberExpression>() | ||
val superFieldRef = findByUniquePredicate(refs) { "super.field" == it.code } | ||
assertTrue(fieldRef.base is Reference) | ||
assertRefersTo(fieldRef.base, getField.receiver) | ||
// See https://github.com/Fraunhofer-AISEC/cpg/issues/1863. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see how this relates to the case of java.
// See https://github.com/Fraunhofer-AISEC/cpg/issues/1863. | ||
// We only have a regular call expression here, if we do not resolve anything else in the | ||
// frontend | ||
/*assertTrue(fieldRef.base is Reference) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
commented out code. -> Remove or fix. What do we expect?
@@ -889,3 +658,21 @@ class ExpressionHandler(lang: JavaLanguageFrontend) : | |||
} | |||
} | |||
} | |||
|
|||
fun ResolvedFieldDeclaration.toFieldAccessExpr(expr: NameExpr): FieldAccessExpr { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Documentation missing
// } | ||
val name = this.parseName(nameExpr.nameAsString) | ||
return try { | ||
// Try to resolve it. We will remove this in a future where we do not really in the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the TODO
of this method resolved? If so, please delete it.
Also, please document the method according to the new standards: #1683 (comment)
This sentence is broken
?: newProblemExpression("Could not parse base") | ||
} | ||
var fieldType: Type? | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please document the method according to the new standards: #1683 (comment)
|
||
@DependsOn(TypeResolver::class) | ||
@ExecuteBefore(SymbolResolver::class) | ||
class JavaExtraPass(ctx: TranslationContext) : TranslationUnitPass(ctx) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Documentation missing for this whole file
c7f72a6
to
592b8ce
Compare
Agreed. I will extract the remaining changes that are not Java-specific to extra PRs |
This PR consists of a major overhaul of Java reference and member expression parsing. It removes a LOT of old weird legacy code that was full of weird things.
It also introduces a new Java-specific pass, that takes care of deciding when a member access is actually static or not. This might be something that we could decide to adapt for other/all languages (maybe also tied to the discussion in #1863).
It also contains some adjustments to the import system, more specifically when the
importedSymbols
field is populated. This might have implications for other languages and if wanted I can extract this into a separate PR.