[return: NotNullIfNotNull(paramName)] about nullabilityinference

[dgrunwald]

    /// <summary>
    /// Atomically performs the following operation:
    /// - If target is null: stores newValue in target and returns newValue.
    /// - If target is not null: returns target.
    /// </summary>
    [return: NotNullIfNotNull("newValue")]
    public static T? GetOrSet<T>(ref T? target, T? newValue) where T : class
    {
        T? oldValue = Interlocked.CompareExchange(ref target, newValue, null);
        return oldValue ?? newValue;
    }

This one is trivial: the nullability of the return value directly depends on the parameter and on no other nodes.

We could detect this special case after building the graph, annotate the method with the attribute, then rebuild the graph from scratch, since callers of the method will profit from the attribute (via 07b2d78), and perform inference as usual in a second pass.

[dgrunwald]

A different case is something like this:

    [return: NotNullIfNotNull("filename")]
    public static Stream? OpenFile(string? filename)
    {
        if (filename == null)
            return null;
        return new FileStream(filename, FileMode.Open);
    }

Here the graph shows no relation between the parameter and the return node.
We could maybe detect that all incoming edges for the return node were created by code under a if (param == null) check (i.e. control-flow guaranteeing that the parameter being definitely null, not just potentially null as tracked by the flow-state implemented in #5).