Closed richardwerkman closed 3 months ago
I reproduce, looking into it. Crashing the compiler is pretty rare...
ok, this is the mutated version of GitInfoProvider that triggers this. It looks like there are ~80 mutations there. Finding the problematic one will be fun
Ah man, good luck analyzing this :) Thanks for looking into this so quickly!
look what Copilot proposed me while working on a recovery strategy:
_logger.LogError("Failed to compile due to a NullReferenceException. This is a known issue in Roslyn. Please report the issue to the Roslyn team.");
So far, I did not spot anything surprising while reading the mutated code. But I am almost done having a work around strategy for his kind of issues
update: it looks like there are 5-6 files that raises this problem. I am not able yet to restore normal flow. This probably due to some stupid bug on my side as restoring the concerned files to their original version should remove the exception. re update: stupid error found, working on a proper fix (this was due to rollback logic reusing non fixed syntax trees)
minor update: of course, this issue appears also in single project mode. I fixed source file compilation issues, but I still have problem with project resources.
Huh, this seems like a big issue. It's a shame our integration test didn't catch this...
I still have problems with resources management. It is likely to be a side effect of the compiler exception which triggers some cleanup.
I have identified one problematic construct, so I should be able to reproduce and fix it:
_testGuids?.Count ?? 0;
These are not properly mutated. I will not share the mutated as it contains 4 mutations. Clearly the conditional operator was not properly mutated (this is the last mutation)
...(StrykerabBot37wrmyO0As.MutantControl.IsActive(3055)?.Sum:.Count)
update: the root cause is a regression with ConditionalAccessExpressions
(?.
). I am trying to find a way to deal with these in some central fashion, and not by adding ifs
everywhere. My last refactoring went too far; early design was too clunky, the current one is too streamlined. I may have a better design in mind. We will see about that.
I have been able to successfully compile 2 of the problematic files, the remaining three contains various constructions with conditional access expressions that force me to think about a better design.
Regarding restoring proper workflow in case of Roslyn exception, I have an almost working version, but I still have issues with resources: streams are finalized when the exception is thrown. I will see what can be done about it, but my focus is on the conditional access expression stuff.
Edited to correct usage of ConditionalExpressions (?:
) instead of the proper ConditionalAccessExpression (?.
)
Stupid me
update: the design I had in mind works. I had to add several orchestrators, which I do not like. But, I finally got my head around chained MemberAccesses (and variants). Still have to streamline the design a bit. But I can open a PR now if the fix is urgent
Nothing except going to the hospital with a missing leg is really urgent :) just let us know what you prefer: shall we better stick to the old version so that you have more time to find a solution that fits you better? Or wait for a temporary fix?
Because in our CI pipeline, we're pulling and installing the latest version of Stryker (which fails at the moment) and now I have to decide whether to live with the failing builds for a couple of days or go back to the previous version :)
I will see today how far I am for a good solution and decide afterward. One thing is sure: there is no quick fix, it needs to add a few orchestrators and maybe add features to MutationContext. So if I think this is too far away, I will open a PR with an interim solution. Here are the things I want to fix:
x.y.z().t.u
, at once, while it would be smarter to mutate only the beginning (which the master version does, sometimes).The problem with member access chains is that they are described right from left, which may force some double scanning...
@mu88 I was wondering if more people were seeing this behavior. We could see if we can revert the commit that causes this for now. And release the refactor again later (when a fix is ready).
cool. I have improved design and the recovery mechanism now works properly. Still need to:
@mu88 I was wondering if more people were seeing this behavior. We could see if we can revert the commit that causes this for now. And release the refactor again later (when a fix is ready).
@richardwerkman sry for not jumping in earlier ^^ I saw the issue popping up last week on our infrastructure, however, I was triggering figuring out what's wrong on our side because I didn't blame Stryker :)
the PR is ready for review. As said earlier, I will not attempt to reach expected coverage level as it requires wrapping C# compiler
Describe the bug When running stryker in solution mode, mutation fails with a null reference exception. I ran stryker on another clone of stryker (master branch).
Logs log-20240315.txt
Desktop (please complete the following information):
Additional context I reverted some commits to locate that this behaviour was added during the refactor of the mutation orchestration by @dupdob