Skip to content

Null state in unreachable code #32047

@gafter

Description

@gafter

I think the null state of an expression should take into account when it occurs in unreachable code. An expression in unreachable code is never ever null. Even the expression null is never null in unreachable code.

This is not the same as simply suppressing warnings in unreachable code (though we should consider that too). For example:

#nullable enable
public class C {
    public void M(bool b, string s) {
        var t = (b || true) ? s : null;
        t.ToString(); // unexpected warning CS8602: Possible dereference of a null reference.
    }
}

Formally, my proposal is that an expression is never null in an unreachable statement, never null when false after the constant true, never null when true after the constant false, and never null when false after expr is var x and similar patterns (which are always true but not a constant). These all have in common that the “current” state in the nullable analysis should be the unreachable state when evaluating the code in question. That means there is a nice bottleneck in the rvalue-visiting method where this can be implemented.

Metadata

Metadata

Assignees

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions