-
Notifications
You must be signed in to change notification settings - Fork 300
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
[dataflowengineoss] Turn Semantics
into a node-directed trait
#4920
Conversation
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.
Sounds like a good idea from my POV, but since I'm not super familiar with Semantics I'll pass the torch to someone else, maybe @DavidBakerEffendi for approval..?
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.
Looks nice! Opens up a world of possibilities for this notation
FYI I've experimented with representing parameters undergoing fine-grained operations such as field accesses and calls within a method, and that used a similar approach as above, but was pretty difficult (not undoable though). This already makes the semantic DSL more readable though. |
@xavierpinho do you have permissions to merge? |
I have, thanks for asking :) Was just giving it some time in case someone wanted to chime in any other feedback first. |
Presently,
Semantics
are exclusively based on method fullNames and, while that is perfectly reasonable for statically typed languages such as Java, they are not so great for dynamic ones.The proposal here is to turn
Semantics
into a common trait equipped with aforMethod :: Method -> Option[FlowSemantic]
operation, that can take into account more information (since it's given the node itself) other than just its fullName. In doing so, I also renamed the currentSemantics
class toFullNameSemantics
, to make it clear what the latter operates on.In particular, this would allow users of Joern as-a-library to provide their own custom
Semantics
instance, that can inform the dataflowengine on a node-by-node basis.If this proposal is welcomed, I also intend to refactor
SemanticTestCpg
and friends to allow customSemantic
objects, instead ofFullNameSemantics
exclusively. Moreover, I'd also like to introduce aNoCrossTaint
semantics -- essentially a liftedPassThroughMapping
. This patch is already too large as is, so I refrained from doing so at this point.