Skip to content
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

Catch ambiguous interface method resolution exceptions #15978

Merged
merged 1 commit into from Jan 24, 2018

Conversation

MichalStrehovsky
Copy link
Member

@MichalStrehovsky MichalStrehovsky commented Jan 23, 2018

Default interface methods might end up being ambiguous. Resolution thows an exception we need to catch at devirtualization time. The exception will still happen at dispatch time.

Default interface methods might end up being ambiguous. This thows an exception we need to catch.
@MichalStrehovsky
Copy link
Member Author

@MichalStrehovsky MichalStrehovsky commented Jan 23, 2018

(Not a fan of the fix, but not a fan of the throwing behavior in the first place. I guess we could also pass a bool flag across half a dozen frames to the place where we throw and use the value of the flag to decide if we want to throw?)

@jkotas PTAL

Cc @sergiy-k

jkotas
jkotas approved these changes Jan 23, 2018
@jkotas
Copy link
Member

@jkotas jkotas commented Jan 23, 2018

Do we need a test that hits this?

@jkotas
Copy link
Member

@jkotas jkotas commented Jan 23, 2018

cc @AndyAyersMS

@MichalStrehovsky
Copy link
Member Author

@MichalStrehovsky MichalStrehovsky commented Jan 23, 2018

Do we need a test that hits this?

This is getting hit by Loader\classloader\DefaultInterfaceMethods\diamondshape\diamondshape, but that one also hits #15979 so I'm not removing the test from issues.targets with this pull request.

@AndyAyersMS
Copy link
Member

@AndyAyersMS AndyAyersMS commented Jan 23, 2018

Is there a link anywhere that discusses implementation decisions? Seems like it would be good to have something written up, even if just an overview, in the CoreCLR design docs.

In particular I'm wondering if this is something that we could catch when the class is loaded, or whether that is too expensive and/or undesirable.

@jkotas
Copy link
Member

@jkotas jkotas commented Jan 24, 2018

Is there a link anywhere that discusses implementation decisions?

Agree. Opened issue https://github.com/dotnet/coreclr/issues/15989

@jkotas jkotas merged commit 007fa55 into dotnet:master Jan 24, 2018
13 of 14 checks passed
@MichalStrehovsky MichalStrehovsky deleted the fixDevirtException branch Jan 24, 2018
MichalStrehovsky added a commit to MichalStrehovsky/coreclr that referenced this issue Jan 24, 2018
* The diamondshape test should work now that dotnet#15979 and dotnet#15978 are merged.
* Create debug and retail version of diamondshape and sharedgenerics tests so that we have retail coverage. These tests hit issues around devirtualization (that is only active when RyuJIT is optimizing).
MichalStrehovsky added a commit that referenced this issue Jan 30, 2018
* The diamondshape test should work now that #15979 and #15978 are merged.
* Create debug and retail version of diamondshape and sharedgenerics tests so that we have retail coverage. These tests hit issues around devirtualization (that is only active when RyuJIT is optimizing).
* Add license headers
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants