Diagnostic for argument constraint with non-nullable type instead of nullable type

Split from #1005. Inspired by #660.

Assuming you have this interface:

public interface IFoo
{
    int Bar(int? x);
}

And a call configuration like this:

A.CallTo(() => foo.Bar(A<int>._)).Returns(42);

It’s easy to miss the fact that the constraint won’t match when the argument is null (it used to throw a NRE, which at least indicated something was wrong, but now it silently rejects the null argument). It’s especially confusing because when you write A<int>._, you usually mean “match anything”. The analyzer could detect this and emit a warning.

(I wish we could omit the type and just say A.CallTo(() => foo.Bar(A._), which is more concise and easier to get right. Java’s type inference is a little better in that regard. This syntax could also be achieved if we had a “bottom type” in C#.)

[thomaslevesque]

False positives are the worst of all situations, so if the That analysis might overreport warnings, I would leave it out. It’s easy to add new cases to the analyzer later.

A fix for Ignored (and _) sounds grand!

The thing is, this analyzer is bound to cause false positives, because you can intentionally write A<int>._ where a int? is expected. This is why I want to provide a code-fix to easily change it to something that is equivalent and more obviously correct. But since I can’t do that for A<T>.That..., the user would have to suppress the warning if it was intentional.

So I think I’ll just restrict the warning to Ignored and _.

[blairconrad]

This change has been released as part of FakeItEasy 4.0.0.