Skip to content

Conversation

@stephentoub
Copy link
Member

For the non-generic IEnumerator, we don't have any idea whether the type contains nulls or not. If we're forced to annotate it, ? is correct, because it says "it's possible this is null" and we can't prove it's not. But that ends up leading to lots of spurious warnings, in particular when enumerating over supplied collections that won't ever contain null, e.g. enumerating a CookieCollection. Since the non-generic IEnumerator is effectively legacy, our best path forward while maintaining correctness and avoiding causing unnecessary warnings is to simply not annotate IEnumerator.Current at all, leaving it "oblivious"; in that way, we don't make any claims about its state, and leave it up to tooling how to best convey that.

Fixes https://github.com/dotnet/csharplang/issues/3214
cc: @buyaa-n

Copy link
Contributor

@buyaa-n buyaa-n left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great, thanks! Left one optional NIT comment

@stephentoub stephentoub reopened this Jun 17, 2020
@stephentoub stephentoub reopened this Jun 17, 2020
@stephentoub stephentoub force-pushed the nullableenumeratorcurrent branch from cb08f84 to 165063e Compare June 17, 2020 09:45
@stephentoub stephentoub reopened this Jun 17, 2020
For the non-generic IEnumerator, we don't have any idea whether the type contains nulls or not.  If we're forced to annotate it, `?` is correct, because it says "it's possible this is null" and we can't prove it's not.  But that ends up leading to lots of spurious warnings, in particular when enumerating over supplied collections that won't ever contain null, e.g. enumerating a CookieCollection.  Since the non-generic IEnumerator is effectively legacy, our best path forward while maintaining correctness and avoiding causing unnecessary warnings is to simply not annotate `IEnumerator.Current` at all, leaving it "oblivious"; in that way, we don't make any claims about its state, and leave it up to tooling how to best convey that.
@stephentoub stephentoub force-pushed the nullableenumeratorcurrent branch from 165063e to ebbb979 Compare June 17, 2020 15:24
@stephentoub stephentoub merged commit 5f29a03 into dotnet:master Jun 17, 2020
@stephentoub stephentoub deleted the nullableenumeratorcurrent branch June 17, 2020 21:09
AndyAyersMS pushed a commit to AndyAyersMS/runtime that referenced this pull request Jul 30, 2020
Reworking of dotnet#37969. Block LSRA from using R2 around the profiler leave
callback, but don't kill GC refs in R2, since late codegen will use
R2 to temporarily hold return values around the callback.

Fixes dotnet#37223.
AndyAyersMS added a commit that referenced this pull request Jul 30, 2020
)

Reworking of #37969. Block LSRA from using R2 around the profiler leave
callback, but don't kill GC refs in R2, since late codegen will use
R2 to temporarily hold return values around the callback.

Fixes #37223.

Co-authored-by: Carol Eidt <[email protected]>
Jacksondr5 pushed a commit to Jacksondr5/runtime that referenced this pull request Aug 10, 2020
…net#40123)

Reworking of dotnet#37969. Block LSRA from using R2 around the profiler leave
callback, but don't kill GC refs in R2, since late codegen will use
R2 to temporarily hold return values around the callback.

Fixes dotnet#37223.

Co-authored-by: Carol Eidt <[email protected]>
@ghost ghost locked as resolved and limited conversation to collaborators Dec 8, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants