Adapt Class validators to SootUp#863
Adapt Class validators to SootUp#863Momo-Not-Emo wants to merge 2 commits intosoot-oss:developfrom Momo-Not-Emo:class-validator
Conversation
|
thx for your contribution! It seems like a duplicate of #860 ? Lets merge the best of both approaches.
you can get it via I think isAllowedInFinalCode() should not be necessary (and thats the reason we have/need a validator) / I am not sure we should have an API for it. Maybe lets have an interface for the all allowed types and check via instanceof that interface? like an interface for non-void types, "Method returnable types" including void? |
akshitad11
left a comment
akshitad11
left a comment
There was a problem hiding this comment.
Kindly refer to my pull request : 860.
I have already made changes to MethodDeclarationValidator in much more detail there. Let's merge these changes as suggested by @swissiety.
Also, my changes for ClassFlagsValidator(now renamed to ClassModifierValidator) are merged in develop, please take the latest version of develop and you will see the changes.
However, it seems |
3 participants
This pull request modifies the
MethodDeclarationValidatorandClassFlagsValidatorclasses to be compatible with SootUp.boolean isAllowedInFinalCode()method to the Type class and its subclasses forMethodDeclarationValidator.sc.isSuper()is now used inClassFlagsValidatorinstead ofsc.isSynchronized()due to a method renaming.However, the adaptation of
OuterClassValidatorremains incomplete. This validator is designed to check for cycles in the outer class chain, but adapting it is challenging because the return type ofSootClass::getOuterClasshas changed fromSootClasstoClassType. I am uncertain about how to obtain theSootClassobject from theClassType.Note: There are no test cases included in this pull request, as these class validators are not currently utilized in SootUp. They are typically invoked through
PackManagerin Soot, but it appears that SootUp has not yet portedPackManager.