Type inference with null literals and nullable reference types

[svick]

I'm having trouble with the compiler not inferring the expected type for a generic method when nullable reference types are enabled and one of the arguments is the null literal. Consider the following code:

using System;

#nullable enable

void V<T>(T x1, T x2) { }
void F<T>(Func<T> f1, Func<T> f2) { }

V("", null);                // V<string>, warning
V("", default);             // V<string?>, no warning
F(() => "", () => null);    // F<string>, warning
F(() => "", () => default); // F<string>, warning

In all these examples, my expectation is that the inferred type should be V<string?> and there should be no warning. But only the V("", default) example follows that expectation.

When looking at the NRT spec, I see this:

If the resulting candidate is a reference type or a nonnullable value type and all of the exact bounds or any of the lower bounds are nullable value types, nullable reference types, null or default, then ? is added to the resulting candidate, making it a nullable value type or reference type.

As far as I can tell, in all of these cases the second argument should produce a lower bound of null or default, so the inferred type should be string?.

So, am I correct and is this a bug in the compiler? Or did I misunderstood the spec and this is the expected behavior?

[RikkiGibson]

We have a bug where null doesn't contribute its nullability to type inference. I believe it's tracked by #43536.

At any rate, I think for nullability analysis, a null literal should have the same behavior as any expression with constant value null.