Open dupdob opened 10 months ago
Makes sense as safe mode was added as a temporary fix. The idea was however that we would fix all occurrences when they pop up and in time we would see less and less safe mode triggers. If this is not the case, we might have slacked a bit in fixing the causes of the safe mode triggers...
the idea was however that we would fix all occurrences when they pop up ... we might have slacked a bit yes, that was the original idea, but it turns out they are many situations when the error cannot be prevented without arduous/lengthy data flow coverage, and cannot be realistically prevented.
My proposal here aims at being better at flagging mutations as compilation errors and preventing collateral damage due to safe mode. So, compilation errors would still be visible and thus could be addressed at the mutator level.
Plus, there is also the trend of saying: if a mutation results in a compilation error, it should be marked as such instead of trying to make to compile anyway (I do not fully share this point of view, but I understand where it comes from).
I mean, we could get rid of many safeguards (such as return default
) which exists mainly to prevent safe mode from triggering too often.
Is your feature request related to a problem? Please describe. Safe mode removes many valid mutations as a side effect. This is a loss of information in itself; also, with the evolution of the C# language towards more implicit syntax constructions, type determination, it is likely the number of safe mode triggers may increase. Other 'safety' related features (return default, out variable initialization) have for sole purpose to ensure mutated code can compile. These are subject to discussions as they enable non viable mutants. Hence, while Stryker needed those features as part of its growth, they should now be removed, where and when possible.
Describe the solution you'd like Stryker should be able to remove every non viable mutations (i.e. those which are sources of compilation errors) while keeping the viable ones. As a reminder the problem occurs when the compilation error appears far from the mutation causing it. A possible solution could be to incrementally add/remove mutations until the guilty one(s) is(are) identified. A side effect of this approach could be that it significantly lengthen the compilation phase, so it could be an option. The main problem is that the current design does not support restoring a mutation that has been removed, so this may be difficult to achieve.
Describe alternatives you've considered Alternative approaches:
Additional context I am willing to dig into this as I think this is probably the (current) most limiting issues with Stryker