-
Notifications
You must be signed in to change notification settings - Fork 4.6k
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] [metadata] Skip null vtable entries when checking covariant return overrides #76327
Conversation
When there are covariant return overrides, we check the vtable slot in every parent class for signature compatability with the proposed override. However if one of the ancestor classes is abstract, it could have an abstract override for hte method: class Base { public virtual Base Method() => this; } public abstract Intermediate : Base { public override abstract Base Method(); } public Leaf : Intermediate { public override Leaf Method() => this; } In this case when we're checking that Leaf.Method is compatible with the vtable slot in Intermediate, we will see a null method (since Intermediate is abstract). In such cases we can skip over the class and continue with its parent. Fixes #76312
approved in email |
@carlossanlop I would really like a way to land changes between branding and lock down, It feels like we're creating additional servicing compression |
I see some problems if we start doing this:
Having said that, I am open to changing the rules if we have enough counter arguments to outweigh the disadvantages. @ViktorHofer @ericstj @mmitche what is your opinion on this? Are there additional concerns I am unaware of? Do you know if repos merge whenever? |
The only real requirement is that we do branding before we start merging fixes. Branding happens Tuesday. The main problem with checking in before we do branding is that we do incremental servicing for some repos. If you start checking into runtime, new versions of packages that will not ship in the next release start flowing into downstream repos and this tends to cause a ton of confusion and clean-up. Basically, it gets more complicated to allow changes whenever. The other option, is to branch for each release (6.0.9, 6.0.10, etc.). But it's been shown over time that it's really difficult to coordinate these activities (we do this for previews, of course), and they're difficult to automate because the repository owners need to be aware and in control of the content of those newly created branches. So we've tried to arrive at a happy medium for now where branding happens a week before release (around signoff) and we get a week or two where we can take new fixes. |
Approved, signed-off, CI green. No OOB package authoring changes needed. Ready to merge. |
Backport of #76323 to release/6.0
/cc @lambdageek
Customer Impact
Customers using code that uses C# covariant returns in mobile or WebAssembly applications experienced crashes when using classes that re-abstracted virtual methods that had covariant returns in child subclasses. At least one commercial NuGet package used this pattern which prevented their customers from deploying the library in Android applications.
See dotnet/maui#6811
Testing
New CI test and manual testing
Risk
Low. The change affects validation done by the runtime while loading classes. A null pointer dereference is avoided. No existing checks are removed, no new checks are added. Code generation is unchanged. Any code that previously worked will continue to work.