-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
[release/6.0] Fix NullabilityInfoContext.Create throws IndexOutOfRangeException and other bugs #81291
Conversation
* Fix several bugs in NullabilityInfoContext.
* Moved call to TryLoadGenericMetaTypeNullability The TryLoadGenericMetaTypeNullability method was called with the same member info but varying nullability across the entire nullability hierarchy. Moved it one level up where nullability and member info are aligned.
Tagging subscribers to this area: @dotnet/area-system-reflection Issue DetailsManual backport of #71851 and #64143 ContextThese bugs have been reported previously and fixed in 7.0. A customer requested to port #71851 into 6.0 as it is LTS, but #71851 fix is based on #64143 and #64143 also has fixes for uncovered edge case scenarios related to generic type parameters nullability. Overall, these 2 PRs completes Expose Nullability info from Reflection feature we added in .NET 6.0 Customer ImpactThe customer started to use This could happen for any customer that uses Testing
RiskLow, the
|
@buyaa-n Some of the failing tests look like they involve Reflection; can you take a look please? https://github.com/dotnet/runtime/pull/81291/checks?check_run_id=10941557543 |
Once we confirm this is coming in clean and no tests regressed, then this has my support. I know we considered several approaches for backporting the fix and I agree with the conclusion that the best approach is to backport the refactoring and other fixes along with the fix for the specific issue reported. I looked back at our risk taxonomy to check that Low is appropriate; it is.
I echo the "bonus points if a customer has tried it out" statement. Since there are unrelated changes as described, getting the customer's validation that the net8.0 bits as-is work in their scenarios would be reassuring. |
This is not related, I see |
I asked for that, the response was |
Closing and reopening because the CI couldn't find the obsolete helix queues and a lot of test coverage was lost. I already fixed that and merged it: #81807 |
Manual backport of #71851 and #64143
Fixes: #81022
Context
These bugs have been reported previously and fixed in 7.0. A customer requested to port #71851 into 6.0 as it is LTS, but #71851 fix is based on #64143 and #64143 also has fixes for uncovered edge case scenarios related to generic type parameters nullability. Overall, these 2 PRs completes Expose Nullability info from Reflection feature we added in .NET 6.0
Customer Impact
The customer started to use
NullabilityInfoContext
in order to support nullable reference types properly across different parts of their system and plan to use it everywhere were they must know at runtime that some property is optional. They found out that NullabilityInfoContext breaks with exception at runtime and makes certain parts of their product unusable.This could happen for any customer that uses
NullabilityInfoContext
with types having generic type parameters and there is no work around.Testing
Risk
Low, the
NullabilityInfoContext
feature doesn't affect any other library functionality, the fixes reviewed and unit tested completely. The bugs were fixed in 7.0 a while ago and it's been stable since then.CC @jeffhandley @steveharter