-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incorrect "CS8602 Dereference of a possibly null reference" after pattern-matching through a derived type #72680
Comments
Notes from investigation so far: The DAG of the switch is:
Note that in path 0-1-2-3-4-5-7-8-13-14 the property is accessed twice (in [2] and [8]), each time saved into a different temp. This is an optimization which happens when But nullability analysis does not track aliased references, for example: var p1 = C.P;
if (p1 != null)
{
p1.GetHashCode();
var p2 = C.P;
p2.GetHashCode(); // warning: p2 may be null
}
static class C
{
public static object? P { get; set; }
} Given this, I think there are different ways to fix the superfluous nullability warning:
|
This is a variant of the track nullness through |
Could this be a side effect of #34933? |
@jaredpar i'm not sure hwo this is through a bool or alias. in the above code it's simply: // ⚠️ CS8602 Dereference of a possibly null reference.
// ↓
Base { Foo: { } f } => f.GetHashCode(), Because of hte |
That seems to be hte issue. Even if we don't want to emit the Can we have the check be in the DAG, but mark it as superfluous for emitting? |
I don't see this as a case of an alias. In this case, if there is an alias, it's an internal impl detail of the compiler in how it chose to represent the code. Form the perspective of the lang, there is no alias, and this should not give a null-warning. I think we should fix the internal representation. Could nullability analysis be done on the initial unoptimized DAG? THen we optimize the dag and use that in emit? |
Can it be done: yes. Is it worth the significant code change for this bug: almost certainly no. |
What about having the |
Possibly. It's a new data flow path we'd need to design and push into our NRT analysis which is already incredibly complex. Just don't see it meeting our bar anytime soon. |
That's fine. Can we leave this open though? To me, this seems more like a bug in our impl, versus an intentional limitation of the design of nullability analysis. I can totally see the bug and costs not meeting hte bar any time soon. But i think this issue would still be worthwhile to track this. |
Version Used: VS 17.10.0-p2 and SharpLab
The repro disappears if the pattern matching is done via
Base
instead ofDerived
or ifFoo
is not read in theDerived
property pattern.Diagnostic Id:
CS8602
Expected Behavior:
No warning.
Actual Behavior:
Warning as shown in the code sample.
The text was updated successfully, but these errors were encountered: