[return: NotNullIfNotNull(paramName)]

[dgrunwald]

[return: NotNullIfNotNull(paramName)] is a semi-common attribute to use, especially in some code bases that like to use: if (input == null) return null; at the start of many functions.

Unlike [NotNullWhen(bool)] for out parameters, I don't see a clean way to infer NotNullIfNotNull with our current algorithm. But it would be valuable to figure something out, so I'm creating this issue to collect some cases of [NotNullIfNotNull] methods and their constraint graphs.

[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 07b2d7842cb49efcdaa2682f4c7560520661e0f4), 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).