Optional "Semantic" mode

[Liam-Rougoor]

Stryker.NET does not use the semantic model:

2. Stryker.Net not does use the semantic model of the syntax tree.
   1. This improves performance during mutation.
   2. On the other hand, one must not design a mutator relying on type information (e.g. Linq / Threading dedicated mutators).
      The semantic model is an improved version of the syntax tree which adds the type information to the syntax elements.

This definitely makes sense for performance reasons, but this makes it difficult to design mutators that handle semantic info (like type information).

I was wondering, instead of not supporting the semantic model at all, would it be possible to give users the choice to enable/disable the semantic model? Then users could decide whether they prefer mutation performance or a bigger set of mutators.

I'm not sure yet how implementing this would affect the current Stryker.NET architecture, but if people are interested, I would definitely like to investigate this further.

[dupdob]

IMHO, adding new mutators definitely brings diminishing returns and hence is not a project priority. I think there is a good chance that Stryker already has too many mutators. Type specific mutators are only interesting when user analyzes survivors to assess if they demonstrate problem in their tests base or not, and then add the appropriate tests accordingly. This is the way I work on NFluent, which I keep at 100% kill rate. But this requires an important effort while it is quite a simple project (of moderate size).

But, adding the semantic model could be interesting to improve the accuracy of existing mutators and to avoid compilation errors that lead to safe mode.

So being able to assess the impact of enabling semantic info to see if this is acceptable performance wise is a good first step.

Based on opened issues, I think the most pressing problem for Stryker is to add support to other existing project types (Unity, Razor, code generators....). Addressing this requires creativity as the main problem is the replication of MsBuild: as of now, Stryker tries to replicate what MsBuild does, but this is only doable for really basic workflows.