Additional bugs in S1155

[Zuplyx]

To verify the solution for #1025, I decided to test Sorald with SonarJava's test file and I unfortunately found two new bugs with the processor:

• L33: The repair for b = myCollection.size() <= 0; wrongly generates a negated call b = !myCollection.isEmpty(); when it should be just b = myCollection.isEmpty();.
• L37 to L62: Statements in the form of b = 0 == myCollection.size(); cause a ClassCastException in Sorald with the following stacktrace. Additionally it seems that the summary message after processing still counts these statements as fixed.

  java.lang.ClassCastException: class spoon.support.reflect.code.CtLiteralImpl cannot be cast to class spoon.reflect.code.CtInvocation (spoon.support.reflect.code.CtLiteralImpl and spoon.reflect.code.CtInvocation are in unnamed module of loader 'app')
      at sorald.processor.CollectionIsEmptyProcessor.repairInternal(CollectionIsEmptyProcessor.java:17)
      at sorald.processor.CollectionIsEmptyProcessor.repairInternal(CollectionIsEmptyProcessor.java:9)
      at sorald.processor.SoraldAbstractProcessor.repair(SoraldAbstractProcessor.java:87)
      at sorald.processor.SoraldAbstractProcessor.process(SoraldAbstractProcessor.java:165)
      at spoon.support.visitor.ProcessingVisitor.scan(ProcessingVisitor.java:72)
      at spoon.reflect.visitor.CtScanner.scan(CtScanner.java:184)
      at spoon.reflect.visitor.CtScanner.visitCtAssignment(CtScanner.java:302)
      at spoon.support.reflect.code.CtAssignmentImpl.accept(CtAssignmentImpl.java:45)
      at spoon.reflect.visitor.CtScanner.scan(CtScanner.java:194)
      at spoon.support.visitor.ProcessingVisitor.scan(ProcessingVisitor.java:68)
      at spoon.reflect.visitor.CtScanner.scan(CtScanner.java:184)
      at spoon.reflect.visitor.CtScanner.scan(CtScanner.java:149)
      at spoon.reflect.visitor.CtScanner.visitCtBlock(CtScanner.java:321)
      at spoon.support.reflect.code.CtBlockImpl.accept(CtBlockImpl.java:58)
      at spoon.reflect.visitor.CtScanner.scan(CtScanner.java:194)
      at spoon.support.visitor.ProcessingVisitor.scan(ProcessingVisitor.java:68)
      at spoon.reflect.visitor.CtScanner.scan(CtScanner.java:184)
      at spoon.reflect.visitor.CtScanner.visitCtMethod(CtScanner.java:589)
      at spoon.support.reflect.declaration.CtMethodImpl.accept(CtMethodImpl.java:59)
      at spoon.reflect.visitor.CtScanner.scan(CtScanner.java:194)
      at spoon.support.visitor.ProcessingVisitor.scan(ProcessingVisitor.java:68)
      at spoon.reflect.visitor.CtScanner.scan(CtScanner.java:184)
      at spoon.reflect.visitor.CtScanner.scan(CtScanner.java:149)
      at spoon.reflect.visitor.CtScanner.visitCtClass(CtScanner.java:357)
      at spoon.support.reflect.declaration.CtClassImpl.accept(CtClassImpl.java:63)
      at spoon.reflect.visitor.CtScanner.scan(CtScanner.java:194)
      at spoon.support.visitor.ProcessingVisitor.scan(ProcessingVisitor.java:68)
      at spoon.support.QueueProcessingManager.process(QueueProcessingManager.java:118)
      at sorald.Repair.repairModelWithInitializedProcessor(Repair.java:205)
      at sorald.Repair.defaultRepair(Repair.java:135)
      at sorald.Repair.repair(Repair.java:112)
      at sorald.Repair.repair(Repair.java:95)
      at sorald.cli.RepairCommand.call(RepairCommand.java:147)
      at sorald.cli.RepairCommand.call(RepairCommand.java:32)
      at picocli.CommandLine.executeUserObject(CommandLine.java:2041)
      at picocli.CommandLine.access$1500(CommandLine.java:148)
      at picocli.CommandLine$RunLast.executeUserObjectOfLastSubcommandWithSameParent(CommandLine.java:2461)
      at picocli.CommandLine$RunLast.handle(CommandLine.java:2453)
      at picocli.CommandLine$RunLast.handle(CommandLine.java:2415)
      at picocli.CommandLine$AbstractParseResultHandler.execute(CommandLine.java:2273)
      at picocli.CommandLine$RunLast.execute(CommandLine.java:2417)
      at picocli.CommandLine.execute(CommandLine.java:2170)
      at sorald.Main.main(Main.java:7)

It might also be a good idea to compare Sorald's tests for the other processors with the ones from SonarJava to ensure the processors can handle all situations where SonarJava is expected to report an issue.

[algomaster99]

I intentionally skipped the repair for those cases. See the updated document here because I thought it would be extremely rare for them to appear in practice.

However, if it is essential for your use case, I can implement them.

[Zuplyx]

• Regarding the cases of 0 == myCollection.size(): I have a few of those in the code I am transforming, but I would not say it's essential to add them. However I would appreciate it if you could surpress the exception for these cases and not count them towards the total in the summary message.
• Regarding the case of myCollection.size() <= 0;: IMHO this should be fixed, as Sorald currently generates wrong code for it.

[algomaster99]

Sure. I will proceed to add them. Wait for a fix :)

[algomaster99]

@Zuplyx fixed! It should be out in release 0.8.4.

EDIT: https://github.com/ASSERT-KTH/sorald/releases/tag/sorald-0.8.4

[Zuplyx]

Thank you. The repair of my code now completed without issues.

[monperrus]

thanks a lot @algomaster99