You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Branch master (27 Oct 2020)
Latest commit 576eb30 by Sam Harwell:
Merge pull request #48934 from sharwell/no-api-telemetry
Disable ApiUsageIncrementalAnalyzerProvider for production scenarios
Steps to Reproduce:
#nullable enable
using System.Diagnostics.CodeAnalysis;classC<T>{[NotNull]publicTProp{get;set;}publicC(Tt){Prop=t;}// no warningspublicC(Tt,intx){Prop=t; Prop.ToString();}// CS8602[MemberNotNull("Prop")]publicvoidInit(Tt){Prop=t;}// CS8774}
Expected Behavior: CS8618 is reported for the first constructor
Actual Behavior:
No warnings for the first constructor
Notes
Note that if you add a dereference after the assignment e.g. Prop.ToString(); the compiler correctly emits CS8602 for that. So the compiler recognizes that the property might still be nullable contrary to its annotation yet the assignment suppresses the initialization warning in the constructor. I believe this behavior contradicts the following proposal: https://github.com/dotnet/csharplang/blob/master/proposals/nullable-constructor-analysis.md /cc @RikkiGibson
There's a similar problem in the following code (where annotations makes more sense). The compiler understands that the value of Prop might be nullable after the assignment so it emits CS8602 if I dereference the property in both the constructor and Init method but only warns about leaving the instance in invalid state in Init but not in the constructor
#nullable enable
using System.Diagnostics.CodeAnalysis;classC<T>{[NotNull,DisallowNull]publicTProp{get;set;}publicC(Tt){Prop=t;// CS8607if("".Length >0){ Prop.ToString();}// CS8602}// no warnings[MemberNotNull("Prop")]publicvoidInit(Tt){Prop=t;// CS8607if("".Length >0){ Prop.ToString();}// CS8602}// CS8774}
The text was updated successfully, but these errors were encountered:
Thanks, my best guess is we are not folding the flow analysis annotations when determining the required state for the field when exiting the constructor.
Version Used:
Steps to Reproduce:
Expected Behavior:
CS8618
is reported for the first constructorActual Behavior:
No warnings for the first constructor
Notes
Note that if you add a dereference after the assignment e.g.
Prop.ToString();
the compiler correctly emits CS8602 for that. So the compiler recognizes that the property might still be nullable contrary to its annotation yet the assignment suppresses the initialization warning in the constructor. I believe this behavior contradicts the following proposal: https://github.com/dotnet/csharplang/blob/master/proposals/nullable-constructor-analysis.md /cc @RikkiGibsonThere's a similar problem in the following code (where annotations makes more sense). The compiler understands that the value of
Prop
might be nullable after the assignment so it emitsCS8602
if I dereference the property in both the constructor andInit
method but only warns about leaving the instance in invalid state inInit
but not in the constructorThe text was updated successfully, but these errors were encountered: