Issue description

Sometime, return value for a function is not correctly identified as null allowed. See snippets below.

Choose one or more from the following categories of impact

• Unexpected nullness warning (false positive in nullness checking, code uses --checknulls and langversion:preview).
• Missing nullness warning in a case which can produce nulls (false negative, code uses --checknulls and langversion:preview).
• Breaking change related to older null constructs in code not using the checknulls switch.
• Breaking change related to generic code and explicit type constraints (null, not null).
• Type inference issue (i.e. code worked without type annotations before, and applying the --checknulls enforces type annotations).
• C#/F# interop issue related to nullness metadata.
• Other (none of the categories above apply).

Operating System

macOS

What .NET runtime/SDK kind are you seeing the issue on

.NET SDK (.NET Core, .NET 5+)

.NET Runtime/SDK version

.0.100-rc.2.24474.11

Reproducible code snippet and actual behavior

This case generate error Program.fs(14,14): error FS0043: The type 'List<'T>' does not have 'null' as a proper value

[<AbstractClass>]
type Generator<'T>() =
    abstract Values: unit -> 'T

[<Sealed>]
type ListGenerator<'T>() =
    inherit Generator<List<'T> | null>()

    override _.Values() =
        if false then []
        else null

This case does not generate error (same as above but with forced signature on Values()):

[<AbstractClass>]
type Generator<'T>() =
    abstract Values: unit -> 'T

[<Sealed>]
type ListGenerator<'T>() =
    inherit Generator<List<'T> | null>()

    override _.Values(): List<'T> | null = // <-- signature for return value forced
        if false then []
        else null

And this case does not generate error:

[<AbstractClass>]
type Generator<'T>() =
    abstract Values: unit -> 'T

[<Sealed>]
type ListGenerator<'T>() =
    inherit Generator<List<'T> | null>()

    let theValue() = null

    override _.Values() = // <-- no return signature
        theValue() // <-- just calling a function instead if if/else

Possible workarounds

Forcing signature on method seems to fix the problem. But it's cumbersome and not natural.