We are not actually killing the mutation. We are just playing smart with pitest so it cannot create a mutation that passes all test cases.

The real problem is assigning variableUsageAst to blockWithVariableUsage in every circumstance i.e. variableUsageAst = blockWithVariableUsage;.

The condition:

 variableUsageAst = Objects.requireNonNullElse(exprWithVariableUsage, blockWithVariableUsage);

translates to:

if (exprWithVariableUsage == null) {          
    variableUsageAst = blockWithVariableUsage;
} else {                                      
    variableUsageAst = exprWithVariableUsage; 
}                                             

Now why this won't pass pitest is due to the mutation exprWithVariableUsage == null -> true which again results in the initial mutation condition i.e. variableUsageAst = blockWithVariableUsage;

Now we take advantage of another fact that currentScopeAst == null in every iteration and it is assigned value only at currentScopeAst = exprWithVariableUsage; Now there is no need to assign a value to currentScopeAst when exprWithVariableUsage is null because we already set currentScopeAst == null.

So using this information to our advantage we put currentScopeAst = exprWithVariableUsage; in the second branch of if-else so that the mutation exprWithVariableUsage == null -> true fails a test case as in that condition currentScopeAst would not be assigned to exprWithVariableUsage.

It is basically:

currentScopeAst = exprWithVariableUsage;        
if (exprWithVariableUsage == null) {            
    variableUsageAst = blockWithVariableUsage;  
} else {                                        
    variableUsageAst = exprWithVariableUsage;   
}                                               

versus

if (exprWithVariableUsage == null) {          
    variableUsageAst = blockWithVariableUsage;
} else {                                      
    // try replacing exprWithVariableUsage with blockWithVariableUsage,
    // still all test cases would pass 
    variableUsageAst = exprWithVariableUsage;
    currentScopeAst = exprWithVariableUsage;  
}                                             

BUT this doesn't change the fact that variableUsageAst = blockWithVariableUsage; can be done in any condition. Hence, the mutation is not actually killed but we just used certain facts to our advantage to kill the mutation.

This would reduce the count but we won't get any actual benefit in code quality by using this method.

@nrmancuso @romani @rdiachenko Thoughts on this way? I would say we should tackle the original mutation variableUsageAst = blockWithVariableUsage; instead of using certain facts to our advantage.

we do not try to kill survival. Our goal to avoid survival. Highly preferable by reasonable code.
It happens all the time with all quality tools.
Last 10% of items from quality tools are not about quality in most cases but about fact to make code clean from violation and prevent new violations to appear.
We had this problem in jacoco 100% coverage, last 10% of coverage was extremely complicated to cover, but final result is enormous, as we do not even discuss reduction of coverage. Nobody can point to bad code and say "look there are examples of bad testing, I am doing the same".

@Kevin222004 , why we can not simply apply pitest suggestion ?

@romani we can apply Pitest's suggestion I have debugged the whole code with that as well at the end output of the method will not affect it.

I don't want to make any new changes here and this was the possible way to avoid the mutation. I have really not think as #13121 (comment)

Instead of your changes, let's do what pitest suggests.

done

we can apply Pitest's suggestion I have debugged the whole code with that as well at the end output of the method will not affect it.

@Kevin222004 Another important aspect of this project is explaining why you think it will work. Sometimes there might be gaps in your calculation or sometimes we are thinking of something else and your calculation can correct us.

So please share why you think this won't be a problem in the PR description. This way even if it comes up as a regression later, we can find faults in our thinking if we have something (like a slight explanation as to why it is correct) present.

@Vyom-Yadav I have tried to explain such whole thing if you have any question in that let me know