-
Notifications
You must be signed in to change notification settings - Fork 4.2k
Report warning for assignment or explicit cast of possibly null value of unconstrained type parameter type #48803
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
Conversation
…lue of unconstrained type parameter type
src/Compilers/CSharp/Portable/FlowAnalysis/AbstractFlowPass_LocalFunctions.cs
Show resolved
Hide resolved
src/Compilers/CSharp/Test/Semantic/Semantics/NullableReferenceTypesTests.cs
Show resolved
Hide resolved
src/Compilers/CSharp/Test/Semantic/Semantics/NullableReferenceTypesTests.cs
Outdated
Show resolved
Hide resolved
src/Compilers/CSharp/Test/Semantic/Semantics/NullableReferenceTypesTests.cs
Show resolved
Hide resolved
@@ -138978,18 +139418,30 @@ static T F1<T>(T x1) | |||
}"; | |||
var comp = CreateCompilation(source, parseOptions: TestOptions.Regular9); | |||
comp.VerifyDiagnostics( | |||
// (7,14): warning CS8600: Converting null literal or possible null value to non-nullable type. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It occurs to me that this message may not be quite right. T
is a possibly non-nullable type. It is not known to be non-nullable. However, this may not end up being very disruptive/confusing to users in practice.
[InlineData("where T : notnull")] | ||
[InlineData("where T : I")] | ||
[InlineData("where T : I?")] | ||
public void UnconstrainedTypeParameter_44(string constraint) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: test is named UnconstrainedTypeParameter, but it is about testing a variety of type parameter constraints.
src/Compilers/CSharp/Test/Semantic/Semantics/NullableReferenceTypesTests.cs
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, just had some minor feedback/suggestions
Should we have a single diagnostic here instead? It seems that both warnings are related to the same problem (assigning Refers to: src/Compilers/CSharp/Test/Semantic/Semantics/NullableReferenceTypesTests.cs:68235 in 80c60b3. [](commit_id = 80c60b3, deletion_comment = False) |
else | ||
{ | ||
typedValue = (T)value; | ||
typedValue = (T)value!; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How do we know value
isn't null here (seems like it could be)? #Closed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change just moves the !
from the return
statement to here.
In reply to: 518244029 [](ancestors = 518244029)
Since we're adding a nullable warning, it'll be good to do a validation on runtime and/or VS. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done with review pass (iteration 8)
VS validation: https://dev.azure.com/devdiv/DevDiv/_git/VS/pullrequest/283878.
dotnet/runtime#43925 resolves new runtime warnings resulting from this change #Closed |
The warnings are from separate expressions: the second warning ("CS8600: Converting null literal") is from assigning The behavior is the same for reference types: see sharplab.io. In reply to: 722532861 [](ancestors = 722532861) Refers to: src/Compilers/CSharp/Test/Semantic/Semantics/NullableReferenceTypesTests.cs:68235 in 80c60b3. [](commit_id = 80c60b3, deletion_comment = False) |
IIRC, once we stop updating parameter state based on the default value, it will turn into one warning. #Closed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM Thanks (iteration 9)
* upstream/master: (519 commits) Remove workaround in PEMethodSymbol.ExplicitInterfaceImplementations (dotnet#49246) Enable LSP pull model diagnostic for XAML. (dotnet#49145) Update dependencies from https://github.com/dotnet/roslyn build 20201109.8 (dotnet#49240) Add test for with expression in F1 help service (dotnet#49236) Cache RegexPatternDetector per compilation Fix RazorRemoteHostClient to maintain binary back-compat Further tweak inline hints Fix MemberNames API for records (dotnet#49138) Minor cleanups (dotnet#49204) Report warning for assignment or explicit cast of possibly null value of unconstrained type parameter type (dotnet#48803) Clean up of EditorFeatures.Cocoa.Snippets (dotnet#49188) Fix OK button state handling. Make relation between viewmodels more tightly coupled Extend make type abstract to include records (dotnet#48227) Remove duplicated implementations of C# event hookup Add select all/deselect all buttons Consolidate conditional compilation (dotnet#49150) Implement IEquatable on Microsoft.Cci.DefinitionWithLocation structure (dotnet#49162) Add new document extensions file Unify implementations Only disable structure tagger provider in LSP scenario ...
In a future version of the compiler, this cast is a warning (csc version 3.10, change introduce [here](dotnet/roslyn#48803)) This resolves the warning for this case.
In a future version of the compiler, this cast is a warning (csc version 3.10, change introduce [here](dotnet/roslyn#48803)) This resolves the warning for this case.
Report warnings when assigning
default
to, or when casting a possiblynull
value to a type parameter type not constrained to value types or reference types.Fixes #46044